[rfc-i] issue: legal status of canonical formats

Yoav Nir ynir at checkpoint.com
Sun Jun 3 01:26:54 PDT 2012


I agree with PHB and John Levine that we're spending way too much time on supporting use by courts, when there's not even a problem there.

I think it should be fairly easy to create at least three output formats:
 - HTML (simplified somewhat for longevity) with no pagination
 - PDF (maybe /A) with page numbers. You can play with the settings so that the same PDF would print OK on both A4 and US Letter
 - old-style text. Smallest file, and some prefer it.

I think we should also have a canonical input format. I prefer the XML because it enforces structure and prevents doing things that don't look like an RFC, but the requirements should be:
 1. Should be well specified so tools can make it.
 2. Contain all the information, so all the output formats can be generated automatically from it.

Note that the output formats are not equivalent. If we allow non-ASCII art graphics, or even ASCII art that's wider than 72 characters, it won't show correctly in the old-style text. 

Similarly, HTML can contain arbitrary width graphics, forcing you to scroll, but PDF is limited to the width of the "page". I think it would be a valid criticism of a draft, if it includes an image that would be automatically resized to something unusable, although you can still zoom in when you're on a computer.

If we allow animated PNGs they would also not work on printed PDFs, at least outside of the Harry Potter universe. So unless the document actually requires the wizard in figure 1 to wave, wink, and run off to figure 2, these should be discouraged.

The canonical input format can be made available, so that others can write tools to convert it to other output formats, such as "mobile" html, epub, or ODF, but I think even the regular HTML can and should work well on a phone or tablet, especially if it looks like the current HTML output of xml2rfc.


More information about the rfc-interest mailing list