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

Re: Questions about ALPN

From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Mon, 28 Oct 2013 11:32:38 +0000
Message-ID: <526E4B56.70502@isode.com>
To: Mark Nottingham <mnot@mnot.net>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, Andrei Popov <Andrei.Popov@microsoft.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 28/10/2013 05:00, Mark Nottingham wrote:
> Joe,
>
> The crux of the matter for me is that we're talking about defining parallel mechanisms that also use this registry, but have syntactic constraints -- to wit, DNS, and HTTP headers.
>
> That means we'll need to either define an encoding mechanism to allow these theoretical non-ASCII protocol identifiers to be used, or we'll have to say that certain protocol identifiers just won't work. Neither seems like a great solution.
>
> Let's push on it the other way, though: has anyone stated a requirement for non-ASCII protocol identifiers? We've talked about the downside of so much flexibility -- what does it buy us?
I am agreeing with Mark. Identifiers don't need to be anything other 
than ASCII. If somebody wants to stuff binary data in ALPN to go with 
protocol identifiers, then UTF-8 is not flexible enough.

So I would also like to see use cases for UTF-8 data which is not US-ASCII.
> Cheers,
>
>
>
> On 28/10/2013, at 1:24 PM, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com> wrote:
>
>> While the primary motivation for ALPN is the HTTP work, it may not be the only consumer and we did not see the need to restrict the possible values.   If the work associated to HTTP wants to restrict the values that they use then that can be done within the context of that work.  Other usages would still be free to define values that are expressed in other ways.   I think this design allows for flexibility so we do not have to define an extension for each usage.
>>
>> I still don't see a reason why allowing additional representations beyond what HTTP wants to use as problematic as long as we can represent what HTTP needs.  You will still need to handle unwanted character sets since implementations may choose not to follow the specification for malicious and benign reasons.
>>
>> Cheers,
>>
>> Joe
>>
>>
>>
>> On Oct 26, 2013, at 3:30 PM, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
>> wrote:
>>
>>>
>>> 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 11:33:08 UTC

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