W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com>
Date: Thu, 21 Aug 2014 17:08:00 +0000
To: Martin Thomson <martin.thomson@gmail.com>, Adam Rice <ricea@google.com>
CC: Mark Nottingham <mnot@mnot.net>, Greg Wilkins <gregw@intalio.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E523970@US70UWXCHMBA02.zam.alcatel-lucent.com>
+ 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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC