W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

Re: Straw-man charter for http-bis

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 31 May 2007 19:25:12 -0700
Message-Id: <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Apps Discuss <discuss@apps.ietf.org>, Robert Sayre <sayrer@gmail.com>
To: Mark Nottingham <mnot@mnot.net>

On May 31, 2007, at 6:12 PM, Mark Nottingham wrote:
> On 01/06/2007, at 11:04 AM, Robert Sayre wrote:
>> I don't understand why the two approaches are mutually exclusive. I
>> think the best way to start is by doing exactly what has been done so
>> far. I agree with Roy that we shouldn't rule out large scale
>> restructuring at some point, but it might be better to let everyone
>> look at a few rounds of diffs before any major structural changes are
>> made. The issues list is already getting a little big.
> Agreed. As I said earlier, we've already talked about rearranging  
> sections, and maybe rewriting parts of the caching section.
> Perhaps we're just talking past each other -- Roy, are you really  
> talking about a wholesale rewrite, or rearranging parts, or what?  
> If you gave us an idea of what you want to do, it might help make  
> this discussion more productive.

I am talking about splitting the document into

    conditional requests and range requests
    caching and cache control
    content negotiation
    http and https URIs
    HTTP implementation guide for TCP transports

to go along with

    authentication and access control

and then replacing the BNF with ABNF, removing the (relatively few)
parts of the document that specify server implementation instead of
interface requirements in the method definitions, and fixing the
errata already identified.  I can do that in late July and then
publish one draft each per month until it is done.

Note that there are many other things that *could* be changed,
such as eliminating line-folding from the header definitions for
HTTP over TCP, but that would not be part of making the document
reviewable again.  Other things will probably be revealed once
I am forced to actually read the existing text, line-by-line.
Any changes that I make would be visible because I would use a
public subversion repository to make them.

If, for some unforeseen reason, I am unable to make those drafts
happen, then nothing on your charter schedule needs to change.
If the WG chooses not to adopt the changed drafts after they
have been reviewed, then so be it.  I just don't want to burn
the time editing the drafts only to have someone declare
discussion of them to be out of scope.

BTW, structural changes have to be done first, using 2616 as
the basis.  There is no point of reviewing diffs of 2616 when
nobody bothers to read 2616 as a whole.  Diffs after restructuring
can then be viewed in their proper context, with all of the relevant
requirements in the same comprehensible space.

Received on Friday, 1 June 2007 02:25:05 UTC

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