Re: Reorganising RFC2616 [was: Revising RFC2616 - what's happening]

On Oct 20, 2006, at 2:36 PM, Mark Nottingham wrote:
> On 2006/10/20, at 11:55 AM, Roy T. Fielding wrote:
>
>> If that is what the community wanted, people would have reviewed  
>> Jim's draft.
>
> The community of HTTP  implementors today is different than it was  
> in either 2003 or 1999. I think many implementers don't have the  
> context of the WG at the time of publication, and are confused by  
> the assumptions baked into the document. Many of the problems that  
> people are tripping across could be fixed by a few extra words, not  
> a wholesale re-org.
>
> Furthermore, from what I understand there were a number of long- 
> running disagreements that were buried in the interest of getting  
> 2616 out. While it might be easier for you if you were given carte  
> blanche to re-write HTTP, I'm not convinced those disagreements  
> wouldn't resurface, dragging out the process considerably, or  
> causing the effort to fail.

I am sure that they would resurface, assuming that the same people  
hadn't
changed their minds given implementation experience, but they can be  
resolved
via the usual working group consensus process if the chair has the will
to enforce it.  That means nothing goes in the draft until it is proven
to be implemented, anything that wasn't implemented (aside from open
extensibility provisions) gets removed, and consensus is determined by
the implementations rather than just the number of opinions.

The biggest unresolved issue between the editors was whether to call
the payload a "representation" (as I had been doing for ages) or  
"instance"
as desired by Jeff Mogul.  We had good reasons for disagreeing, and Jim
decided not to use either, so that is all that can be said about it.
You know exactly what I would call it if I rewrote the spec.

> Those are the concerns that I have. If people want a drastic re- 
> org, it's achievable in a bounded amount of time, and there are  
> enough people willing to do the work, great (personally, I've  
> always wanted to see a more comprehensive, clearly organised  
> document). However, so far only you and Bjoern have expressed  
> interest in doing that now. OTOH, much of the feedback that I got  
> when floating the idea of revising 2616 was concerned with  
> overambition. An apt quote is "the enemy of the good is the perfect."
>
> Roy, perhaps it would be helpful if you gave a sketch of the  
> changes you have in mind, so that people have a better idea of what  
> we're talking about here, and get a broader public response.

As I said on March 6, 2006:

>> On Mar 6, 2006, at 10:39 AM, Jim Gettys wrote:
>>
>>> Still doesn't solve the problem of getting people to *read* and  
>>> *verify*
>>> the results, which is the fundamental sticking point, IMHO.  So  
>>> far, no
>>> promises from anyone I've heard.
>>
>> It isn't worth the effort.  The minimum tasks for an update include
>> re-specifying the grammar using the now-standard IETF BNF notation  
>> and
>> the RFC 3986 rules for URIs, and then split the specification into
>> readable drafts on message syntax, http/https URIs, caching, and
>> content negotiation.  I don't see that happening any time soon, since
>> it makes more sense to let MIME be updated first.

Nothing has changed between then and now.

>> It is ridiculous that we have to waste our time reviewing an  
>> unreadable document.
>
> I'm a little surprised by that.
>
> If you've already implemented 2616, and a diff to the new document  
> is small, it should be simple to find any changes that you need to  
> make. However, if the document is radically different, it seems  
> that you'd need to evaluate the new spec line-by-line to verify  
> that you're conformant.

The minimal changes will end up changing every line of BNF, so your
theory about this revision being identifiable from the diffs will
not be true.

Have I implemented 2616?  Why do you think there were so many editorial
mistakes, like entire paragraphs missing their first character, when  
2616
was submitted to the RFC editor?  Why do you think the RFC editor didn't
find those errors before publication?  The answer to all of those  
questions
is that NOBODY, not even the document authors, read the final submission
sufficiently to notice anything -- our eyes glazed over before we got  
that
far in the spec.  It was simply too big and the timing was wrong and the
whole "minor fixes for update to Draft Standard" was rushed through,  
while
I was trying to advance to candidacy, because any real editorial effort
was considered "too risky".

> Certainly, the changes need to be weighed for interactions with the  
> rest of the document, but that's true in either case. Are you  
> saying that the document is so unintelligible as to justify the  
> effort of coming to consensus on a whole new formulation (see above)?

Yes!  I've been saying that since 1998, ever since section 13 was added
with 25 pages of very obscure and hard to read requirements.

....Roy

Received on Friday, 20 October 2006 23:55:58 UTC