Hello TLS,
I just started a thread on how ALPN will interact with new versions of QUIC:
https://mailarchive.ietf.org/arch/msg/quic/VuAWMvB8XFjpfK7kg6QaHn4KHqA/
This discussion could have a large impact on the evolution of the IANA ALPN
registry, which this WG created. Please participate in the di
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
If you look at
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
you can see that all of them are ASCII right now, except for some of the
GREASE values.
I support limiting it.
___
TLS mailing li
On 5/19/2021 12:29 PM, Salz, Rich wrote:
If you look
athttps://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
you can see that all of them are ASCII right now, except for some of the
GREASE values.
I support limiting it.
Internationaliza
I think that we would need stronger reasons than "it's annoying". There are
good reasons to use octets that map to simple ASCII. We should continue to
only define identifiers that use those characters. However, a specification is
also a commitment and whether or not it was a good idea, we (th
On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:
> I support limiting it.
I concur. These are not strings used between users to communicate in
their native language. They are machine-to-machine protocol
identifiers, and use of the narrowest reasonable character set promotes
interoper
