[rfc-i] RFC Format - final requirements and next steps

Julian Reschke 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 mailing list