Paul and Brian,
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(_at_)imc(_dot_)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