Re: Straw-man charter for http-bis

[John C Klensin <[e-mail]>]

--On Friday, 01 June, 2007 19:51 +0200 Julian Reschke
<[e-mail]> 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