- From: John C Klensin <john-ietf@jck.com>
- Date: Fri, 01 Jun 2007 18:06:15 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Apps Discuss <discuss@apps.ietf.org>
--On Friday, 01 June, 2007 19:51 +0200 Julian Reschke <julian.reschke@gmx.de> wrote: > Hi, > > I'd like to make one small comment with respect to the opinion > that maintaining an errata list (and potentially handing that > to the RFC Editor) would be sufficient. > > 1) Scott Lawrence' original errata list > (<http://purl.org/NET/http-errata> is excellent, but it hasn't > been maintained since 2004. So we needed to move somewhere > else. > > 2) Just collecting errata sounds nice in theory, but my > experience with spec writing is that you can't close a bug > until you have applied the suggested fix to the spec text. > Frequently, something that looks OK in isolation doesn't work > in the specification context. Thus my preference is not only > to collect errata and proposed resolutions, but to also have > them applied to a copy of the original spec (and have that up > for review for everybody). > > 3) Finally, looking at the amount of issues we have collected > in the meantime, I'd be really amazed if the RFC Editor would > be willing to take over the editorial work for updating the > document. I bet the answer would be: please submit an Internet > Draft. Let me add one thing to this, while more or less agreeing with Julian on this particular point (no comment yet about other issues). There are two types of errata. One type just clears up typographical and similar errors where the intent of the text is fairly clear. Those are trivial, the RFC Editor rarely has a problem with them, but it is not clear that they are worth a lot of effort. The second involves a substantive clarification or correction to the document, especially one that permits one way to do things and excludes one or more others that some people might have thought plausible. That second type really requires some explicit process of determining or verifying community consensus; it is not something the RFC Editor ought to be publishing as authoritative at the request of any one party, even if that party were an author of the original document (or the responsible AD at the time :-( ). 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. best regards, john
Received on Sunday, 3 June 2007 20:17:48 UTC