Re: Straw-man charter for http-bis

On 01/06/2007, at 5:10 AM, Roy T. Fielding wrote:

> 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.

I'm very aware of your feelings. I'm also aware of the pain that  
folks go through when they try to implement the current spec. Yes,  
some of that is caused by the organisation and committee-speak there,  
but much more is on very specific points where the spec is silent or  
misleading -- our issues list now has more than sixty issues. That  
this effort will help in those cases. No, it's not a magic pill, but  
a complete rewrite wouldn't be either, and it would have much less  
chance of success.

> 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.

Is your threat to attempt a fork of HTTP if you don't get your way a  
hypothetical, or something you're actually considering?

Also, on what do you base the accusation that this is being driven by  
"short-term corporate agendas?"

In any case, I don't think re-organising parts of the spec is off the  
table; indeed, it's already been discussed on a small scale. Re- 
writing the entire spec sentence-for-sentence is, in my opinion.

> 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.

That would be disruptive and unproductive. You may be willing to re- 
write HTTP from scratch, but the review requirements are much higher  
than required for what we're attempting (with step-by-step diffs, by  
the way).

Somehow, HTTP has been implemented and become one of the most widely- 
deployed application protocols today, despite your claims that the  
spec needs to be re-written from scratch. I don't hear *anyone* else  
saying that this necessary, or a realistic option.


> 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.

This concern has already been discussed extensively, and as of Prague  
we believe we have a workable solution.

Thanks,

--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 31 May 2007 21:16:06 UTC