- From: Eliot Lear <lear@cisco.com>
- Date: Thu, 29 May 2014 18:57:45 +0200
- To: Martin Thomson <martin.thomson@gmail.com>, Matthew Kerwin <matthew@kerwin.net.au>
- CC: Willy Tarreau <w@1wt.eu>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Martin, On 5/29/14, 6:24 PM, Martin Thomson wrote: > On 29 May 2014 00:36, Matthew Kerwin <matthew@kerwin.net.au> wrote: >> Perhaps it would be better to use h2f for failsafe mode, to make it clear >> that h2 is the benchmark, and h2f is an acceptable variant/subset. It's more >> of an all-or-nothing approach that way. It also fits the "add a letter, >> remove a feature" pattern established with h2c and security. > Please no. That's not a pattern worth repeating. I know that we've > discussed a limited profile in the past, but that was used to prime > initial state. > > I haven't seen any justification for creating a protocol variation. > See Section 3.4 of RFC 6709: > http://tools.ietf.org/html/rfc6709#section-3.4 That's really not the intent, if not the reading, of that section. A variation occurs within a protocol, and the key focus of that text is one of assuring interoperability with means to identify among the communicating systems that different rules in play. Here there are clear mechanisms to do that. They are talking about a separate clearly identified protocol. Whether or not a separate protocol is warranted is a different discussion. Michael says yes. You say no. Generally fewer code paths are better, and so that's why I would say the onus is on the proponents of the additional code path. Eliot
Received on Thursday, 29 May 2014 16:58:18 UTC