Re: Charter revision

PHK,

This is a detailed work plan, not a way to find agreement on an approach (which is what many people -- including you -- have said they want). 

If you have an approach that you think will gain consensus, you're welcome to submit it under the new charter.

Regards,


On 10/02/2012, at 8:10 PM, Poul-Henning Kamp wrote:

> In message <D0E5F9D3-9827-4228-B101-39705918132F@mnot.net>, Mark Nottingham wri
> tes:
> 
>> Based on the feedback I've seen on-list and discussions with folks about 
>> it, I've revised the proposal for our new charter; see below. Please 
>> provide timely feedback; I'd like to get this to the IESG soon.
> 
> Here is a counter-proposal, which takes a different approach:
> 
>    1. Define the minimal transport primitives all HTTP/2.0 transport
> 	protocols SHALL offer.
> 
> 	Something like:
> 		Client sends request consisting of:
> 			Primitive (GET/PUT/POST)
> 			Content-metadata (headers)
> 			Content-body (zero or more bytes)
> 		Server returns response consisting of:
> 			Response (%03d)
> 			Content-metadata (headers)
> 			Content-body (zero or more bytes)
> 
> 	This in effect turns a HTTP request into a high-level IP
> 	datagram giving the same fundamental advantage that every
> 	transport from HTTP-over-stone-tablets and up will work.
> 
>    2. Define how to deal with transport "value add"
> 
> 	By "value-add" I'm thinking of stuff like:
> 	   Indication of assumed Session-membership
> 	   Indication of assumed Identity (X-Forward-for)
> 	   Transparency Guarantee (ie: level of guarantee content is unmolested)
> 	   Privacy Guarantee (ie: level of guarantee nobody saw the content)
> 	   Authentification Guarantee (ie: level of guarantee we know who it is)
> 	   Indicative delivery (ie: chunked encoding + optional final status)
> 	   Bandwidth/RTT estimate
> 	   Reverse transactions (server push) (This may need #1 text)
> 	   etc.
> 
> 	I would deal with these by:
> 	1) creating a registry for them,
> 	2) defining transport primitives to request, indicate and
> 	   explore their availability end-to-end.  (TELNET's
> 	   do/dont/will/wont model comes to mind)
> 
>    3. Publish "HTTP/2.0 Transport primitives" with the above definitions
> 
>    4. Draw a red line through the HTTP/1.1bis documents, to separate
> 	transport from semantics.
> 
>    5. Publish "HTTP/2.0 semantics" With the lefthand side of the red line.
> 	Possibly only as a document which "blackens out" the transport
> 	parts of HTTP/1.1bis by cross reference.
> 
>    6. Create a HTTP/2.0 transport protocol registry.
> 
>    7. Publish "HTTP/2.0 basic transport" which righthand side of the red line.
> 	This is the HTTP/1.1 style HTTP/2.0 transport, which SHALL be
> 	very easy to implement for any working HTTP/1.1 code base.
> 	This doc also defines how one upgrades a HTTP/1.1 TCP connection to
> 	any TCP based HTTP/2.0 transport protocol from the transport registry.
> 
>    6. Publish "HTTP/pre2 vs. HTTP/2.0 interoperability" which defines;
> 
> 	a) how to move/map HTTP/1.1 content to HTTP/2.0 transports 
> 	b) how to move/map HTTP/2.0 content to HTTP/1.1 transports 
> 
>    7. Open the floodgates to standardizing other transport protocols.
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

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

Received on Friday, 10 February 2012 10:49:18 UTC