Re: XML2RFC submission (was Re: ASCII art)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]