Re: XML2RFC submission (was Re: ASCII art)

I personally would welcome any pragmatic approach that maximizes the 
long-term usefulness of our output. I hope we have general agreement 
that a structured document format is better long-term than any 
unstructured, presentation-oriented format, be it ASCII, Word or PDF. 
The latter all lose information that then has to be manually added later 
or guessed, with some probability of error, by tools.
Beyond that, we can be pragmatic and rather than fight a small, but 
determined, minority, hope that almost all drafts will be available in a 
content-oriented format that can be easily transformed. That certainly 
beats another round of IETF list philosophy discussions and 0% availability.
As a community, we need to distinguish what works for the vast majority 
of contributors and for our "customers" (implementors, readers) from 
what's convenient for some subset of authors. Good organizations serve 
their customers and their long-term interests, not primarily the 
convenience of their own staff.
I'd much rather move now to some version of strong encouragement of XML 
submission. This encouragement can take multiple forms: For example, I 
see nothing wrong with a WG or area deciding that all of their WG drafts 
will be kept in XML, since they might value the long-term usability of 
their output. (Drafts now routinely cycle through "bis" stages and the 
original editor may not be the "bis" editor. Thus, having the 
convenience of the current editor outweigh the long-term cost to the 
working group just doesn't seem right.)
Summary of suggestions:

- Official statement of encouragement from the IESG that WG drafts 
submitted for IESG action SHOULD be in XML-RFC format when being 
submitted (but can be in any format the working group feels like and the 
I-D editor accepts during the early stages).
- Allow submission of XML-RFC format to the I-D editor, as part of the 
automation of that part of our process.
- (Semi-serious) Have an earlier IETF cut-off date for I-Ds in ASCII, 
since it takes longer to automatically check them for compliance. This 
will solve our format problem in one IETF round :-)
- Making XML-RFC versions of existing or new RFCs available to the public.


Henning



Spencer Dawkins wrote:
> (With some hesitation, but if we're discussing a specific proposal, I 
> guess this is more than just cycling)
>
> > I would find this problematic.  I often submit in the "final"
> > form because I started in the "final" form.  I have no *roff
> > or XML form to submit.
>
> Well, this can go a few different ways:
>
> - "the authors must submit XML2RFC or plain text", where what you submit 
> is what's used as the canonical source, or
> - We can assume that an author of any draft that genrates any interest 
> can dragoon someone among the thousands of IETF participants to spin 
> plain text as XML2RFC, at some point in time (note that we practice the 
> reverse art today; anyone wanting to modify a specification will often 
> start out with the plain text of an I-D or an RFC and reverse-engineer 
> it into XML2RFC, or into nroff, or into MS-Word, so the burden is 
> already "out there", and we're just talking about whether we inflict it 
> on the original author, or on subsequent authors), or
> - We can say that it's time to require XML2RFC for all drafts.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf