- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Thu, 31 May 2007 19:25:12 -0700
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Apps Discuss <discuss@apps.ietf.org>, Robert Sayre <sayrer@gmail.com>
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 messaging 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. ....Roy
Received on Friday, 1 June 2007 02:25:05 UTC