Personally, I find page references to be really confusing when people
talk about RFCs. But personal preference is not what matters.
We have already agreed that within the near future the pagination of
RFCs will differ in different representations, and some may not have
pagination at all.
As such, worrying about keeping page numbers working for the next few
years while we transition seems a less than effective use of our resources.
Yours,
Joel
On 10/11/17 5:12 AM, Stewart Bryant wrote:
That is popular in legal circles and I find it so distracting. In those
circles distraction of the reader may be good for the author. However
our goal is clarity of message to both so we can write and implement
unambiguous specifications.
When doing reviews I also find it useful to have page numbers as a quick
way of knowing how much text I need to make time to read.
- Stewart
On 10/10/2017 21:06, Andrew G. Malis wrote:
We could, of course, introduce paragraph numbering in the left margin,
which would alleviate the page number reference problem since as Yoav
notes, we’ll no longer have constant page numbers in the various
display versions of an RFC.
Cheers,
Andy
On Tue, Oct 10, 2017 at 2:48 PM, Yoav Nir <ynir.ietf@xxxxxxxxx
<mailto:ynir.ietf@xxxxxxxxx>> wrote:
On 10 Oct 2017, at 5:29, John C Klensin <john-ietf@xxxxxxx
<mailto:john-ietf@xxxxxxx>> wrote:
--On Monday, October 9, 2017 16:36 -0700 "Heather Flanagan (RFC
Series Editor)" <rse@xxxxxxxxxxxxxx <mailto:rse@xxxxxxxxxxxxxx>>
wrote:
On 10/9/17 10:14 AM, John C Klensin wrote:
--On Wednesday, September 27, 2017 08:38 +1300 Brian E
Carpenter <brian.e.carpenter@xxxxxxxxx
<mailto:brian.e.carpenter@xxxxxxxxx>> wrote:
So why don't we, the Internet standards people who believe in
rough consensus and running code, request the RFC Editor (a
friend of ours) to supply two text versions of each RFC, like
https://www.rfc-editor.org/rfc/rfc8187.txt
<https://www.rfc-editor.org/rfc/rfc8187.txt> as today, with
BOM if relevant
https://www.rfc-editor.org/rfc/rfc8187.ut8
<https://www.rfc-editor.org/rfc/rfc8187.ut8>
containing pure UTF-8 with no BOM ever
If one were really going to do that, one would need three
representations (pick your own three-character suffixes for
the first two):
rfc8176.utf8 (standard/normal Unicode in UTF-8, no BOM)
rfc8176.utf8-with-BOM (as above, but...)
rfc8176.txt (ASCII, with characters outside the ASCII
repertoire expressed as \u'[N[N]]NNNN' (see RFC 5137) or
another escaping system of the RFC Editor's choice.
A few points to consider. First, the RFC Editor will review,
at least to some extent, every file we produce, and our tools
will need to be modified to create the additional formats;
that complexity would then need to be maintained going
forward. The more files added, the more resources it will take
to produce. This has implications for either the time it takes
to publish or the cost it takes to publish. Second, there have
also been some discussions about creating separate files for
paginated versus unpaginated text files. That would take us up
to six files just for the plain-text outputs (noting the RFC
Editor also has the PDF/A-3 and HTML to review).
Alternatively, the IETF community that prefers plain text can
develop tools that takes the one file created by the RFC
Editor and strip the BOM, add pagination, or run it through a
translation tool to get it in their native language--these
will not be produced or reviewed by the RFC Editor, but will
perhaps meet the individual desires here. Given the number of
options, opinions, and resources involved, I think this makes
the most sense.
Up to a point, yes. On the other hand, unless the RFC Editor
intends to make a rule requiring either that sections (or
subsections) not extend over circa a page, or numbering lines,
or doing something else that facilities references into a
document, I think you'd best retain a canonical / distributed
version with page numbers, headers, and footers.
In that case we’d all have to look up that version whenever we
received a reference to something in RFC xxxx page 7. So even if
it’s more comfortable for us to read the RFC in a browser or on a
phone, we’d need access to this canonical version.
IMO it’s far easier to reference section and paragraph number, as
in “the formula in RFC 6962, section 2.1.2, paragraph 3”. This
works with any format, paginated or not.
This gets clunky if people have 4-page long paragraphs or
50-paragraph sections, but that kind of badness can and should be
caught by working groups, shepherd reviews or if all else fails,
gen-art reviews. This one is not up to the RFC editor to make
rules against.
Yoav