Right. And I've heard authors gripe that they wrote their books with
state-of-the-art distributed systems and version control, but because
the publisher's typesetting was done on a different, incompatible
system, the copy-edit changes were not fed back into the authors'
system, making any second edition much more difficult.
AUTH48 is often quite prolonged and painful -- and I've experienced
this as an author, WG chair, and AD. Let's not make it any worse.
If by "worse" you mean I'll get back the vast majority of changes in the form
of a revised version of the XML file I handed in, which I can then edit and
send back, saving me hours of work retrofitting the changes into my copy, them
I'm for making this as "worse" as possible.
In my case at least this changes the first pass of AUTH48 to a simple
differences check-and-merge. I do these routinely, often on much larger
documents than any RFC I've written, and it is rare for the process to take
more than 15-20 minutes. (It does help to have sharp tools for this: BBEdit in
my case.) In contrast, the two recent RFCs I recently dealt with required
several hours of work apiece. That pushes things from an activity I can pretty
much squeeze in anywhere to one I have to budget time for, and that in turn
tends to stretch AUTH48 into the realm of AUTH96 or even more.
As long as the second pass doesn't involve wording changes I don't anticipate
it taking very long. I view layout as the RFC Editor's for the most part.
Bottom line: This will be a HUGE improvement for anyone that uses xml2rfc. I
would not be adverse to retaining the old process for RFCs submitted to the
editor as ASCII text, but holding xml2rfc users hostage to the old way of
working makes no sense whatsoever.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf