Re: HTTP Semantics in HTTP 2.0

Ted,

On 20/07/2012, at 5:10 AM, Ted Hardie wrote:

> Reading through the discussion over the past few days, one of the
> things which struck me was that a disagreement about the level of
> compatibility we're aiming for seems to underly some of the more
> obvious disagreements.  In particular, I believe that there may be
> some disagreement about  what "* Compatibility with HTTP/1.1
> semantics" means in this context.
> 
> Speaking personally, I don't think that implies that we can't
> introduce new semantics, and I believe that this may be an important
> part of meeting some of the design goals which have been expressed.
> To take a trivial example, imagine that we decide that an important
> goal was allowing proxies and clients to explicitly share a session
> key negotiated for some transport, so that proxies did not have to act
> as back-to-back User-Agents in order to perform functions on behalf of
> the client.  That might require new semantics (I don't think anyone
> can squint hard enough to fit it into 407, but your mileage may vary).
> Whether it is a good idea or not, I don't think that's ruled out by
> "Compatibility with HTTP/1.1 semantics".  Adding semantics may, in
> other words, allow us to meet new design goals and re-balance specific
> trade-offs between those design goals and existing deployments.

Perhaps, but the bar is going to be very high. This is not an opportunity for people to add their hobby-horse extension to HTTP, or perform live experiments with protocol design at a global scale. 

In particular, I'm going to look very dimly upon proposals that could be defined as HTTP/1.x extensions*, because it begs the question of why it hasn't already been done, and why it can't be done as a parallel but separate effort to our work on the wire protocol.

I still see many people who look at HTTP/2.0 as an opportunity to leverage new functions into the Web stack, because (they presume) it's a carrot to convince the browsers / web sites to do something new. Treating HTTP/2.0 like this is only going to make this work longer and deployment riskier.

All of that said -- if we can get consensus on new semantics to help deliver on our charter (whose focus is on improving performance and security), that's great. This is NOT an invitation to debate new ideas endlessly, however.

* The major exception here being a new authentication scheme, as per our charter.

> I also remind folks that because we're working in the IETF, some of
> the design goals are set for us, by larger policies.  Mark reminded
> the group of the policies in BCP 61/RFC 3365.  I'd also like to point
> to RFC 2804.  Despite being 12 years old, it still guides the IETF
> policy on developing technologies which intercept communications
> without the knowledge and consent of the parties to the communication.


Thanks, that's equally relevant. Link: <http://www.ietf.org/rfc/rfc2804.txt>


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

Received on Friday, 20 July 2012 00:22:20 UTC