Re: Questions about ALPN

SPDY/1 was never released externally, and so isn't particularly useful
except as an example.

Arguably the string used within ALPN is a subset of the form that might be
used in alt-protocol or alt-svc (there is no need to talk about ports, ips,
hosts, transports, etc. within the ALPN string-- that choice was already
made...), and so should probably be defined in a separate document from
both the HTTP or ALPN specs.

-=R


On Mon, Oct 14, 2013 at 2:19 PM, Mark Nottingham <mnot@mnot.net> wrote:

> After our recent discussions, I went back and looked at the LC draft of
> ALPN:
>   http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-02
> and noticed a few things.
>
> For a while now, we've been talking about using the ALPN string for more
> than just negotiation within TLS; possible uses include in the Upgrade
> "dance", in the Alt-Svc / Alternate-Protocol header, and possibly within
> DNS.
>
> However, the range of characters in an ALPN string is broad; in fact,
> UTF-8 is only a possibility:
>
> """
>    o  Identification Sequence: The precise set of octet values that
>       identifies the protocol.  This could be the UTF-8 encoding
>       [RFC3629] of the protocol name.
> """
>
> While that's fine for TLS, it becomes problematic in other environments
> like HTTP headers or DNS, because encoding will be necessary.
>
> Furthermore, there's no ABNF for other specifications to refer to.
>
> I think the range of an ALPN protocol identifier needs to be more
> constrained, to make it more amenable to reuse. Alternatively, maybe the
> protocol identifier registry shouldn't be specified by this document; it
> could be delegated to the URI scheme that is in use, for example. Or, maybe
> the Port Number registry could be reused (as SVN has done).
>
> In some ways, that makes more sense, since ALPN is so TLS-specific; in
> some of the discussions I've had, people get confused when I talk about
> ALPN protocol identifiers being used for non-TLS protocols.
>
> Note that I'm not against having ALPN define this registry -- I just think
> we need to talk about it and understand what the consequences of doing so
> will be.
>
> Also, the document pre-registers a number of values:
>
> """
>       Protocol: HTTP/1.1
>       Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31
> ("http/1.1")
>       Specification:  http://tools.ietf.org/html/rfc2616
>
>       Protocol: SPDY/1
>       Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x31 ("spdy/1")
>       Specification:
> http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1
>
>       Protocol: SPDY/2
>       Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x32 ("spdy/2")
>       Specification:
> http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2
>
>       Protocol: SPDY/3
>       Identification Sequence: 0x73 0x70 0x64 0x79 0x2f 0x33 ("spdy/3")
>       Specification:
> http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3
> """
>
> The reference for HTTP/1.1 needs to be draft-ietf-httpbis-p1-messaging,
> and I don't think that SPDY/1 has ever been used (except for early internal
> testing by Mike and Roberto, perhaps).
>
> I'll eventually send this feedback to TLS, but wanted to bring it up here
> first; please discuss.
>
> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>