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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf