[rfc-i] New proposal for "canonical and others"

[paul.hoffman at vpnc.org (Paul Hoffman)]

Greetings again. I was surprised by the amount of interest people here had for having the canonical format for RFCs be XML or HTML. I agree with JoeH's thesis that having the canonical format be the same as the input format will reduce the number of hidden surprises for authors during their review of the RFC Editor's changes. (Can we stop calling that "AUTH48" now?)

For this draft, I chose XML instead of HTML for a variety of reasons. Basically, there are too many things that an HTML-aware editing program might do that would not match the constrained format that RFC Editor will surely require, whereas a similar (as yet non-existant) XML-aware editing program probably would not. The proposal makes an implicit assumption that the RFC Editor will make tools for making canonical RFC format readable freely available, similar to the way xml2rfc has been made available.

Thoughts?

--Paul Hoffman

Begin forwarded message:

> From: internet-drafts at ietf.org
> Subject: New Version Notification for draft-hoffman-rfcformat-canon-others-02.txt
> Date: June 15, 2012 3:16:07 PM PDT
> To: paul.hoffman at vpnc.org
> 
> 
> A new version of I-D, draft-hoffman-rfcformat-canon-others-02.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
> 
> Filename:	 draft-hoffman-rfcformat-canon-others
> Revision:	 02
> Title:		 Proposal for Canonical and Other Formats for RFCs
> Creation date:	 2012-06-15
> WG ID:		 Individual Submission
> Number of pages: 5
> URL:             http://www.ietf.org/internet-drafts/draft-hoffman-rfcformat-canon-others-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-hoffman-rfcformat-canon-others
> Htmlized:        http://tools.ietf.org/html/draft-hoffman-rfcformat-canon-others-02
> Diff:            http://tools.ietf.org/rfcdiff?url2=draft-hoffman-rfcformat-canon-others-02
> 
> Abstract:
>   This document proposes a new, XML-based canonical format for RFCs
>   that explicitly allows external art as a normative part of the RFC.
>   If the RFC Editor chooses this format, they will also publish non-
>   canonical versions of RFCs in order to accomodate the largest target
>   audience of readers.  Having a simple, stable canonical format and a
>   varying number of non-canonical formats that can change over time
>   allows the RFC Editor to add useful formats, particularly in HTML,
>   that can keep up with the needs of all RFC readers.