- From: Paul Hoffman <phoffman@imc.org>
- Date: Fri, 1 Jun 2007 12:20:43 -0700
- To: Apps Discuss <discuss@apps.ietf.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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.)
Received on Friday, 1 June 2007 19:21:03 UTC