We currently have a number of application-layer applications that we might
want to use, a number of protocols, a number of transports, and at least
two levels of 'security'.
{http,ws}/{tls/,}{tcp, udp}/ip
This is already 8 combinations. If we add another application-layer
protocol and another transport (sctp for instance), we're up to 18...
If goodness forbid, we find some need to specify schemes, this becomes more
ludicrous.
If we're even thinking about going any length down this road, then we need
to at least reserve the capability to do something reasonable about this.
-=R
On Mon, Mar 3, 2014 at 2:37 AM, Martin Thomson <martin.thomson@gmail.com>wrote:
> On 3 March 2014 02:30, Roberto Peon <grmocg@gmail.com> wrote:
> > When using ALPN tokens within the actual ALPN extension, specifying TLS,
> > TCP, etc. (or the lack of same) is useless at best.
> > Such, however, makes sense over dns, alt-service, alt-protocol, etc.
>
> Right, but I would expect that you simply never send the
> h2{c|tcp|plain} label in ALPN itself.
>
Received on Monday, 3 March 2014 11:00:26 UTC