[rfc-i] RFC submission formats, Internet-Draft formats, and RFC streams

Paul Hoffman paul.hoffman at vpnc.org
Tue Dec 11 12:31:59 PST 2012


[[ Changing the subject line, because this has nothing to do with RFC editing. ]]

On Dec 11, 2012, at 12:00 PM, Ted Lemon <mellon at fugue.com> wrote:

> On Dec 11, 2012, at 2:54 PM, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
>> If xml2rfc++ becomes the new canonical format, and many people want to develop Internet Drafts in HTML, the RFC Editor should allow that as an input format as long as it is constrained in such a way as to be a minimal burden on the post-submission process. An HTML profile that is a straight conversion to and from the canonical XML profile would be logical. In that case, the RFC Editor should fund the creation of the conversion tool as a benefit to the RFC-writing community.
> 
> It seems to me that this is not the RFC editor's problem

It is absolutely the RFC Editor's problem to specify what input formats are allowed for each stream. The fact that this has only been done informally for >15 years does not mean that it should not be done now.

Note that this very much comes down to the relationship between the RFC Editor and the streams. No one wants to discuss that much, but it is what threads like this keep coming around to: "I want to edit my drafts with X tool and turn them in in Y format". There is no RSE equivalent for Internet Drafts who can say "we will publish drafts in the following formats" even though everyone "knows" that has mostly been ASCII-only, but with "looser" rules than those used for RFC publication. If the canonical RFC publication format changes to something a tad more modern than lineprinter, the streams have to decide whether it might make sense (cough cough) to update their Internet Draft formats as well. And that absolutely will require tooling for the Internet Drafts submission.

The room is large, but there is still an elephant sitting in the middle.

> —it's the problem of the community of editors who want this capability.   

It is not a problem. It is their responsibility to talk to their stream directors.

> Joe's already said that it's a matter of a few minutes work to cobble together the jquery code to make this work, so it seems like a no-brainer anyway—nothing the RFC editor need take on as a burden.

jQuery is for finding parts of a published HTML document; it's not for converting between formats. And he can't cobble it together in any language unless we know what the acceptable input formats are. Nor should this be the job of a volunteer if it is going to affect hundreds of RFC authors. Hasn't the all-quirks-all-the-time-mode of xml2rfc proven that?

--Paul Hoffman


More information about the rfc-interest mailing list