[rfc-i] Section 2.48 - allowing for fragment tagging on sourcecode

Paul Hoffman 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.

--Paul Hoffman

More information about the rfc-interest mailing list