On Tue, 4 May 2021 at 21:18, Ben Schwartz <bem...@google.com> wrote: > > On Tue, May 4, 2021 at 12:09 PM Dick Franks <rwfra...@gmail.com> wrote: >> >> The brutal reality is that the char-string parser has already >> obliterated the distinction between escaped and unescaped commas >> before the value-list parser is invoked. > > Yes, hence the use of "\\," for embedded commas in value-list values.
No, this is better characterised as the wound dressing covering the bullet hole in your foot! ... >> >> For the sanity of all concerned, SVCB should adhere to the same >> standard RFC1035 escape conventions as the other 50+ RRTYPEs. > > I think that's a good description of why this arrangement was chosen. But that is precisely what you are NOT doing. You have assigned a special significance to the character sequence "\\," contrary to RFC1035. The language of RFC1035 is crystal clear that an escaped character is parsed as plain text, independently, without regard to context, and that any special meaning does not apply. Strict application of the RFC1035 rules causes string "...\\,..." to be equivalent to "...\092,...". BIND, NSD, and Net::DNS are all able to arrive at implementations of SVCB using the RFC1035 standard escape conventions, which demonstrates beyond reasonable doubt that recognising "\\," is not an essential requirement. Appendix A and related features should be removed from the draft. --Dick _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
