Re: Straw-man charter for http-bis

["Roy T. Fielding" <[e-mail]>]

Just to reiterate what I have said before, I think it is absurd to make
minor editorial modifications to RFC 2616 in a new revision.  If minor
editorial changes are necessary right now, the RFC editor can make them
with a simple set of instructions from the original authors.  However,
I don't see them as necessary -- the existing list of errata is
sufficient until such time as the more pressing security issues can
be resolved in other specifications.

The reason that RFC 2616 had so many editorial mistakes is because the
RFC became completely unreadable due to far too much committee-driven
discussion being added in the revision from 2068 to 2616.
If an actual revision is desired for HTTP/1.1, then a ground-up reorg
of the specification and formal ABNF productions are necessary.
I don't care if that matches "group consensus desires" or not;
sometimes the work needs to be done regardless of popular opinion.

What matters is not what work the working group is willing to embark
upon, but what work the group is willing to review at the end.  If I
completely rewrite the HTTP/1.1 specification without adding features,
and submit that new draft for review, will the working group consider
it to be out of scope?  If not, then limiting the scope of changes
to the specification (aside from not adding new features) is irrelevant
to the charter.  If it will be out of scope, then I have no interest
in participating here and will fork the standard to a place that
isn't being driven by a short-term corporate agenda.

If an IETF HTTP WG is to be recreated, then its task items should be
to create what the working group believes to be the best documents
to replace 2616 and 2617.  The charter does not need to constrain that.

In any case, the IESG has expressed many times that an application
protocol will not move forward without providing a required solution
for secure authentication.  Thus, it is foolish to start a 2616 revision
without first completing some form of 2617 revision, whether or not
that includes new features for HTTP.  That is not going to happen as
long as you guys are burning up all of the available HTTP reviewers'
time on irrelevant changes to 2616.


Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>