Re: [rfc-i] Poll: RFCs with page numbers (pretty please) ?

[John C Klensin <[e-mail]>]

--On Tuesday, October 27, 2020 10:37 +1300 Brian E Carpenter
<[e-mail]> wrote:

>> The argument that page numbers are harmful for *any*
>> *purpose* *whatever* is not reasonable. To offer one
>> glaringly obvious counterexample, people (I, for one)
>> sometimes print RFCs for the purpose of reading them.
>> Sometimes we want to make use of some kind of facility for
>> indexing from a list of headings to facilitate direct access
>> to the right section of the pile of printout. A table of
>> contents, in short. This is literally what tables of contents
>> were invented for. They remain useful for this purpose…
>> unless some bright spark chooses to remove the page numbers
>> from them, because they forgot what tables of contents are
>> FOR.

> Well yes... but iirc the input to the new format discussion
> was that most people read RFCs and drafts on-screen and mostly
> with the htmlized versions. So the needs of the occasional
> eccentrics who print them for off-line reading were set aside.
> (I can say that because I am such an eccentric.)  

But, first of all, if the only need is to print (eccentric or
not) for off-line reading were the only issue, then that is an
argument in favor of PDF and perhaps abolishing the text form,
not crippling it, unless one happens to like the fixed-pitch
font (definitely eccentric).   The people whose needs were set
aside were those of us who routinely use text editors (of the
emacs or vi species and their clones), and personal RFC-specific
macros in those editors, to work with RFCs, many of whom have
been working that way for a long time (a few since before there
was an IETF). 

As to "set aside", there were at least some IETF participants
with those needs (or, if you prefer, habits), along with those
who argued for keeping the xml2rfc v3 specification rather
closer to generic markup (reducing rather than increasing the
amount of format markup) and inclusion of markup that would make
it straightforward to specify references to book chapters and
journal articles in relatively standard form. It was made clear
to at least a subset of that group that they were (to paraphrase
somewhat) a bunch of old farts who, regardless of their prior
experience, just did not understand the modern Internet and
publishing and therefore would not be listened to no matter what
they had to say.  That message was rather clear and, since the
process was not an IETF one, appeals and the like felt rather
hopeless.  So, some people just moved on to other things and
others concluded that the IETF was on enough of a downhill slide
that issues like publication formats made little difference.

The good news is that there apparently weren't very many of us.

>> (Also, I think the use of the ToC for quickly estimating a
>> document's throw weight is a valid one. I previously
>> suggested associating a BogoPages metric with each non
>> paginated RFC for this purpose.)
> 
> Well, the byte count serves fairly well for that too.  

Sure.  So does a line count given a format.  But, while I'm
reconciled to do it, time I spend re-understanding and then
rebuilding macros that are a couple of decades old is time that
isn't spent on IETF substantive work.  The question is whether
whatever benefits are gained by eliminating pagination from RFCs
-- presumably gains to those who continue to use the text form
rather than HTML or PDF because the latter two groups are
irrelevant -- are sufficient to justify that.

   john
  


> 
> Regards
>    Brian
> 


_______________________________________________
rfc-interest mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest