Subject: Re: [art] New RFCs text formatting

From: Nick Hilliard <[email-masked]>
Date: Sun, 1 Dec 2019 17:28:27 +0000

Joel M. Halpern wrote on 30/11/2019 23:46:
> It seems that it ought to take a consensus call (here, rfc-interest, 
> somewhere else?) to change the default output prouced by the IETF tools. 
>   The question of pagination of output was more contentious than I would 
> have expected in previous rounds.

Not even slightly unexpected - this is a classic bikeshed issue.

I'd be happy for pagination to be the default if there were rough 
consensus that the primary medium for reading RFCs was printed paper.

Nick

---

From: Keith Moore <[email-masked]>
Date: Sun, 1 Dec 2019 12:52:10 -0500

Sent from my iPhone

> On Dec 1, 2019, at 12:28 PM, Nick Hilliard <[email-masked]> wrote:
> 
> I'd be happy for pagination to be the default if there were rough consensus that the primary medium for reading RFCs was printed paper.

Seems like this is backwards.  Pagination should be removed from plain text RFCs only if there’s rough consensus that nobody prints RFCs anymore - not because a few individuals think that nobody should do that, or think that they’re in a position to dictate how RFCs are used. 

Keith

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 1 Dec 2019 12:55:59 -0500

+1

> On Dec 1, 2019, at 12:52 PM, Keith Moore <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPhone
>

---

From: Eric Heflin <[email-masked]>
Date: Sun, 1 Dec 2019 12:07:15 -0600

Also agreed.

On Sun, Dec 1, 2019 at 11:56 AM Scott O. Bradner <[email-masked]> wrote:

> > Seems like this is backwards.  Pagination should be removed from plain
> text RFCs only if there’s rough consensus that nobody prints RFCs anymore -
> not because a few individuals think that nobody should do that, or think
> that they’re in a position to dictate how RFCs are used.
> >
> > Keith
> >
> >
>
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 01 Dec 2019 10:17:44 -0800

On 1 Dec 2019, at 9:52, Keith Moore wrote:

> Pagination should be removed from plain text RFCs only if there’s 
> rough consensus that nobody prints RFCs anymore - not because a few 
> individuals think that nobody should do that, or think that they’re 
> in a position to dictate how RFCs are used.

One can easily print text files that have no pagination; we do that all 
the time. In fact, using unpaginated text files completely removes the 
question of "which paper size will most people want for pagination".

However, it seems that this entire thread is being continued by people 
who have not read RFC 7994, which requires pagination for the RFC 
output. Why is this being rehashed three years after the last-call 
discussion of this document?

--Paul Hoffman

---

From: Keith Moore <[email-masked]>
Date: Sun, 1 Dec 2019 13:37:13 -0500

On 11/30/19 10:59 PM, Phillip Hallam-Baker wrote:

> On Sat, Nov 30, 2019 at 10:12 PM Joel Halpern Direct 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     That (the suggestions that RFC-interest is the wrong place to
>     judge such
>     things) may be, which is why I listed alternatives.  But just saying
>     that two people liked the idea, and no one screamed, in one day, is
>     clearly NOT enough to change the default.
>
>
> Quite. The botched pagination of the old plaintext format was one of 
> the main reasons I hated it. The parochial US-centric design ensures 
> that it only works reliably on US paper which is only used in North 
> America.

I thought the format was a compromise between US Letter format, A4 
format, and printers.   The horizontal line length was short enough for 
A4 format.   The number of lines per page was short enough for Letter 
format.   And even those printers capable of centering a text image on a 
page, didn't do so by default.  Some printers could print 66 lines on a 
page, but some could only print 60 or even 58.  A lot of printers were 
set so that the start of a page (after receiving a form feed or page 
advance button press) was some distance down from the perforation or top 
of the actual page, so that there would be some margin at the top 
(sometimes used for binding) and the printed text wouldn't creep to 
overlap the perforations on continuous-feed paper.

(In hindsight maybe the line lengths should have been even shorter so 
that RFCs would look equally ugly when printed in either Letter or A4 
format, but nothing's perfect.)

In some ways it's still a better format than anything else, including 
HTML and PDF.

What would be parochial would be to assume that nobody in the world 
needs to print RFCs using mechanical printers any more - that everyone 
in the world should have laser printers, ample power for their fusers, 
and a generous supply of suitable paper and toner - or for that matter 
that everyone in the world should have multiple displays so they can 
read RFCs on one screen while writing code or other specifications on 
another one.   Yes, the plain text RFC format is a low-tech format 
intended for low-tech devices.   That's a feature, not a bug.

Keith

p.s. Some may not be aware, and some may have forgotten, that I was the 
first to set up an "RFCs in PDF" page (I believe there was also an "I-Ds 
in PDF" page) so that those readers who were forced to use Windows would 
still have a way to print out RFCs with appropriate pagination.   It 
seemed like overkill to use PDF for that, but it wasn't too hard to 
implement and it was fit for purpose.  I'm all about making RFCs 
accessible (yes, even for Windows users :) but not about breaking things 
that work.

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2019 14:09:53 -0500

In article <[email-masked]> you write:
>format, and printers.

I thought it was 72 characters because that's how many you got on a
punch card, leaving 8 for the sequence number.

>and a generous supply of suitable paper and toner -

I think that if you price all the printers made in the past decade or
two, you'll find that there are a lot of laser and inkjet printers and
close to nothing else, certainly nothing restricted to fixed pitch
text.  The only mechanical printers I recall seeing in recent years
are antique Okidata dot matrix units printing whatever it is they
print at airport gates.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Dec 2019 15:23:55 -0500

I would say "+1" too, except that, from experience, the implicit
characterization of paginated (and header and footer-equipped)
plain text as being only about printing (especially, as has come
up in other notes, printing on ancient, perforated-paper, line
printers) misses the point that there are at least three reasons
that I can think of to prefer that format (other than
idiosyncratic personal taste, but I don't think the IETF gets to
say that even the latter is illegitimate).  Those are:

(1) One really does intend to print the document and has a
printer, or printer drivers, that make handling of documents
without page breaks difficult.  As Paul Hoffman just pointed out
(and I pointed out last week), RFC 7994 requires pagination (but
just page breaks, not headers or footers) for the RFC output.
If RFCs are being produced and put into the archives / available
from the RFC Editor's server) that don't have those page breaks
in the plain ASCII form (and we seem to have at least one
example) that is a bug and it is, at least IMO, reasonable to
ask how soon it will be fixed (and maybe why it happened).

(2) One has discovered that, regardless of the format in which
one prefers to read RFCs, it is easier to work with them in
plain text format using public tools like "grep", some
highlight-copy-and-paste operations, and so on.  Most, perhaps
all, of those uses require that plain text files be available;
few, if any, require pagination, much less headers, footers, or
page numbers [1].

(3) One has private tools (or obscure public ones that there has
been no evidence that anyone other than their authors know
about) that are actually dependent on the presence of headers
and/or footers and/or usable page numbers.

So, I think that Keith should have said "only if there's rough
consensus that
none of the three cases above exist anymore.  If they do, there
is rough consensus that the IETF is willing to tell users whose
work falls into one of those categories that we are just not
interested in their problems and that, if the result is that
they reduce their participation or willingness to accept RFCs
for other purposes, we just don't care."

best,
   john

p.s. Some of the comments about A4 paper make questionable
assumptions about how line and page lengths for RFCs were
chosen.  It may well be that we (and I do mean "we" because I
was involved in the discussion although I certainly was not the
decision-maker) got it wrong, but the assumption that is was not
considered is simply incorrect.

[1] As I have discussed elsewhere and will not repeat unless
asked, the claim that eliminating the ability to reference into
an RFC by page number and therefore encourage shorter sections
has actually been disproven by years of experience.  The only
things that encourage or forces shorter sections are author
education and the RFC Editor insisting that they will not
publish a document with too-long sections without a very
specific justification (at least unless the Stream Manager
insists and then probably with the appropriate note).

--On Sunday, December 1, 2019 12:55 -0500 "Scott O. Bradner"
<[email-masked]> wrote:

>>> I'd be happy for pagination to be the default if there were
>>> rough consensus that the primary medium for reading RFCs was
>>> printed paper.
>> 
>> Seems like this is backwards.  Pagination should be removed
>> from plain text RFCs only if there's rough consensus that
>> nobody prints RFCs anymore - not because a few individuals
>> think that nobody should do that, or think that they're in
>> a position to dictate how RFCs are used. 
>> 
>> Keith
>> 
>> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 2 Dec 2019 09:33:28 +1300

> punch card, leaving 8 for the sequence number.

Keith is right and it was one of Postel+Reynolds's wiser decisions. The only case where it goes wrong is with software or printers that fail to recognise the FF (form feed) character correctly.

Phill is correct that it wastes some white space; that's the price of fitting into both paper sizes. When I print drafts, which is rarely, I do it "booklet" style which limits waste paper considerably.

As we discussed 3 years ago, numbered pagination is useful in a printable format but irrelevant in a screen-only format.

Can we stop now?

     Brian

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 1 Dec 2019 15:35:14 -0500

I agree with what John has to say but also with the “bumper sticker” way that Keith
expressed it - changes should be made when to very well established and widely used systems 
its known that no one uses the old version not just because someone thinks there is a better way

for what its worth - I have used the old format for decades and still do (or want to)
i.e. pages & page numbers

Scott

> On Dec 1, 2019, at 3:23 PM, John C Klensin <[email-masked]> wrote:
>

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 1 Dec 2019 15:36:58 -0500

> On Dec 1, 2019, at 3:33 PM, Brian E Carpenter <[email-masked]> wrote:
> 

except for references - section numbers are frequently far too far apart when you want to point someone to a particular
chunk of text

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 2 Dec 2019 09:45:06 +1300

Scott,

> except for references - section numbers are frequently far too far apart when you want to point someone to a particular

Yes. I sometimes use page numbers for that reason, like https://tools.ietf.org/html/rfc3056#page-15 (random example with no significance). For new-format HTML, any internal <xref/> should generate a link.

    Brian

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 1 Dec 2019 15:47:57 -0500

the usefulness of a link depends on where the reference is used - I, for example, reference RFCs very
frequently in expert reports in patent cases where everything is still paper-based so the references
need to work when printed on paper

Scott

> On Dec 1, 2019, at 3:45 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Scott,
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 1 Dec 2019 21:55:21 +0100

On 01.12.2019 21:36, Scott O. Bradner wrote:
> ...

That's why in the new format, paragraphs get numbers, too. (in HTML,
where it really matters).

Best regards, Julian (ducks)

---

From: Brian Carpenter <[email-masked]>
Date: Mon, 2 Dec 2019 10:21:23 +1300

Understood, but since the new canonical form is XML there is a much harder
issue.

Regards
    Brian
    (via tiny screen & keyboard)

On Mon, 2 Dec 2019, 09:48 Scott O. Bradner, <[email-masked]> wrote:

> >>> Keith is right and it was one of Postel+Reynolds's wiser decisions.
> The only case where it goes wrong is with software or printers that fail to
> recognise the FF (form feed) character correctly.
> >>>
> >>> Phill is correct that it wastes some white space; that's the price of
> fitting into both paper sizes. When I print drafts, which is rarely, I do
> it "booklet" style which limits waste paper considerably.
> >>>
> >>> As we discussed 3 years ago, numbered pagination is useful in a
> printable format but irrelevant in a screen-only format.
> >>
> >> except for references - section numbers are frequently far too far
> apart when you want to point someone to a particular
> >> chunk of text
> >
> > Yes. I sometimes use page numbers for that reason, like
> https://tools.ietf.org/html/rfc3056#page-15 (random example with no
> significance). For new-format HTML, any internal <xref/> should generate a
> link.
> >
> >    Brian
> >
> >>
> >> Scott
> >>
> >>>
> >>> Can we stop now?
> >>>
> >>>    Brian
> >>>>

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 1 Dec 2019 03:10:36 +0000

The holiday season is upcoming, the new-format cutover is very recent, and we just had an IETF meeting.

Maybe cut folks a little slack and just briefly (!!!) point out what is missing?

Ietf moved to bcc; rfc-interest added.

	/r$

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Dec 2019 18:06:48 -0500

Rich,

What is missing is a page-image format (I personally don't care
if it is restricted to ASCII or uses UTF-8 coding or not, but
believe the latter would be better and easier to achieve with
xml2rfc v3) with headers, footers, and pagination compatible
with what we have been using/ living with for the last 40-odd
years.

IETF list added back in because, IMO, part of what got us to the
point where we are having this discussion now rather than
three-plus years ago was that a number of discussions and
decisions occurred on the rfc-interest list without adequate
information, warning, and serious attempts to get informed
consensus among those who use and work with RFCs rather than
just those willing to endure sometimes very detailed discussions
on that list including, occasionally, the tone and
aggressiveness of some of them.

That short enough?
   john

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 2 Dec 2019 00:07:58 +0100

> punch card, leaving 8 for the sequence number.

More likely, it’s 72 characters for the line width of a Model 33 Teletype (a.k.a. ASR-33/KSR-33).
Not everyone had a line printer or a card reader!

Grüße, Carsten

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 1 Dec 2019 23:23:03 +0000

>    That short enough?

Modulo the second paragraph :)  sure.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 3 Dec 2019 15:13:01 +0100

On 30.11.2019 06:22, Julian Reschke wrote:
> On 29.11.2019 23:34, Carsten Bormann wrote:
>> On Nov 29, 2019, at 23:18, John C Klensin <[email-masked]> wrote:
>>>
>>> identified a weakness in rfcdiff
>>
>> The RFC 7386/7396 accident was also caused by this (root cause was
>> apparently the use of HT characters, which need to be expunged from
>> the universe, but rfcdiff helped in not detecting the problem before
>> publication).
>>
>> Grüße, Carsten
>
>
> rfc2629.xslt has been warning about HTAB since 2014-10-16 (likely
> triggered by that accident). xml2rfc has a ticket open about that:
> <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/403> (dated
> 2019-04-14, still in status "new").
> ...

FWIW, rfc2629.xslt used to output the HTAB into the HTML content; this
is now changed, it will place a (red) U+2409 character instead - that
should make it easier to spot the issue in the source (see
<https://github.com/reschke/xml2rfc/commit/58dca914d1489f25b4be8220c30e13f1cb23e46e>).

Best regards, Julian

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Dec 2019 11:27:38 -0500

--On Tuesday, December 3, 2019 15:13 +0100 Julian Reschke
<[email-masked]> wrote:

>>> The RFC 7386/7396 accident was also caused by this (root
>>> cause was apparently the use of HT characters, which need to
>>> be expunged from the universe, but rfcdiff helped in not
>>> detecting the problem before publication).
>>> 
>>> Grüße, Carsten
>> 
>> 
>> rfc2629.xslt has been warning about HTAB since 2014-10-16
>> (likely triggered by that accident). xml2rfc has a ticket
>> open about that:
>> <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/403>
>> (dated 2019-04-14, still in status "new").
>> ...
> 

Helpful but, if we are concerned about what the final output
looks like, wouldn't it be easier to have authors just convert
HT to the widths they prefer and to modify the nits checker to
notice their presence?  And for the RFC Editor to be sure that
none of them make it into final output?  Those are just
questions -- I haven't thought through what bad side effects
that might have.

best,
   john

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 Dec 2019 17:34:51 +0100

On Dec 3, 2019, at 17:27, John C Klensin <[email-masked]> wrote:
> none of them make it into final output?

Yes.

It seems to me Julian’s code was simply providing the error message in the form of a red U+2409 «␉», so you can locate the HT if you don’t have an appropriate editor program.

Grüße, Carsten

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Dec 2019 11:36:10 -0500

--On Tuesday, December 3, 2019 17:34 +0100 Carsten Bormann
<[email-masked]> wrote:

> It seems to me Julian's code was simply providing the error
> message in the form of a red U+2409 «␉», so you can locate
> the HT if you don't have an appropriate editor program.

Clearly useful too.

best,
  john

---

From: Julian Reschke <[email-masked]>
Date: Tue, 3 Dec 2019 17:55:25 +0100

> It seems to me Julian’s code was simply providing the error message in the form of a red U+2409 «␉», so you can locate the HT if you don’t have an appropriate editor program.

Right.

xml2rfc in v3 mode should just give proper diagnostics and/or abort
processing (right now it seems to just replace the TAB by multiple TAB
characters, which is clearly not what the spec is requiring).

Best regards, Julian