- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 19 Oct 2013 12:17:36 +1100
- To: Andrei Popov <Andrei.Popov@microsoft.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 16/10/2013, at 9:41 AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote: > Hi Mark, > > SPDY and HTTP/1.1 protocol IDs are defined in the ALPN draft so that ALPN can be immediately used to negotiate the same protocols as NPN. We had originally defined an HTTP/2 protocol ID as well, but removed it from the latest versions of the draft so that the HTTPbis WG can specify the appropriate protocol ID(s). > > ALPN protocol IDs are defined as opaque non-empty octet strings, which allows for a compact representation of a large number of IDs. This does not prevent the HTTPbis WG from defining US-ASCII or UTF-8 protocol IDs for use on the Web. Hi Andrei, I understand; just a bit uncomfortable with using a registry that allows some fields that aren't valid. When we specify the header, we'll either have to specify an encoding (which probably won't get implemented), or just say that values outside a certain range are unusable. Our intent is to have multiple ways to convey these ids (e.g., in DNS, in headers), which means there needs to be coordination about what syntactic limits they have. The normal place to do that is in the registry requirements. Of course, we can work around this with some effort; it's just odd. Are there other strong motivating use cases that require this flexibility? Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 19 October 2013 01:18:04 UTC