[TLS] Narrowing allowed characters in ALPN ?

[Erik Nygren <[e-mail]>]

With draft-ietf-dnsop-svcb-https being in WGLC in DNSOP, one feedback that
has come up is that the escaping and parsing for SvcParamValues is
complicated.
Most of this complication comes from trying to support 8-bit clean ALPN
values.
Ideally in presentation format the ALPN list would be something like
"h2,h3,http/1.1"
but at the same time the current definition of ALPN as being a series of
binary
octets means that we need parsing and escaping rules.
When httpbis defined Alt-Svc, quite a bit of complexity showed up there
as well for supporting an 8-bit-clean ALPN value while allowing for an ascii
representation for most codepoints.  It seems likely that other
specifications
may run into the same challenge.

Would there be support for updating the ALPN registry to
indicate that registered ALPN values need to conform to a subset of token
characters?   There is a separate question for the process of making
this change, but before even exploring that it seems necessary to ask
the TLS WG if there are strong opinions on this one way or the other.

>From a usability perspective, non-token ALPN values will have challenges
in many of the systems that may try and configure them, as well
as for rendering special characters in various systems that may handle
ALPNs.
The codepoint space is also massive so it isn't clear that there's a
compelling
need to support 8-bit ALPN from a code point conservation perspective.

   Erik