Re: Straw-man charter for http-bis

[Keith Moore <[e-mail]>]

Julian Reschke 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.
>
> Best regards, Julian

My recommendation would be for the group to construct a list of errata
and get consensus on that list.  Each erratum should mention the
specific sections and text of RFC 2616 that it applies to, what the
problem is, and what changes are needed to fix the problem.

By the time the list is nearing completion, it should be apparent
whether it's worth the effort to revise the HTTP specification.  The
original errata list would still be useful, perhaps as an appendix,
because many implementors will just want to know what has changed.

My guess is that if the group sees its task as making a good
errata-and-fix list for 2616,  it will stay focused and finish in a
reasonable amount of time.  If at that point it is seen as appropriate
to actually update 2616, this will be a straightforward task which won't
take a lot of additional time.  (I do not propose that this task be
delegated to the RFC editor - the RFC editor function needs to stay
separate.)

On the other hand, if the working group sees its task as revising 2616,
the chance that it will take several years, dig into a dozen ratholes,
and create even more ambiguity than currently exists, is quite large.

Keith