On Fri, Nov 18, 2005 at 09:13:33AM +0100, Juergen Schoenwaelder wrote:
On Thu, Nov 17, 2005 at 09:22:10AM -0800, Ted Faber wrote:
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
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
Clarification #1: I believe the IETF (tools team perhaps) should
provide version control services (again I favour SVN over CVS but that
is an implementation detail) for WGs who _want_ to use it. Much like
xml2rfc is out there for authors/editors who _want_ to use it.
I think we agree on that. In fact I think we're in general agreement,
but some of the details differ.
request that the RFC editor will accept xml2rfc as an input format.
I thought they did take it as a supplement or something, which I hope
indicates that they are considering moving to it.
See also Bert Wijnen's early copy editing experiment where they seem
to have used xml2rfc successfully for copy editing. In other words,
the proposal is not to force people who strongly believe in other
tools to use xml2rfc or the repository. However, I believe having
support for xml2rfc plus revision will be a big step for the community
which already uses the xml2rfc format and is kind of happy with it.
I agree that this is a great goal. But there are certainly going to be
people who are not going to do it. I dunno why either - the advantages
seem considerable and obvious to me, too.
BTW, does the RFC editor have a record which typesetting system has
recently been used to produce the documents that end up on his desk?
I don't know. They (the RFC Editor is many people, many of whom aren't
he's :-)) may not get that information at all. I agree it would be
interesting to know.
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.
Clarification #2: I did not think of open source documentation - I was
referring to the source code itself. I believe there is no fundamental
difference between the production of source code and technical
specification when it comes to the importance of change management,
style guides, bug tracking and long term evolution and maintenance of
revision history. In other words, I believe that an IETF WG needs
almost exactly the same tool chain, namely agreement on common
formats, revision control, bug tracking.
Again, in the big picture we agree. The IETF needs to keep track of
document revisions, bugs (outstanding issues), and produce consistent
I think that RFC formats and the RFC editor do establish a style guide.
I don't think you like the style that's being enforced, but I think
there is a (fairly consistent) style in force. xml2rfc on the front end
and the backend idnits checker from the tools team help automate
following that style. They're collectively indent(1) Or maybe lint(1)
I think the bug tracking is addressed significantly by the issue
tracker. Specs and implementations aren't the same and I don't think a
bug tracker with trouble tickets and all that is really what we need,
but I could be convinced. I'm curious if you think the issue tracker
tool needs extending or scrapping.
I do agree that fine grained source control would be nice and if the
IETF wants to run a community source control system, I think that
would be a valuable resource. I'm cautious that there might be a morass
here in picking the system, but if someone on the tools team just does
it, that may avoid the rathole simply.
Sorry if I misrepresented your position earlier.
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
Description: PGP signature
Ietf mailing list