[rfc-i] v3imp #8 Fragment tagging on sourcecode

dev+ietf at seantek.com (Sean Leonard) Fri, 23 January 2015 09:08 UTC

From: "dev+ietf at seantek.com"
Date: Fri, 23 Jan 2015 01:08:34 -0800
Subject: [rfc-i] v3imp #8 Fragment tagging on sourcecode
Message-ID: <54C20F92.4090400@seantek.com>

Minor Improvement Need
#8 Fragment tagging on sourcecode

This improvement calls for fragment tagging on the <sourcecode> element. 
This is a follow-up to Jim Schaad's request 
<mid:051301cffde1$ebd07590$c37160b0$@augustcellars.com> 
<http://www.rfc-editor.org/pipermail/rfc-interest/2014-November/008328.html> 
(Subject: Allow fragment tagging on sourcecode).

The gist of jimsch's original improvement seems to be that fragments of 
a syntax (e.g., part of an ASN.1 module, such as a single definition) 
should be treated differently than a fig that includes a complete 
compilation unit. For example, many security RFCs include an "Appendix 
A. ASN.1 Module", where the primary figure is a complete ASN.1 module 
(regrettably punctuated with paging artifacts in the current text format).

My improvement should be considered in light of Improvements #5 and #6, 
which permit including discrete files or Internet message content. One 
should assume that such elements are complete units. Therefore, the use 
of <sourcecode> should be restricted to fragments only?nobody should 
need to extract the <sourcecode> figs out of an RFC and stitch it 
together in order to feed it through some software process. As Paul 
noted in his response, there are ordering problems when piecing such 
fragmented figures back together, and tools may make bad assumptions.

Nothing prevents an author from putting a "complete code unit" in a fig, 
of course, but the point is that a software process (e.g., a syntax 
highlighter) should assume that the fig is a fragment of the syntax 
rather than a complete unit.

Sean