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

Phillip Hallam-Baker phill at hallambaker.com
Wed Jun 25 05:05:19 PDT 2014


Citing a paragraph makes sense, a line number rarely adds additional

Further since the documents most likely to have fine grained citations are
others from the same document set, being over specific with line numbers is
a hassle.

Further, I can do paragraph level citations in an evening with a glass or
two of port. Doing line level citations would be an utter pain.

I don't see the need for a specific ban on page long paragraphs as that is
a corner case unlikely to arise and trying to ban it would require us to
define 'page'.

Actually there is a workflow tool I have around that allows comments to be
attached at paragraph level, will have to dust it off...

On Wed, Jun 25, 2014 at 7:53 AM, John C Klensin <john-ietf at jck.com> wrote:

> --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.
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20140625/bc0c5665/attachment.html>

More information about the rfc-interest mailing list