W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Questions about ALPN

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Sun, 27 Oct 2013 07:30:43 +0900
Message-ID: <526C4293.80201@it.aoyama.ac.jp>
To: Andrei Popov <Andrei.Popov@microsoft.com>
CC: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>


On 2013/10/22 6:03, Andrei Popov wrote:
> 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.

Yes, If some of them, like HTTP, prefer upper-case because it has always 
been upper-case, and others prefer lower-case, that's not going to be a 
problem.

> Even on this thread, I believe both US-ASCII and UTF-8 protocol IDs have been mentioned.

I saw UTF-8 mentioned as a theoretical idea, but I didn't see any actual 
UTF-8 example. Please tell me in case I missed it.

More strongly, as I have said before, I think for *protocol* 
identifiers, UTF-8 is entirely and completely unnecessary.

> From this perspective, having the flexibility at the TLS layer appears beneficial.

Flexibility is good, too much flexibility is bad.

> Treating application protocol IDs as opaque octet strings also allows efficient protocol ID matching at the TLS layer.

There's a huge difference between *allowing* arbitrary octet strings 
(which is completely unnecessary and actually problematic if you have 
octets e.g. in the C0 range show up in displays) and *comparing* them 
octet-by-octet (which is good for efficiency).

So please fix them to say that they are limited to printable ASCII and 
are compared byte-by-byte. That will be flexible enough without being 
too flexible, and efficient on top of it.

Regards,   Martin.
Received on Monday, 28 October 2013 01:27:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC