Subject: RE: RFC-Editor 48-hour process (was: Input solicited: IETF problem pi npointing at the plenary?)

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 14 Nov 2002 14:02:59 -0600

One of my least favorite activities is trying to figure out what the difs between two formatted drafts are, because so many lines change simply because of formatting. If this proposal would make it easier to produce content difs, instead of format-and-content difs, I'd think that was a Good Thing.

Perhaps the True Cabal Members have the gift of quickly scanning difs and ignoring non-changes - but I don't know that secret handshake!

Spencer

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Thursday, November 14, 2002 1:39 PM
> To: Wijnen, Bert (Bert)
> Cc: [email-masked]
> Subject: Re: RFC-Editor 48-hour process (was: Input solicited: IETF
> problem pi npointing at the plenary?)
> 
> 
> 
> Actually, I've recently had a couple of good reasons why I
> needed to figure out when a change was introduced into an
> I-D that updates an RFC...
> 
> It might be good to use some sort of change control system
> (CVS is the best one I know of) to track changes in all
> WG work items, as well as in RFCs.
> 
> Margaret
> 
> 
> At 08:50 AM 11/14/02, Wijnen, Bert (Bert) wrote:
> >When discussing changes during the 48-hour author call from
> >the RFC-Editor, the following came up from a non-WG-chair.
> >I think it is a usefull idea to investigate.
> >
> >Juergen Schoenwaelder writes:
> >
> >   In fact, I believe the whole process could work much faster if we
> >   could apply normal software engineering practices by 
> making the RFC
> >   editor use a version control system such as CVS. This is 
> perhaps just
> >   dreaming - but it is kind of strange how much effort we 
> (I guess you)
> >   spend writing down edits in prose, checking whether the edits have
> >   been done correctly, or authors tracking RFC editor 
> changes back into
> >   their own sources and so on. The open source community has largely
> >   agreed on using CVS for that purpose and it seems to work 
> reasonably
> >   well. But yes, I am dreaming...
> >
> >Thanks,
> >Bert
> 
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 14 Nov 2002 16:22:58 -0500

> One of my least favorite activities is trying to figure out what the
> difs between two formatted drafts are, because so many lines change
> simply because of formatting. If this proposal would make it easier
> to produce content difs, instead of format-and-content difs, I'd
> think that was a Good Thing.

   http://www2.iro.umontreal.ca/~pinard/traiter.cgi/wdiff
   ftp.gnu.org/pub/gnu/wdiff/wdiff-0.5.tar.gz

I (and surely others) have scripts that strip off page headers and
trailers of documents and then run them through wdiff. Result is an
easy way to look only at text differences in documents (provided there
aren't too many, of course).

Thomas

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Nov 2002 22:30:05 +0100

> Perhaps the True Cabal Members have the gift of quickly scanning difs 
> and ignoring non-changes - but I don't know that secret handshake!

After only nine years in the IETF, I'm not a Cabal member yet, but I 
know the secret: Emacs (ediff-files and the * command work wonders).

CVS would make sense if we got to work on the *source*.  For RFCs, this 
means nroff, folks...

Gruesse, Carsten

---

From: Pat Calhoun <[email-masked]>
Date: 14 Nov 2002 14:00:51 -0500

> CVS would make sense if we got to work on the *source*.  For RFCs, this 

good point, and not everyone makes use of nroff. There are some folks
that insist on using the RFC word template :(

PatC

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 14 Nov 2002 15:12:35 -0800

I also agree it would be a good idea for the RFC editor to use some form of
version control.

I think we can do better than CVS, though. CVS has multiple well-known
deployment, security, and scalability problems.

As a WebDAV guy, my recommendation is to use Subversion
<http://subversion.tigris.org/>. It's very CVS-like in its command syntax
and use patterns, but scales much better (by leveraging the HTTP/DAV/DeltaV
infrastructure), and is much easier to administer (on the server side it's
just another Apache module). Client software exists for most computing
platforms. It's Open Source. Since Subversion builds on WebDAV/DeltaV, one
nice feature is that all documents automatically have URLs.

- Jim

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 15 Nov 2002 16:30:49 -0600

> good point, and not everyone makes use of nroff. There are 
> some folks that insist on using the RFC word template :(

And there are those who use Marshall's delightful xml2rfc, which IMHO
should be THE baseline tool used by the RFC editor and ALL AD authors.
There's something very nice about having semantically meaningful tags
that can be programatically processed in a draft. I don't even know that
we should archive the txt files anymore . . .

--
Dean

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 15 Nov 2002 15:02:57 -0800

While I agree with Dean that xml2rfc (which I use for all my IDs) is a 
delightful improvement over the other current alternatives, I wonder if 
we shouldn't try to move to something with more usage in the industry 
as a whole (say docbook for example).

thanks,
-rohan

---

From: Melinda Shore <[email-masked]>
Date: Fri, 15 Nov 2002 18:27:11 -0500

> as a whole (say docbook for example).

I'd like to put in a plug for allowing people to use the
tools they're most comfortable with and standardizing
instead on an output format, as we currently do.  I don't
see that forcing people to use a particular input format is
a win over forcing people to use a particular output
format.  (BTW, CVS can store binary files.)

Melinda

---

From: Marshall Rose <[email-masked]>
Date: Fri, 15 Nov 2002 17:08:51 -0800

> format.  (BTW, CVS can store binary files.)

well, the distinction between input and output formats is irrelevant providing
that the output format is revisable (or, if you prefer, reversable).

many would say that the problem is that the input format to the rfc editor is
either 2223 or nroff-ms, but that the output format is always 2223, which is not
reversable. hence, the OLD:/NEW: stuff on the .txt file instead of "diff -c" on
the .nr file.

certainly, people should use whatever they're comfortable with. the complaints i
hear aren't so much about the authoring as opposed to what comes later.

/mtr

---

From: Marshall Rose <[email-masked]>
Date: Fri, 15 Nov 2002 17:02:04 -0800

> we should archive the txt files anymore . . .

i guess i'll be sending you a card this christmas...

however, one thing folks need to keep in mind is that the rfc editor is
completely independent from the ietf. there are pluses and minuses to this,
obviously.

however, people wanting to make the ietf better probably should not spend too
much energy on suggesting changes to the rfc editor process because, frankly,
there aren't any levers/buttons/switches in the ietf that can be used to effect
those kind of changes.

/mtr