[rfc-i] issue: canonical formats

Yoav Nir ynir at checkpoint.com
Mon Jun 4 01:50:43 PDT 2012

On Jun 3, 2012, at 6:59 PM, Joe Hildebrand wrote:

> On 6/3/12 6:50 AM, "John R Levine" <johnl at taugh.com> wrote:
>> I'm not opposed to HTML, but I doubt that a useful version of HTML would
>> be any easier to edit than xml2rfc.
> By hand, an HTML format may be slightly more difficult to edit than xml2rfc
> format.  However there are more tools to deal with HTML, for example ones
> that show you the rendered version in real-time as you modify the source.
> It's roughly a wash on ease of authoring so far, at least for me.

I strongly prefer the XML2RFC. Any XML that you write and pass through xml2rfc comes out looking like an RFC, including correct section numbering, the TOC, etc.

Most HTML in the world doesn't look like an RFC. So if we allow HTML as the submission format, we need tools that reject or fix anything that doesn't look like an RFC, or else have the human RFC editors reformat all the text (and pretty soon, images as well). Writing such tools is akin to writing anti-virus software - I-D writers can come up with new ways of creating things that don't look like RFCs faster than the tool can adapt.

The tools available for editing HTML don't make this any better. They might work with DIVs or tables or the infamous small white gif to create structure in documents, and they also tend to create very large files with a lot of embedded formatting, and that makes it harder later on to convert these to usable other formats such as PDF.


More information about the rfc-interest mailing list