Subject: [rtcweb] rtcweb-transports, Suggested text for HTTP Connect usage.

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 19 Aug 2014 15:26:24 +0000

I promised in the Toronto meeting to provide suggested text for draft-ietf-rtcweb-transports once http://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00 was adopted so here goes.

My suggestion is to replace the following text in http://tools.ietf.org/html/draft-ietf-rtcweb-transports-06#section-3.4

   Further discussion of the interaction of WebRTC with firewalls is
   contained in [I-D.hutton-rtcweb-nat-firewall-considerations].  This
   document makes no requirements on interacting with HTTP proxies or
   HTTP proxy configuration methods.

   The WebRTC implementation MAY support accessing the Internet through
   an HTTP proxy.  If it does so, it MUST support the "connect" header
   as specified in [I-D.hutton-httpbis-connect-protocol].

With the following

"In order to deal with the scenario in which the media must traverse a HTTP Proxy then the HTTP Connect request (Section 4.3.6 of [RFC7231]<http://tools.ietf.org/html/rfc7231>) MUST be supported.  The HTTP Proxy may require authentication and therefore proxy authentication as described in (Section 4.3.6 of [RFC7231]<http://tools.ietf.org/html/rfc7231>) and [RFC7235] MUST also be supported. In addition the HTTP Connect MUST include an indication of the protocol being used with the HTTP Connect initiated tunnel as described in [I.D.draft-ietf-httpbis-tunnel-protocol]".

Note:  I don't intend to maintain or progress [I-D.hutton-rtcweb-nat-firewall-considerations].

Regards
Andy

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 19 Aug 2014 17:35:21 +0000

<Raju>
> ... In addition the HTTP Connect MUST include an indication of the protocol being...

Is the tunnel indication in CONNECT a "MUST"? or Can it be changed to "SHOULD"?
The reason is, though typically unrecognized HTTP headers are ignored, what if some proxies are sensitive to HTTP CONNECT's  unrecognized headers? In such a case excluding this header may just work fine.

</Raju>

BR
Raju

---

From: Martin Thomson <[email-masked]>
Date: Tue, 19 Aug 2014 11:40:23 -0700

On 19 August 2014 08:26, Hutton, Andrew <[email-masked]> wrote:
> “In order to deal with the scenario in which the media must traverse a HTTP
> Proxy then the HTTP Connect request (Section 4.3.6 of [RFC7231]) MUST be
> supported.  The HTTP Proxy may require authentication and therefore proxy
> authentication as described in (Section 4.3.6 of [RFC7231]) and [RFC7235]
> MUST also be supported. In addition the HTTP Connect MUST include an
> indication of the protocol being used with the HTTP Connect initiated tunnel
> as described in [I.D.draft-ietf-httpbis-tunnel-protocol]”.

s/HTTP Connect/HTTP CONNECT/g

Use of lowercase "must" and "may require" are playing 2119 bingo,
maybe consider alternative words.

Making this mandatory on all endpoints is mainly just unnecessary.  As
we've seen, browsers are going to do this anyway because the economics
makes sense.  I don't see any reason to extend that mandate.  It's a
lot of work for a non-browser, for a relatively small gain.  I could
settle for SHOULD.

I think that putting a MUST on proxy authentication is a little of a
stretch for the same reasons that the traversal using CONNECT needs to
be MAY.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 20 Aug 2014 10:13:05 +0000

> s/HTTP Connect/HTTP CONNECT/g

Ok thanks.

> maybe consider alternative words.

Agreed will suggest alternatives.

> lot of work for a non-browser, for a relatively small gain.  I could

The aim is to get consistent behavior from browsers so making it mandatory for WebRTC browsers seems the best option for me.  I agree that there are other things (WebRTC Devices/Endpoints or whatever they are called) may not need to do this so is this a case for differentiating between browsers and devices? 

> stretch for the same reasons that the traversal using CONNECT needs to

Again my argument is that consistent browser behavior is needed here and if browsers implement HTTP CONNECT then I believe they MUST also implement authentication. Does that make sense?

Andy

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 20 Aug 2014 10:26:24 +0000

>The reason is, though typically unrecognized HTTP headers are ignored, what if some proxies are sensitive to >HTTP CONNECT's  unrecognized headers? In such a case excluding this header may just work fine.
>
></Raju>

The consensus during the RTCWEB interim meeting in May was to my understanding that this needed to be a MUST so that proxies are told that the tunnel will contain real-time media. My opinion is that we need browsers to be consistent and this overrides the need to cater for broken proxies.