I recall a long-ago problem involving SIP DNS resource records related to confusion over escaped values. I believe it was the NAPTR resource record.
The problem presented to me involved two RFC documents, but related to NAPTR and both “published” as RFCs (not Internet Drafts). The conflict between the two related to one RFC adhering strictly to the conventions for zone files, while the other ignored a fine detail of the convention. This came down to the representation of a ‘\’ character in the record - one RFC wrote it as “\\” (escaping the backslash) and the other RFC did not perform the escape. Historical data (I’m surprised I could dig this back up.): In https://www.ietf.org/rfc/rfc2915.txt <https://www.ietf.org/rfc/rfc2915.txt> > http.uri.arpa. IN NAPTR > ;; order pref flags service regexp replacement > 100 90 "" "" "!http://([^/:]+)!\1!i" . In https://www.rfc-editor.org/rfc/rfc5483.txt <https://www.rfc-editor.org/rfc/rfc5483.txt> > A correct way to write this example [referring to the example as written > just before this, not RFC 2915] is: > * IN NAPTR 100 10 "u" > "E2U+sip" "!^\\+4655(.*)$!sip:\\1...@example.net!" . > > Note that when a NAPTR resource record is shown in DNS master file > syntax (as in this example above), the backslash itself must be > escaped using a second backslash. The DNS on-the-wire packet will > have only a single backslash. The latter is more strict - the escape (for zone files) is shown. Ironically, the latter, while trying to isolate the escape character, omits the line continuation parentheses. Regarding the two above, my explanation (to colleagues) was that the first RFC is showing the presentation of the record external to a zone file, the latter shows the record in a zone file. With this in mind, I’ve believed that there are three forms of a resource record. One is the wire format. Ignoring for now the compression of some domain names in some of early resource record types, there is just one way to express these in octets. I’ve learned that this is the format that matters - it is what is sent over the wire. Two is the convention of having a presentation format. This is the above converted into what we can see, speak, and hear when talking, listening, reading and writing documents. Three is the format that appears in zone files. The difference between this and the above format is that zone files have parsing instructions embedded, things external to the DNS protocol. What is in this difference are the (albeit quirky) line continuation characters, the ‘$’ directives, comments, escape for DDD (three-digit decimal values), and the regular escape. It’s been a long time since I wrote a parser, I may be forgetting some rarer cases. To understand how WALLET is “unimplementable”, I need to ask this… if the resource record is saying that ‘(‘ has no special meaning in the presentation format, when converting to zone file (presentation) format, wouldn’t you stick an escape character in front of it? That escape character would only be in the zone file, inserted and removed when writing and parsing it. > On Jun 24, 2024, at 01:25, Mark Andrews <ma...@isc.org> wrote: > > I was meaning to send a more meaningful message. > > WALLET has the following paragraph that should have prevented it being > approved > because multi-line continuation can be anywhere in a record and there is no > way > actually write a zone file parser and also do the requested behaviour. > > "None of the characters in either the <currency_abbrev> or > <display_value_of_address> are special. For example, a backslash > character (U+005C) does not act as an escape character of any sort.” > > Note the opening ‘(‘ occurs before the type is defined so one can’t event > disable > multi-line parsing after processing the type is specified. > > % cat multi-line.db > @ ( SOA . . 0 0 0 0 0 ) > @ NS . > % named-checkzone -D example multi-line.db > multi-line.db:1: no TTL specified; using SOA MINTTL instead > zone example/IN: loaded serial 0 > example. 0 IN SOA . . 0 0 0 0 0 > example. 0 IN NS . > OK > % > > Now the specification of WALLET doesn’t disallow ‘)’ as a currency identifier. > > I know people don’t like having to deal with escape processing but that isn’t > actually negotiable. > > Mark > >> On 23 Jun 2024, at 12:57, Mark Andrews <ma...@isc.org> wrote: >> >> Turning off escape processing prevents turning off multi line processing. >> >> >> >> -- >> Mark Andrews >> >> _______________________________________________ >> DNSOP mailing list -- dnsop@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org > > -- > 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 > To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
