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

[Ronald Tse <[e-mail]>]

My two cents: why don’t we just run a poll to see what the “consensus” is?

To me, standardizing page numbers is the wrong direction — one of the features of XML RFC is to allow rendering content into different formats. Having page numbers for the ASCII version is fine (it’s only being done by xml2rfc anyway), but requiring these numbers inside the XML is putting the cart before the horse.

Ron

_____________________________________

Ronald Tse
Ribose Inc.

On Oct 27, 2020, at 7:56 AM, John C Klensin <[e-mail]<mailto:[e-mail]>> wrote:



--On Tuesday, October 27, 2020 10:37 +1300 Brian E Carpenter
<[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.rfc-editor.org/mailman/listinfo/rfc-interest