HTTP Semantics in HTTP 2.0

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

Received on Thursday, 19 July 2012 19:11:01 UTC