At 2:06 PM -0400 6/1/07, John C Klensin wrote:
>While I'm not sure I'd recommend it (in part for the reasons
>Julian identifies under (2) above), one could, in principle,
>prepare an I-D that was simply a listing of errata and
>discussion of ambiguities in the base spec, get rough consensus
>on that listing, and then ask the the IESG to process it and the
>RFC Editor to publish. That would be a little bit unusual, and
>would give the reader an extra, and separate, document to read,
>but I don't know of anything that would prohibit it procedurally.
In fact, there is a recent example of this very thing happening:
"IKEv2 Clarifications and Implementation Guidelines", RFC 4718. It is
about 50 pages of clarifications on RFC 4306. The process of
developing the spec went quite smoothly, and it really helped during
the first f2f interop event.
Based on the feedback we have gotten from developers, we are
preparing an IKEv2bis which is RFC 4718 mixed into RFC 4306. They
really wanted it all in one document. The draft for that is currently
expired, but will be revived in the very near future.
Note that some of the "clarifications" in RFC 4718 are in fact
technical changes that were realized after RFC 4306 was published. We
wiggly-worded them to sound like clarifications, but they are fixes
to things that are broken. I would be quite surprised if the authors
of an HTTP clarifications effort were not put into the exact same
situation.
From my experience with the IKEv2 document, I propose that you do a
clarifications-and-errata document first, get most of the way
through, then decide whether or not to do a bis document.
(I was tempted to change my From: line to my @vpnc.org address
because of the context, but I doubt the message would have gotten to
this mailing list if I had.)