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 <martin.thom...@gmail.com> 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 > <christer.holmb...@ericsson.com> 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 > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
