Subject: RE: draft-hutton-httpbis-connect-protocol-00.txt

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 1 Jul 2014 14:33:13 +0000

Thanks for the feedback.

I think the question that needs to be answered is what does the proxy really need to know if it is going to make some policy decision based on what is in this header.

It me be that the fact that the application is using TURN or ICE-TCP to connect to a WebRTC peer is irrelevant to the proxy and that what is really relevant is that "WebRTC" is the application. This tells the proxy something about what it can expect within the tunnel (I.e. real-time media).

I that case I would probably support a single token for "webrtc".

For some non WebRTC applications it maybe that "turn" is a generic label that is useful to indicate to the proxy that what to expect within the tunnel but maybe that should not be within the scope of this draft.

I would be ok with "Tunneled-Application" if the consensus is that that is better.

Regards
Andy

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: 30 June 2014 17:19
> To: Sergio Garcia Murillo
> Cc: HTTP Working Group
> Subject: Re: draft-hutton-httpbis-connect-protocol-00.txt
> 
> On 30 June 2014 02:29, Sergio Garcia Murillo
> <[email-masked]> wrote:
> > In case of using just one token (i.e. "webrtc"), then I think what is
> > misleading for me is the header name. IMHO if we are talking about
> > protocols, they are ice and turn, if we are talking about webrtc,
> then it is
> > something different. How about Tunneled-Application or
> > Tunneled-Application-Protocol?
> 
> It's still a protocol.  But I have no objection to the former, some
> small objection to the latter, but only with respect to verbosity.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 28 Jul 2014 10:28:55 +0000

Thanks to everybody who provided feedback on this draft during the session in Toronto last week.

During the following RTCWEB session in Toronto we discussed referencing this draft in http://tools.ietf.org/html/draft-ietf-rtcweb-transports-05 and it looks like RTCWEB has consensus to do this as long as HTTPBis intends to adopt the draft.

So I would like to understand what needs to be done to move this forward in HTTPBis.

It seems that the concept of including an indication that the application/protocol is WebRTC and therefore the proxy can expect real-time media in the tunnel is accepted but there are some open issues around the name of the header and exactly what labels to use.

I personally would be ok with the header name being either "Tunneled-Application" or "Tunnel-Protocol" and that for webrtc purposes a single label "webrtc" taken from http://tools.ietf.org/html/draft-ietf-rtcweb-alpn-00 would be ok. Note the -rtcweb-alpn- draft was adopted by RTCWEB last week.

Regards
Andy

> From: Hutton, Andrew [mailto:[email-masked]]
> Sent: 01 July 2014 15:33
> To: Martin Thomson; Sergio Garcia Murillo
> Cc: HTTP Working Group
> Subject: RE: draft-hutton-httpbis-connect-protocol-00.txt
> 
> Thanks for the feedback.
> 
> I think the question that needs to be answered is what does the proxy
> really need to know if it is going to make some policy decision based
> on what is in this header.
> 
> It me be that the fact that the application is using TURN or ICE-TCP to
> connect to a WebRTC peer is irrelevant to the proxy and that what is
> really relevant is that "WebRTC" is the application. This tells the
> proxy something about what it can expect within the tunnel (I.e. real-
> time media).
> 
> For some non WebRTC applications it maybe that "turn" is a generic
> label that is useful to indicate to the proxy that what to expect
> within the tunnel but maybe that should not be within the scope of this
> draft.
>