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-idsAgain, 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
OpenPGP_0x3732979CF967B306.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
