Subject: HTTP Semantics in HTTP 2.0

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Jul 2012 12:10:34 -0700

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.

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.

regards,

Ted Hardie

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 Jul 2012 10:21:54 +1000

Ted,

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

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 07:50:38 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>Treating HTTP/2.0 like this is only going to make this work longer and =
>deployment riskier.

... but also more likely.

We don't have a stick, we can only offer carrots.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.