[rfc-i] transition plan for choosing alternative format for RFCs

Larry Masinter masinter at adobe.com
Sat Mar 24 21:09:23 PDT 2012


I'd like to suggest a transition plan, with trail and evaluation along the way:

* Current: Official policy: ASCII-only text edition is authoritative, PostScript alternative allowed but infrequently invoked.
In practice: PDF editions also sometimes provided.
* step: Allow HTML and PDF as alternatives, but converge on rules and tools for producing them more regularly and enforcing some quality control on the profiles allowed.
* step: Allow ( in cases where it matters) for one of the alternate editions (e.g. PDF or HTML)  to be declared authoritative, but still require an ASCII-text edition. 
* same, but ASCII text not always required
* non-ASCII-text versions are routinely declared authoritative.
* Finally: alternative format is chosen as default for all RFCs.

Along the way, 
*  produce alternative editions of a few/some/many existing current (i.e., used, read, needed) RFCs
* survey community as to which formats they find useful, and additional requirements

The idea is to develop the workflow and tools for submission and publication paths for  alternative formats, and address the cases where Unicode text, images and graphic illustrations are useful. 

I think there are still a number of issues to be resolved before allowing non-ASCII text in primary specifications. For Unicode HTML or text, do you allow private use characters?  Must the Unicode be in a normalized form? Zero-width joiners?  If the examples are expected to be used "as is" from extracting from HTML? 

How do we insure that multiple editions are consistent? How is that reviewed? What are the allowable divergences? I think when there are multiple editions, one needs to be declared "authoritative", but is that sufficient?

The current experiments with xml2rfc extensions to allow a single XML source to be used for multiple format targets are encouraging, 

For HTML, how are images packaged (multipart/related? ePub format?  Just in the RFC directory with an RFCxxxx/something.jpeg  auxiliary files?). Are there rules or limits on complexity, animation?

For PDF, using Leonard's suggested PDF/A profile addresses the archival requirements. Including the ASCII and XML versions as attachments inside a PDF/a makes sense to me as well.

The question then becomes "which of these formats is most useful, and will aid the community". I'd suggest a trial and a survey. 

Take a sample of 5 RFCs (chosen by RFC editor or by RFC authors) and publish HTML and PDF/A editions of them as well.  Create a survey of users asking them which ones they found useful, which ones they preferred to reference, what other concerns they might have.

Converge on an "authoring" format implies restricting authoring tools; I think this is a high and unwarranted cost. So I think focusing on publication format, and allowing Word, NRoff, XML2RFC input paths to remain while getting better experience with other document forms. 

Once we're satisfied that we've converged on reasonable rules for these alternative formats, the next step might be to allow one of the alternative forms to be declared "authoritative" (e.g., in its last call).

Most journal publishers producing documents "of record" are working through their requirements.

What other SDOs do is of course of interest.   

W3C has HTML publication rules -- should those be important to IETF?  Do other standards groups have publication rules that IETF should review?


More information about the rfc-interest mailing list