> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf