On Mon, 10 May 2021, Ben Schwartz wrote:
It would also require a dramatic rewrite of a specification that is now widely deployed.
The IETF is not a rubber-stamp factory for corporate proposals though. The tendency for corporation to bring up something at the IETF that is "too far gone" for modifications during the IETF process as a trend is worrying, and does make me personally feel less sympathetic towards those kind of deployments. Did you reach out to SecDir for an early review request? I cannot find anything in the SecDir archives related to HTTPSVC or SVCB. DNS records have been using _prefix labels for a while now to split up RR information to be more specific related to targetted DNS requests. This RR type is unfortunately not using that, and thus the complexity and securtity issues are popping up now.
To see why I favor two-pass, consider a SvcParam whose wire format value is defined to be CBOR, represented as JSON in the zone file. JSON is defined as UTF-16, and allows strings containing any character from the Basic Multilingual Plane. It also allows various kinds of backslash escaping including " \" " for quotes within strings, and "\uD834\uDD1E" for extended unicode codepoints. A one-pass parser must somehow integrate this into the flow of zone file parsing. The easiest way is to simply disable all RFC1035-style escapes
Or to simply disable all JSON/COBR/UTF-16 et all ? Do we really need emoticons in our transport definitions ?
I also think these behaviors would be confusing to users, who would have to try to understand how this new integrated escaping works in order to author zone files
If that is the main argument, what's wrong with plain ascii limitations? Anyway, I think this issue deserves a full discussion, without taking into account the current wide deployment. Also bacause everything out there that does not support SVCB also continues to work, so it is not the end of the world if SVCB needs to go through some changes. But as Mr.Abley said (and I paraphrase) "we can burn an RR type allocation easilly". Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
