[rfc-i] Requirement for "clear printing"
mrex at sap.com
Wed Feb 20 11:14:26 PST 2013
Heather Flanagan (RFC Series Editor) wrote:
> On 2/19/13 8:55 AM, Brian E Carpenter wrote:
> > On 19/02/2013 15:46, Julian Reschke wrote:
> >> On 2013-02-19 16:37, Ted Lemon wrote:
> >>> On Feb 19, 2013, at 10:19 AM, Tim Bray <tbray at textuality.com> wrote:
> >>>> Yeah, but there's no real utility in it, because once there's a
> >>>> decent HTML version available, only Martin Rex will still be using
> >>>> the legacy ASCII, so there'll be nobody for him to talk about page
> >>>> numbers with
> >>> I doubt he's the only one, and it's easy to accommodate him, so why
> >>> not do it?
> >> I have my doubts about "easy to accomodate". Right now, the RFC Editor
> >> spends time to optimize vertical whitespace for page breaking in
> >> text/plain. I think it would be good to get rid of this waste of time.
> > It's a lot harder to do with variable-width multi-font etc etc.
> > Also, if we do it, it's really pointless if the pagination is
> > different on International Standard A4 paper and local standard
> > US Letter, because "foreigners" would not be able to trade page
> > numbers with anyone in the USA.
> There are many reasons why we strongly recommend that people do not use
> page numbers as their points of reference. Yes, I know it is done, but
> it is fraught with potential for misunderstanding and misdirection and
> making any kind of requirement for it is, I believe, not a good idea.
If there is a pre-paginated canonical format of a document, as it
has been for I-Ds and RFCs all the time, then the use of page numbers
will remain entirely free of misunderstandings and misdirections.
Page number are natural and sensible for anything that is printed,
as well as anything that is pre-paginated for printing.
While I do usually mention both, the section and the page, the
section itself is often much too coarse to be helpful. Section numbers
may work poorly not only for long sections, but also for pointing to
specific locations within a MIG or an ASN.1 module. And there
is *NO* ambiguity involved.
e.g. Pointing to the processing of basicConstraints extension of
an intemediate CA cert during PKIX certificate path validation,
see basicConstraints processing PKIX/rfc5280, section 6.1.4 (k) on page 87
and for the ASN.1 definition of the crlReason,
see PKIX/rfc5280, Appendix A.2 on page 132
Both references work **MUCH** better than with section number alone,
and since all documents are immutable once published, there is exactly
zero ambiguity involved. And yes, this page-based anchor tags will
intuitively work just fine with printouts, A4, US paper sizes and
any kind of N-up printing that carries through the page numbers.
The huge advantage of fixed size 10 cpi font for the vanilla TXT document
is that one can reliably predict the readability for *ALL* documents
that are printed N-up, because the font size is reliably known before
If the authors get to choose arbitrary font sizes, printing will become
a tree chopping exercise, because inconsistent readability of N-up
printouts that will be highly dependent on the authors (ab)use of
> > b) There is a separate question of whether we also require
> > identical pagination on those two paper sizes.
> Do not want to go here.
This is where we currently are, and where it is reasonable to be.
Please don't break it lightheartedly.
More information about the rfc-interest