ietf
[Top] [All Lists]

Re: A modest proposal - allow the ID repository to hold xml

2003-09-03 11:33:31
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








<Prev in Thread] Current Thread [Next in Thread>