Code change:
2. <del> The following two use cases are considered: The WebRTC Client issues a HTTP CONNECT request to the HTTP proxy with the TURN server address in the Request URI. The WebRTC Client issues a HTTP CONNECT request to the HTTP proxy with the TCP address of a WebRTC peer in the Request URI.  This is used in the case of establishing ICE-TCP RFC6544 with a WebRTC Peer. 3. The client MAY include the Tunnel-Protocol Request Header field in a HTTP Connect request to indicate the application layer protocol </del> <ins> Clients include the Tunnel-Protocol Request Header field in a HTTP Connect request to indicate the application layer protocol used </ins> within the tunnel. <del> 3.1. </del> <ins> 2.1. </ins> Valid values for the protocol field are taken from the registry <del> established in I-D.ietf-tls-applayerprotoneg.  For the purposes of WebRTC, the values "webrtc" I-D.thomson-rtcweb-alpn and "turn" I- D.patil-tram-alpn are applicable. </del> <ins> established in I-D.ietf-tls-applayerprotoneg. </ins> <del> 3.2. </del> <ins> 2.2. </ins> The ABNF (Augmented Backus-Naur Form) syntax for the Tunnel-Protocol header field is given below.  It is based on the Generic Grammar defined in Section 2 of RFC7230. <del> Tunnel-Protocol = "Tunnel-Protocol":" protocol | protocol-extension </del> <ins> Tunnel-Protocol = "Tunnel-Protocol":" protocol-id </ins> <del> protocol = "webrtc" | "turn" </del> <ins> protocol-id = token ; percent-encoded ALPN protocol identifier </ins> <del> protocol-extension = token </del> <ins> ALPN protocol names are octet sequences with no additional constraints on format.  Octets not allowed in tokens (RFC7230, Section 3.2.6) must be percent-encoded as per Section 2.1 of RFC3986. Consequently, the octet representing the percent character "%" (hex 25) must be percent-encoded as well. </ins> <del> 3.3. </del> <ins> In order to have precisely one way to represent any ALPN protocol name, the following additional constraints apply: </ins> <del> The RTCWEB transports specification I-D.ietf-rtcweb-transports requires that a WebRTC client support the modes of TURN that uses TCP and TLS between the client and the TURN server in order to deal with firewalls blocking UDP traffic.  In the case where HTTP Connect is used to establish a tunnel to the TURN server the client SHOULD include the "Tunnel-Protocol" header field with the value "turn" I- D.patil-tram-alpn as shown in the example below. </del> <ins> Octets in the ALPN protocol must not be percent-encoded if they are valid token characters except "%", and </ins> <del> 3.4. </del> <ins> When using percent-encoding, uppercase hex digits must be used. </ins> <del> I-D.ietf-rtcweb-transports also requires that a WebRTC client support ICE-TCP RFC6544 as a mechanism to allow webrtc applications to communicate to peers with public IP addresses across UDP-blocking firewalls without using a TURN server.  In this case the client SHOULD include the "Tunnel-Protocol" header field with the value "webrtc" I-D.thomson-rtcweb-alpn as shown in the example below. </del> <ins> With these constraints, recipients can apply simple string comparison to match protocol identifiers. </ins> <del> Note: The protocol "c_webrtc" described in I-D.thomson-rtcweb-alpn is not relevent in this context and when used at the TLS layer the client SHOULD use "webrtc" in the Tunnel-Protocol header.  OPEN ISSUE - Is this correct? </del> <ins> For example: </ins> <del> 4. </del> <ins> 3. </ins> To Be Added <del> 5. </del> <ins> 4. </ins> In case of using HTTP CONNECT to a TURN server the security consideration of RFC7231, Section-4.3.6] apply.  It states that there

Related discussion:
text: 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?