[rfc-i] Pagination requirements
mrex at sap.com
Wed May 23 16:43:25 PDT 2012
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
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.
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
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.
More information about the rfc-interest