Since I've been using the quite attractive XML2RFC package for some, but not all, of the documents I'm working on, let me make a few observations about this...
(1) The potentials to get quickly from I-D format to RFC format, and to edit either with a wide variety of editing tools (including some otherwise-broken ones) should be considered very attractive. (2) RFC 2629 (and 2629bis) impose some formatting and style requirements that are more restrictive than those supported/ required by the RFC Editor. At the same time, the RFC Editor imposes --sometimes on a per-document basis-- some formatting and style requirements that are different from those provided by 2629 and xml2rfc. That is not a wonderful situation, and it would be well to get it sorted out before an XML format is promoted to any official status --rather than being a handy, if semi-hidden, tool for those who choose to use it. If we are to sort it out, a good deal of the burden would need to fall on the RFC Editor... in particular, we would need to move significantly beyond the traditional "look at some recent RFCs and guess what we want" form of specification/documentation (as well as the "use simple nroff forms, but we don't really want to tell you what to you" tradition). (3) 2629bis and xml2rfc are, as might be predicted from the name, perhaps more suitable for generating RFCs than for generating ongoing, work-in-progress, forms of I-Ds. While one can fuss with comments and trick delimiters to simulate part of the functionality, there are no good generational change-tracking or "note in draft" facilities that are desirable for, e.g., tracking an evolving specification being developed by a WG.
(4) While recent versions of 2629bis and xml2rfc have gotten _much_ better, there are things to be referenced, and forms of references, in RFCs that are not well and obviously supported in those tools. Again, this is partially an RFC Editor issue -- if there were a real style manual for preferred reference formats (in 2223bis or elsewhere) that moved significantly beyond some simple cases and handwaving or "look at some examples and then guess", I assume Marshall and his colleagues would rapidly move to support them.
The above points argue more or less strongly for using 2629bis and xml2rfc when authors find them appropriate. They don't do much to argue that posting the XML formats (even when available) for working-draft I-Ds would be significantly helpful (they argue more strongly for making the XML form of RFCs officially available, but there are separate and complex issues there, and it isn't what Brian proposed). Availability of XML format I-Ds would almost certainly be helpful if a document were being developed by a WG or other committee and people were asked to submit text in pre-formatted form. So would availability of MSWord or nroff formats if those were the "native" form being used by a document editor... at least to the extent that WG participants had easy access to the relevant formats, tools, and knowledge.
So I'm led to an even more modest suggestion than Brian's, at least as a first step:
Where a WG is developing a document, and the WG Chair(s) and/or Editor(s) conclude that availability of the XML (or nroff, or MSWord, or WordPerfect, or...) editing form of a document would be useful to the WG's work in addition to the ASCII-text-format I-D, they should make that happen. In many cases, the best mechanism for making such a working draft available is probably a link from a WG home page to the document itself but, when appropriate, the Chair or Editor may request that the editing form, as well as the text, Postscript, or PDF one, be placed in the I-D directory (and the Secretariat should honor that request). Whenever and however editing-format documents are made available outside editing teams, WG Chairs and Editors should be mindful of the importance of posted, sequentially-numbered, I-Ds as a means of marking WG progress and keeping WG work accessible to onlookers and new participants.
So...
(i) Submitters of individual documents, and documents outside the IETF standards-track and WG processes, are on their own. This approach (and Brian's) do mean more work for the Secretariat, and no case has been made that it would be worth the effort.
(ii) Availability of working drafts, in working/editing form, should not become a substitute for posting of I-Ds, no matter where those drafts are kept/ posted.
(iii) While I personally think that the other formats are less likely to be useful (or more controversial, or both), there is no strong reason to exclusively prefer XML as a posting format for working drafts. If the posting of working draft formats is useful, then, within some limits, document editors should be permitted to post whatever working draft formats are actually being used... as long as the ASCII text I-Ds remain available and accurate.
(iv) In order to reduce the likelihood of chaos, the number of variant forms of editing formats should be minimal and well-defined. If XML is to be permitted, it should conform to 2629bis (and it might be in the interest of the IETF and the proponents of that format to become more systematic and public about versioning of definitions and DTDs). If nroff is to be permitted, it should conform to a set of macros specified by the RFC Editor (or someone delegated by them). And so on. While we shouldn't expect the secretariat to police those rules, some procedure (ideally specified by the IESG without spending a lot of energy on it) would be appropriate by which a member of the community who notices a non-conformant format may request that it be removed.
john
--On Tuesday, 02 September, 2003 10:05 -0700 "Paul Hoffman / IMC" <phoffman@imc.org> wrote:
At 6:15 PM -0400 8/27/03, Rosen, Brian wrote:I therefore have a modest proposal:
Allow the submission of an xml file meeting the requirements of RFC2629 along with the text file (and optional ps file) for an Internet Draft.
You didn't say what the additional value would be. We know the additional value of a .ps file (drawings that don't translate to ASCII art). What is the value of XML? It certainly isn't searchability or readability.
--Paul Hoffman, Director --Internet Mail Consortium