Re: Charter revision

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.

Received on Friday, 10 February 2012 09:10:55 UTC