Re: [DNSOP] alpn parsing in SVCB

[Ben Schwartz <[e-mail]>]

Hi Shane,

It's never too late.  Even after publication, the IETF can always change
the rules for registration of ALPN values.  However, ALPN is controlled by
the TLS working group, so you would have to make that argument there.

The SVCB authors engaged with the TLS working group on this topic last
year: https://mailarchive.ietf.org/arch/msg/tls/JqhlkWX0H1F4Hi4pjMOcn1tkm-I/
.  We concluded that there was not enough support for tightening the ALPN
registration rules, which is how we ended up with the current text.

--Ben

On Tue, Apr 19, 2022 at 2:16 PM Shane Kerr <[e-mail]>
wrote:

> Dear Colleagues,
>
> I know it's really late, but I hadn't worked with the SVCB until
> recently. Apologies if this has been thoroughly discussed. 😬
>
> I implemented a parser for the "alpn" service parameter, and the code
> was a lot more complex than I thought it should be. Basically, the
> double-encoding required for full implementation of the presentation
> format is cumbersome.
>
> I also think it is completely unnecessary.
>
> Can't we just restrict alpn, so that we don't use comma in the name?
> That would get rid of the need for the double-encoded values, the
> decision that implementers have to make whether or not to support them,
> plus all of Appendix A.
>
> I don't see any strong motivation for allowing comma in alpn name. As
> far as I can tell none of the existing ALPN values use a comma:
>
>
> https://www.iana.org/assignments/tls-extensiontype-values.xhtml#alpn-protocol-ids
>
> Again, apologies for chiming in so late. Maybe other implementers have
> had a different experience with this, and I'm way off-base. But if
> others agree, maybe it's not *too* late?
>
> Cheers,
>
> --
> Shane
>