[rfc-i] Section 2.48 - allowing for fragment tagging on sourcecode
paul.hoffman at vpnc.org
Tue Nov 11 11:41:49 PST 2014
On Nov 11, 2014, at 9:01 AM, Jim Schaad <ietf at augustcellars.com> wrote:
> > Section 2.48 - should I be able to label a code fragment as oppose to a full item - for example a fragment of asn;1 vs the complete asn.1 module
> [paul] The list could be doubled in length for fragments, but that seems excessive. Do you foresee that an ASN.1 fragment would be rendered differently than a full ASN.1 module? Of that a program looking for ASN.1 in a published RFC will do something different with a fragment than with a full module?
> Ok – the problem of doubling can easily be solved by the addition of fragment attribute.
> I don’t know that I believe that there would be a difference in how things are displayed if you are looking at code fragments vs complete code items.
> I do believe that there could be some significant differences between how programs looking at the modules will handle things.
Specifics for those two would be greatly appreciated.
> In drafts – tools may check that the fragments in a file match correctly to the same whole object that is living in an appendix.
I do not foresee a tool that could determine that automatically.
> For some types, you will expect to grab and combine fragments together and for others you will ignore fragments and just grab complete items. A fragment of ASN.1 cannot be combined into a compete file, however one can combine multiple fragments of ABNF together into a single file to produce a complete file even if there is not one in the appendix.
All true, but I also don't think a tool could determine which of these fragments go into that program in the appendix in a particular order. Further, I worry that if there is an optional "fragments" attribute and the author doesn't put it in their text, tools could make bad assumptions.
More information about the rfc-interest