Re: Straw-man charter for http-bis

On 01/06/2007, at 12:25 PM, Roy T. Fielding wrote:

Taking a stab at what that might look like in 2616 terms:

> I am talking about splitting the document into
>
>    messaging

4, 5, 6, 7, 9, 10, various parts of 3, parts of the relevant header  
defs in 14

>    conditional requests and range requests

3.12, parts of 10.3.5 and 10.2.7, parts of the relevant header defs  
in 14

>    caching and cache control

13, parts of the relevant header defs in 14

>    content negotiation

12, parts of the relevant header defs in 14

>    http and https URIs

3.2

>    HTTP implementation guide for TCP transports

8, parts of the relevant header defs in 14

> to go along with
>
>    authentication and access control

11, parts of the relevant header defs in 14

Is that in the ballpark? Couple of questions;

1) If going down this path, my intuition would be to continue having  
sections dedicated to lists of headers, status codes, methods, etc.,  
but to limit them to syntax and base semantics, while pushing the  
protocol-related parts (e.g., the mechanics of caching, conditional  
requests, etc.) into the separate sections. Is that what you had in  
mind?

2) With the exception of the impact of (1), the above seems like  
relatively straightforward rearrangement. Did you just have  
rearrangement in mind (perhaps with new introductory text), or did  
you want deeper changes?

> and then replacing the BNF with ABNF

Already on the table.

> removing the (relatively few)
> parts of the document that specify server implementation instead of
> interface requirements in the method definitions

Could you please raise this as an issue when you get a chance? I  
think I know what you're talking about, but examples and proposals  
would be helpful.

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

Chicago's cutoff for -00 drafts is July 2; could you have an initial  
draft by then, perhaps just doing the rearrangement and leaving ABNF  
and errata until later? Something to give people even a rough idea of  
what you were talking about would be very helpful.

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

My personal preference would be to make a decision beforehand; a well- 
scoped charter can be frustrating, but it can also prevent many  
ratholes. Knowing what they're getting into raises people's comfort  
level considerably.

If you can get a draft in before Chicago, we could discuss it there  
and either get them built into the WG's scope, or decide that they're  
already within it, or even base the charter on your document.

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

That makes it seem that you're thinking of something more substantial  
than a straight rearrangement.

One more question (not necessarily for Roy): at what point does  
rewrite/rearrangement affect the transition from Proposed to Draft?

--
Mark Nottingham     http://www.mnot.net/

Received on Friday, 1 June 2007 04:19:44 UTC