|
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 < john-ietf@xxxxxxx> wrote:
--On
Tuesday, October 27, 2020 10:37 +1300 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx>
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
rfc-interest@xxxxxxxxxxxxxx
https://www.rfc-editor.org/mailman/listinfo/rfc-interest
|
