Re: [Gen-art] Gen-ART review of draft-ietf-httpbis-tunnel-protocol-04

[Jari Arkko <[e-mail]>]

Thanks for your review, Christer. Martin, is the ABNF now OK (even if not necessarily submitted as a new version)?

Jari

On 04 Jun 2015, at 07:50, Martin Thomson <[e-mail]> wrote:

> I apologize for missing this, it was badly filed.  Thanks for the
> comments.  Fresh eyes are always helpful here, and you identified lots
> of little pieces of potentially confusing text.
> 
> The changes will be in -05, but you can preview them on github:
> https://httpwg.github.io/http-extensions/tunnel-protocol.html
> 
> On 22 May 2015 at 01:26, Christer Holmberg
> <[e-mail]> wrote:
>> ALPN = "ALPN":" protocol-id *(COMMA protocol-id)
> 
> Julian has corrected this also.  The production that is used is
> described in RFC 7230, as referenced immediately before the rule.
> 
>> Are proxies prevented from implementing any tunneled protocol? If not,
>> should the text say “Proxies might not implement the tunneled protocol”?
> 
> They aren't really proxies when they implement the tunneled protocol,
> are they?  That's them taking off their proxy hat and putting on a
> <some other protocol> server hat (or maybe their MitM hat).
> 
> 
>> Do you need both sentences, or could they be combined into a single
>> sentence?
> 
> Good point.  It was a little redundant:
> https://github.com/httpwg/http-extensions/commit/fb18ad4
> 
>> “For a tunnel that is then secured using TLS [RFC5246], the header field
> 
>> I think it would be useful to add a reference to RFC 7301 after TLS
>> handshake:
>>              “…be carried within the TLS handshake [RFC7301].”
> 
> https://github.com/httpwg/http-extensions/commit/970b37f36
> 
>> What if TLS is NOT used?
> 
> No problem.  Application protocols can still have an identifier.  Note
> that we say "Other substrates could negotiate the application protocol
> differently." and also, later, have a whole section on the subject:
> https://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-04#section-2.3
> 
>> Who makes the choice of application protocol then?
> 
> That is not known.  The ALPN identifiers - if the proxy understands
> them - will probably have to include a definition that covers how the
> protocol is negotiated.  All the current ones do.
> 
>> What if the recipient does not support, or does not want to use, the
>> protocol(s) indicated by the client?
> 
> That's a little piece of necessary uncertainty.  Just as the proxy
> cannot rely on this header field being present, it cannot rely on the
> two peers actually negotiating the indicated protocol.  It can check,
> but TLS is (or will be) designed to make that hard.
> 
>> The text says that the ALPN header field will contain the protocol that will
>> be used within the tunnel.
>> 
>> I think “will” is wrong wording, as the recipient has the final saying on
>> what will be used. Later in the document the text says “intended to be
>> used”, and I think that would fit here too.
> 
> You are right:
> https://github.com/httpwg/http-extensions/commit/1bbe0aa4504
> 
>> “For a CONNECT tunnel that conveys a TLS session that in turn
>>              encapsulates another protocol,…”
>> 
>> The text is confusing. Shouldn’t it simply say “A tunnel that is secured
>> using TLS”, or something?
> 
> Yeah, it's a little overwrought.  How about:
> For a CONNECT tunnel that conveys a protocol secured with TLS
> https://github.com/httpwg/http-extensions/commit/3e470d644
> 
>> “When used in the ALPN header field, the ALPN identifier and registry
>>              are used…”
>> 
>> What is meant by “registry” here?
> 
> Yeah, that's a little confusing.
> How about: "When used in the ALPN header field, an ALPN identifier is used ..."
> https://github.com/httpwg/http-extensions/commit/cdf620a
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art