[rfc-i] Pagination requirements

[Martin Rex]

Iljitsch van Beijnum wrote:
> 
>> I don't want TeX-level typesetting for paper printouts,
>> but I'd like to not give up what I have now - some sense
>> that there's control over page breaks when printing out.
> 
> HTML/CSS supports page breaks. So it's possible to start sections
> on a new page, although I'm not a fan of that, even on paper.


I personally do not believe that making profound CSS & XML skills
and numerous to-be-written complex tools a prerequisite for
authoring I-Ds would significantly raise the entry barrier for
new IETF contributions.  That may not affect folks from the
apps area who are already CSS/HTML/XML experts, but those that
aren't.

Currently, if you want to start authoring I-Ds with NO prior
knowledge, there is the option of using NRoffEdit.  It understands
a dozen very simple nroff commands that are sufficiently explained
in the 2 page built-in help page.  And the NRoffEdit import function
allows you to pick up an existing RFC txt or abandoned I-D txt file
and convert it back into nroff authoring format.

Diffing two existing RFCs, two I-Ds or an exiting I-D and a new RFC
is currently an already solved problem, tools.ietf.org does it for
you quite well based on the canonical TXT format.

  Like  http://tools.ietf.org/rfcdiff?url1=rfc2246&url2=rfc4346

in order to figure out what are the true differences between TLSv1.0
and TLSv1.1 specs.


Writing a tools backend that reflows existing rfcXXXX.txt and allows
variable with fonts (something like a beefed-up rfcmarkup) should not
be that hard.  Falling back to preformatted output for lines where it
is unsure about reflowing should work with a lot of existing RFCs.

For *new* I-Ds and RFCs, the authoring conventions could be restricted
to structures that can be correctly reflowed, and idnits could check&advise
about it.


What I don't like about the fancy feature discussions is that they have
lots of profound expertise prerequisite, significant to-be-written tools
prerequisite for authoring, display, printing, diffing, re-authoring
--and that they do not address the issue of "beautifying" the output
of the _existing_, not exactly small amount of IETF documents at all.


If this discussion is really about the consumers of the documents,
then it would focus on making the _existing_ documents more "consumable"
rather than on the desire of a handful of authors to support their
rampant creativity with bleeding-edge complex technologies and a requirement
for everybody else that they must follow suit.


-Martin