Code change:
As discussed; a quick pass to trim down RTCweb stuff, etc.
This looks ok to me, NAME NAME does this look OK ?
Content looks good to me. , Martin Thomson EMAIL wrote:
Also looks good to me. Should I now merge the pull request and submit the draft?

Related discussion:
text: <del> HTTP Connect - Tunnel Protocol For WebRTC </del> <ins> The Tunnel-Protocol HTTP Request Header Field </ins> draft-ietf-httpbis-tunnel-protocol Abstract <del> This document describes a mechanism to enable HTTP Clients to provide an indication within a HTTP Connect request as to which protocol will be used within the tunnel established to the Server identified by the target resource.  The tunneled protocol is declared using the Tunnel- Protocol HTTP Request header field.  Label usage relating to the use of HTTP Connect by WebRTC clients (e.g. turn, webrtc) are described in this document. </del> <ins> This specification allows HTTP CONNECT requests to indicate what protocol will be used within the tunnel once established, using the Tunnel-Protocol request header field. </ins> 1. <del> The HTTP Connect method (Section 4.3.6 of RFC7231) requests that the recipient establish a tunnel to the destination origin server identified by the request-target and thereafter forward packets, in both directions, until the tunnel is closed.  Such tunnels are commonly used to create end-to-end virtual connections, through one or more proxies, which may then be secured using TLS (Transport Layer Security, RFC5246). The RTCWEB use cases and requirements document I-D.ietf-rtcweb-use- cases-and-requirements includes a requirement that a WebRTC Client must be able to send streams and data to a peer in the presence of Firewalls that only allow traffic via a HTTP Proxy, when Firewall policy allows WebRTC traffic.  To facilitate this and to allow such a HTTP Proxy to be provided with an indication that WebRTC related real-time media is to be included in the tunnel this specification defines the Tunnel-Protocol Request header field and associated labels.  This allows the proxy to identify the protocol being used in the tunnel as early as possible therefore enabling the proxy to make informed policy decisions.  The type of policy decisions the proxy may make is not specified here but may include rejecting the request with a HTTP status code responses or prioritizing connections.  As described in Section 4.3.6 of RFC7231 and 2xx response indicates consent for the client to switch to tunnel mode. The HTTP Tunnel-Protocol header field may be used in conjunction with and complements the application layer next protocol extension I- D.ietf-tls-applayerprotoneg specified for TLS RFC5246".  In the scenario where the HTTP Connect is used to establish a TLS tunnel then the HTTP Tunnel-Protocol may be used to carry the same next protocol label as carried within the TLS handshake.  However, the HTTP-Protocol is an indication rather a negotiation since the HTTP Proxy does not implement the tunneled protocol.  ALPN Labels are already defined for TURN in I-D.patil-tram-alpn and WebRTC I- D.thomson-rtcweb-alpn and are re-used here. </del> <ins> The HTTP CONNECT method (Section 4.3.6 of RFC7231) requests that the recipient establish a tunnel to the identified origin server and thereafter forward packets, in both directions, until the tunnel is closed.  Such tunnels are commonly used to create end-to-end virtual connections, through one or more proxies, which may then be secured using TLS (Transport Layer Security, RFC5246). The HTTP Tunnel-Protocol header field identifies the protocol that will be spoken within the tunnel, using the application layer next protocol identifier I-D.ietf-tls-applayerprotoneg specified for TLS RFC5246". When CONNECT is used to establish a TLS tunnel, the Tunnel-Protocol header field may be used to carry the same next protocol label as was carried within the TLS handshake.  However, the HTTP-Protocol is an indication rather a negotiation since HTTP proxies do not implement the tunneled protocol. </ins> 1.1.