[rfc-i] Pagination requirements
jhildebr at cisco.com
Wed May 23 21:09:14 PDT 2012
On 5/23/12 5:43 PM, "Martin Rex" <mrex at sap.com> wrote:
> 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.
A) it will not require profound knowledge of HTML, no knowledge of XML
(unless you want to use that as a precursor tool), and will require *zero*
knowledge of CSS.
B) the number of people who understand HTML ***VASTLY*** outnumbers the
people who know how to spell "nroff".
> That may not affect folks from the
> apps area who are already CSS/HTML/XML experts, but those that
Is the pushback that there are some folks that don't want to learn new
things? This seems like the wrong career choice, then.
> 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.
This is a valid point that will have to be addressed. Rfcdiff is not a
standard tool, it had to be written to understand the lineprinter format.
The fact that it already exists is nice, but it doesn't mean that other
tools can't be written.
> 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.
So we're going to define a *new* markup language, tools to process it, and
to render it?
> 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.
Agree that new I-Ds and RFCs are different from the old stuff, and can be
> What I don't like about the fancy feature discussions is that they have
> lots of profound expertise prerequisite,
No. I'd ask that you wait for an I-D that describes a proposal before you
decide that it's too hard.
> significant to-be-written tools
Turns out the tools aren't that hard, particularly if someone else gets the
ball rolling and provides a lot of examples.
> 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.
Ones that have xml2rfc inputs available will be easy to move into the new
scheme. Ones that use other input mechanisms will take more work; we can
decide if that's something that should be prioritized.
Or is the argument that we can't ever change the format because we've got a
bunch of docs in an ancient format?
> 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.
I'm not arguing for creative HTML. I'm arguing for a very limited, safe,
conservative subset of HTML. Calling that subset "bleeding-edge" is either
a dirty rhetorical trick, or shows a lack of understanding of the
(see, I can use false dichotomies too, but am willing to call myself on it)
More information about the rfc-interest