On Mon, 10 May 2021 at 00:28, Paul Hoffman <paul.hoff...@icann.org> wrote: > > On May 9, 2021, at 11:26 AM, Paul Wouters <p...@nohats.ca> wrote: > > This is all pretty terrible. I agree with Tim that we should not inflict > > this onto the users. Or perhaps we can already pre-allocate some CVE > > numbers for the security issues this will generate. > > > > Keep the record simple, we are not going for Turing complete here. I > > recommend to authors take this discussion as advise to improve / simplify > > this aspect of the draft. > > I don't think this request is actually doable. The requirements for the SVCB > Rdata are: > 1. Must be entered by the zone operator as ASCII text (not all a jumble of > hex values) > 2. Is a list of key/value pairs > 3. Values are likely to be a list of items >
It is very much doable. BIND, NSD, and PowerDNS can already parse values containing '\,' escapes, and each of these has a substantial installed base. My objections can be entirely satisfied by modest changes to reconcile the document with RFC1035. > Given these three things, it seems that there will *always* be an escaping > problem for the item delimiter in #3. In the current draft, the item > delimiter is a comma, so there has to be a way to escape a comma that is in > an item. Few types of items would ever need a comma in their values. If a > different character is chosen for the item delimiter, it too will need to be > escaped. > > If I'm wrong about this being as good as it can be, there must be an item > delimiter that is better than a comma. I am not thinking creatively enough to > figure out what might be better than a comma. I'd be happy to hear proposals > for a better item delimiter. My objection is narrowly focussed on the escape mechanism, nothing more. Changing the delimiter is neither necessary nor relevant. I am happy to contribute the necessary words. --Dick _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
