On Thu, Nov 17, 2005 at 09:25:03AM +0100, Juergen Schoenwaelder wrote: > On Wed, Nov 16, 2005 at 09:45:00AM -0800, Ted Faber wrote: > > > WRT revision control software on I-Ds, I think it's an excellent idea, > > but authors should use whatever they agree on. IMHO, the IETF doesn't > > need to provide a system. CVS vs. RCS vs. subversion vs. $DIETY knows > > what is too much of a mess to wade into for the benefit. > > I strongly disagree. I fact, I would love if the IETF could settle on > a system and in the long term, even the RFC editor would just use it. > It will make my life much easier if I do not have to manually track > changes applied by the RFC editor to put them back into my version > controlled repository so that the editorial fixes are not lost when > the ID is up for revision. Net me be clear - that's a great goal. I'd like to see that, too. If we could convince everyone to use CVS and XML2RFC that would be a nice straightforward way to get there. But people use a wide variety of authoring tools (I'd like to call them editors, but lumping vi in with MS Word seems to cover too big a space) and to a lesser extent revision control tools. There are people writing RFCs in Word, latex, XML2RFC, groff (yay!), and plain ASCII. Asking the RFC editor to make changes in all those formats and CVS them seems to put a lot of strain on an already overburdened group. Getting anyone to change their authoring tool is difficult, so hoping for standardization on CVS input is pretty unlikely. In my experience, IETF contributors are an order of magnitude more stubborn than most authors, but even if that estimate's wrong, I think there's a lot of inertia here. One way forward is to put the CVS/RFC2XML system up and hope people migrate for the advantages. I'm not optimistic, though I happily use both tools. > > It seems that the open source community much better understands what > it means to edit documents and how important it is to even agree on > style guidelines in order to be efficient. The IETF is really in the > stone age as an organization in this respect. I'm amazed at a comparison between the documentation in the open source community and the document series produced by the IETF that's anything but unfavorable to open source. Again, let me be precise: I love, produce, use and delight in open source software. I've even documented some. But as a whole, saying that open source documentation is no great model of clarity, completeness, consistency or even presence is being very polite. Software is documented in manpages, html, info, ASCII, javadoc, postscript, individual program help formats, and $DIETY knows what else. When I install a new piece of open source software I don't know *if* there will be documentation, let alone what I'll need to read it. Quality and clarity of the docs is largely based on the implementor's skill and time, both of which vary wildly. Before you suggest that some individual Open Source projects are very standardized in how they document: I agree and appreciate the good ones. But you should consider the difference in scale between the IETF and most open source projects. (IETF: scale 'r' us) For any IETF standard I know there will be a reasonably edited, ASCII document (or six) that will lay out the operation for me. I know where to go to look for updates to that document and know that the version I have in front of me is authoritative, even if I haven't checked it out of CVS recently. I even have some hope that it will be written in clear English - probably clear enough to read even if I'm a non-native speaker. It's perfectly reasonable to talk about improving the IETF publication process. It's even productive - IMHO XML2RFC is a significant improvement that I hope becomes a de facto standard for producing and editing RFCs. But let's neither lose sight of the significant benefits of the current process nor lose those benefits in a rush to improvement. The current process didn't just happen. It is the process of design decisions. Those decisions and the goals they're based on must be subject to constant evaluation and revision, but the RFC publication process isn't the way it is entirely by happenstance. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
Attachment:
pgpa05YtMkaqK.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf