> On 20 May 2021, at 12:31, Brian Dickson <brian.peter.dick...@gmail.com> wrote: > > > > On Wed, May 19, 2021 at 7:15 PM Mark Andrews <ma...@isc.org> wrote: > > > > On 20 May 2021, at 11:52, Paul Wouters <p...@nohats.ca> wrote: > > > > On Wed, 19 May 2021, Ben Schwartz wrote: > > > >> So long as there are no registered protocol identifiers containing "," or > >> "\\", zone file implementations MAY > >> disallow these characters instead of implementing the `value-list` > >> escaping procedure. > > > > Sorry, an implementor cannot predict the future of the IANA registry. They > > can't write code to confirm to this requirement other than NOT allowing > > the MAY. > > > > Even if they were silly enough to _first_ check the IANA registry before > > parsing SVCB records, they would still have to write all the the parsing > > code without CVE's for both cases, just in case the IANA registry would > > gain these characters in the future. > > Or detect them and switch to key1=“…” instead of alpn=“…” when displaying > entry would need to be using keyXXXX format until the software was upgraded. > > alpn=“h1\\,h2,h3” (or alpn=“h1\,h2,h3” I’m not sure where the consensus lies) > vs key1=“\005h1,h2\002h3" > > I don't understand why any of the comma-escaping is needed at all, honestly. > > RFC1035 has the definition of <character-string> encoding: > A bunch of characters without any internal spaces, or > A string beginning with " and ending with ", and anything else in between > except " which must be escaped.
Which doesn’t work in practice not the least because zone files where designed to be transferred between machines with different native character set encodings and different end of line conventions and the simplistic everything in between breaks in the real world. example 0 iN TXT “abc def” will produce different wire encodings on a old mac, new mac and windows at the EOL could be encoded as CR, NL, or CR NL. Add to that data entry where the native character set is not compatible with ASCII. > So, alpn=<character-string>[,<character-string>]* is unambiguous. Restricting > the character-string format used > to the kind surrounded by quotes, removes any ambiguity regarding commas. > Parsers need to be sufficiently well built to not treat commas internal to > character-string values as special. It isn’t ambiguity that is the problem. It’s working out which escape mechanism we are going to use. You have just added a third escape mechanism with the above. > No escaping of anything other than double-quote characters within a single > value (an ALPN) is needed. > > Brian > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
