RE: Questions about ALPN

While ALPN was introduced primarily to enable the negotiation of HTTP and SPDY protocol versions within the TLS handshake, the intent is for other (non-Web) applications to be able to negotiate their protocols using the same TLS extension. It is conceivable that different applications will prefer different representations of their protocol IDs. Even on this thread, I believe both US-ASCII and UTF-8 protocol IDs have been mentioned. From this perspective, having the flexibility at the TLS layer appears beneficial. Treating application protocol IDs as opaque octet strings also allows efficient protocol ID matching at the TLS layer.

Cheers,

Andrei

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Friday, October 18, 2013 6:18 PM
To: Andrei Popov
Cc: ietf-http-wg@w3.org
Subject: Re: Questions about ALPN


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 Monday, 21 October 2013 21:03:36 UTC