Re: Straw-man charter for http-bis

On May 31, 2007, at 2:15 PM, Mark Nottingham wrote:
> 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?

It is not "if I don't get my way".  Who appointed you to be the
determinant of group consensus in the first place?  I am not going
to support an IETF working group that says "nobody is allowed
to do a better job describing HTTP than what is in our charter."
If you don't allow people to produce drafts, and allow the working
group to evaluate those drafts on the basis of whether the contents
are better or not, then all you are doing is dictating the content
of the specification based upon some imagined position of authority.

So, you should decide whether your work item is to replace 2616
or to produce a list of errata to be published in RFC form.  If it
is the former, than I know a lot more about this subject than you
and I know for a fact that just making small changes around the
edges is not sufficient.  We already tried that twice.

If I make the real changes that are needed in draft form and submit
them to the WG, then I will expect them to be evaluated without bias
or the WG to be closed.  If the answer is "that's too much
for me to review, so you aren't allowed to do that in the IETF"
then I won't.  I will do it elsewhere and the IETF specification
will become irrelevant.

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

On the basis that you presuppose every work item as being limited
to what you want to do, rather than a task that can be accomplished
if someone does it, and the continual reference to vendors and
"developers" that never actually show themselves on this list.

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

In your opinion.  You chose to ignore mine, in spite of the fact that
I have a bit of history on the subject, and that is why I have to make
comments on these proposals.

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

I don't hear anyone else saying that 2616 needs to be revised before
2617, yet you continue to take that as an assumption.  2616 doesn't
*need* to be revised at all.  2617 desperately does need to in order
to meet the IESG requirements.  Why is that unclear?

I do not desire a revision on 2616.  However, if a revision is called
for, then the minimum revision is something that can be reviewed
in its entirety.  That was not the case for 2616, and certainly won't
be the case for the patchwork of issues you have collected so far.

....Roy

Received on Thursday, 31 May 2007 22:59:05 UTC