[rfc-i] RFC Format - final requirements and next steps
julian.reschke at gmx.de
Tue May 15 00:58:20 PDT 2012
On 2012-05-15 09:45, Brian E Carpenter wrote:
> On 2012-05-15 08:27, Julian Reschke wrote:
>> On 2012-05-15 08:13, Brian E Carpenter wrote:
>>>> Page length is a similar issue but not nearly as problematic, because
>>>> jumping over some headers/footers is annoying, but doesn't get in the
>>>> way of readability
>>> Indeed. And since we allow internal page references, getting rid of
>>> page numbers is not an option.
>>> It seems to me that due to this and the previous point (rewrapping
>>> text but not figures and tables), it's inevitable that *in any case*
>>> there needs to be a specially post-processed version for mobiles.
>> I strongly disagree.
>> Pre-paginated output should be the exception. In consequence, fixed page
>> number references are something we need to get rid of. We have section
>> numbers for a reason.
> Actually, if we follow an HTML direction, you don't even need that
> for internal references. But I don't think it will be easy to get
That is technically true, but doesn't help those who actually *do* print
documents; also sometimes it's easier to communicate a section number
instead of a full URI (or a fragment identifier).
> rid of pagination. I think it was invented for a reason, and we
> will have to deal with in the legacy RFCs anyway.
How do legacy RFCs affect the outcome of this discussions? Are there
requirements I'm not aware of?
> I find pagination useful when I need to study a document in close
> detail, for which purpose a hard copy in "booklet" format is
> generally better than reading it on a screen. In contrast,
> on-screen, pagination is just a nuisance.
Indeed. Pagination can be good; *Pre*-Pagination is bad. Page numbers
are only useful in the latter case, which doesn't work at all for
varying screen/paper sizes or font size preferences.
Best regards, Julian
More information about the rfc-interest