W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 21 Oct 2006 10:58:09 +0200
Message-ID: <4539E121.6060605@gmx.de>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Mark Nottingham <mnot@mnot.net>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>

Roy T. Fielding schrieb:
> ...
> 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.

Speaking of which, *is* there any activity with the goal of updating MIME?

Anyway, I don't think doing the other updates is a waste of time. It 
reduces the work left to do once MIME is updated.

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

The current draft has all RFC2616-style BNF fragments marked up as such 
(in the XML source).

I would imagine the activity to update the BNFs to go like this:

- use automated tools to extract all the BNFs, and produce parse trees 
for them (in some ASCII format suitable for diffing) -- if while doing 
this we find problems, fix them

- discuss how to translate to RFC4234-compliant ABNFs, in particular 
whether to keep the "#" extension (see 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.1.p.9>) - I 
would assume we do to keep stuff readable

- do the conversion, then run a similar set of tools against the new 
version, comparing the parse trees

Sounds like a good activity for the upcoming weeks where we can't 
publish any new drafts anyway...

> 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

I think you're overstating the problem here. I'm not aware of any such 
problem, except the one reported in 
<http://skrb.org/ietf/http_errata.html#msg-len-chars>, which was about 
exactly one paragraph. If there are more problems like this, please 
report them.

> ...

Best regards, Julian
Received on Saturday, 21 October 2006 08:58:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:40 UTC