On May 9, 2021, at 11:26 AM, Paul Wouters <[email protected]> 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 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. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
