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

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

From: Hutton, Andrew <andrew.hutton@unify.com>
Date: Mon, 28 Jul 2014 10:28:55 +0000
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E3737F@MCHP04MSX.global-ad.net>
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





> -----Original Message-----
> From: Hutton, Andrew [mailto:andrew.hutton@unify.com]
> 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).
> 
> 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:martin.thomson@gmail.com]
> > 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
> > <sergio.garcia.murillo@gmail.com> 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.

Received on Monday, 28 July 2014 10:29:19 UTC

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