RE: I-D Action: draft-ietf-httpbis-tunnel-protocol-00.txt

+ 1

> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Thursday, August 21, 2014 11:55 AM
> To: Adam Rice
> Cc: Mark Nottingham; Greg Wilkins; HTTP Working Group
> Subject: Re: I-D Action: draft-ietf-httpbis-tunnel-protocol-00.txt
> 
> On 20 August 2014 21:50, Adam Rice <ricea@google.com> wrote:
> > As a client, why would I add a header to my request that is going to cause
> > the proxy to block it? What is the benefit to the user?
> 
> I'm going to give a different answer to the one Amos gave.  You can
> read the background, including the recorded discussion from the last
> IETF meeting for more on the subject.
> 
> In WebRTC, browsers will do this because they want to be good network
> citizens and sometimes that means asking nicely.  Applications don't
> get that privilege.
> 
> And this isn't always about a block/don't block binary decision.
> Sometimes the information can let the proxy make better choices about
> how it treats the data.  Realtime media over these tunnels (the
> original motivating use case) has somewhat different requirements to
> other types of traffic.  Knowledge about applications can help the
> proxy make better decisions.
> 
> As I've said privately to others when the same point was raised, the
> use of cleartext markers in the context of intermediary blocking is a
> topic that was discussed at some length when the TLS working group
> chose ALPN over NPN.  We could re-run those arguments, and I'm sure
> that we'd have a ball in the process, but that's wasteful.  This
> document really doesn't change the dynamic at all.  If you choose not
> to send this, then send ALPN, then that's just forcing the proxy to do
> extra work to discover what you are doing (i.e., it looks at your TLS
> ClientHello once the tunnel is active).
> 
> If you are suppressing ALPN, then you suppress this too.  I don't
> think that's in question.

Received on Thursday, 21 August 2014 17:08:29 UTC