[rfc-i] Numbering and counting things (was: Re: New Version Notification for draft-flanagan-plaintext-00.txt)

John C Klensin john-ietf at jck.com
Wed Jun 25 04:53:31 PDT 2014



--On Tuesday, June 24, 2014 10:39:29 -0700, Joe Touch
<touch at isi.edu> wrote:

> On 6/24/2014 10:04 AM, Dearlove, Christopher (UK) wrote:
>> No one I've noticed has suggested that all formats should
>> have line numbers, be easily printable etc.
>> 
>> Just that one format should have those properties.
> 
> I doubt that would be useful - unless that format were the
> sole  canonical one.

As others have suggested, while I'm not wild about it as a
style, one could decide to automatically number paragraphs,
either from the beginning of the document or within numbered
sections.  Paragraphs are reasonably well defined even if the
definition turns out in practice to be equivalent to "[flowed]
line" in running text, and are more or less equivalent to the
"t" element in XML2RFC format.

One would then have to have a style rule prohibiting "page"-long
paragraphs and to think very carefully about what to do about
various types of lists within an XML2RFC paragraph/ list element
and pseudo-paragraphs constructed with vspace elements.   But,
unlike line numbers, it would be meaningful and
reader-format-independent if the cases were examined carefully
and stylistic rules made, documented, and then used and enforced
consistently.

Also, in a later note:

> Any item that has more than one representation begs the
> question of  "which is normative?" *when* (not if) the text
> and figure differ.

Yep.  And when other things differ as well, even if, as above,
one can establish conventions that make the differences trivial
in some cases.

> When we're writing a spec, IMO the text ought to be normative,
> and the  text alone ought to be sufficient (even if tedious).

And that, in a sentence, is one of two major problems with
declaring that the marked-up (xml2rfc) version is normative and
that none of the normally-human-readable presentation versions
are.

    john

p.s. One has better be _really_ careful about notions based on
counting bytes, octets, or similar units in the presence of "use
UTF-8", especially if that comes without a clear and
consistently used and enforced rule about normalization.

p.p.s. Those who are outraged about the idea of losing normative
ASCII art should remember that RFCs with only non-ASCII
illustrations have been allowed for a rather long time (see,
e.g., RFC 12).  It has required exceptional permission of the
RFC Editor but one plausible possibility would be to identify
cases for which the exception would be automatic.




More information about the rfc-interest mailing list