(Sorry for the top post)

 

As a proxy author this definition of a new header for CONNECT seems to be needless. What we do to detect a sub-protocol today is check the Upgrade: header value. It holds the name of the internal protocol(s).

 

The only different requirement this places on your spec is that senders must handle 101 status properly.

 

Use of Upgrade: header also resolves this protocol name confusion since the upgrade token has a clear requirement of being whichever wire protocol is directly wrapped.

 

Amos

 

From : Sergio Garcia Murillo
To : Martin Thomson;
Cc : HTTP Working Group;
Subject : Re: draft-hutton-httpbis-connect-protocol-00.txt
 
El 27/06/2014 18:35, Martin Thomson escribió:
> On 27 June 2014 02:50, Sergio Garcia Murillo
>  wrote:
>> If the protocol is ICE-TCP, why is it labeled as webrtc? Shouldn't it be
>> better, and most consistent to use "ice" as value instead?
>
> I think that's a point of confusion.  The intent is to do webrtc, or
> something that is compatible with webrtc.  ICE, and ICE-TCP, are just
> a small part of what is being done here.  ICE isn't inherently useful,
> after all.
Well, the fact is that you are tunneling an ICE-TCP connection over an 
HTTP CONNECT, so calling it "webrtc" sub protocol is quite misleading. 
Mainly because there is not such a thing as a webrtc protocol per se, 
and ICE-TCP may be used by non-webrtc applications.

Also, I think it is not coherent because you are calling "turn" 
subprotocol to TURN tunneled over an HTTP CONNECT. So, following your 
reasoning, you should call it "webrtc" , given that TURN isn't 
inherently useful, after all.

Best regards
Sergio