RFC Errata
RFC 8427, "Representing DNS Messages in JSON", July 2018
Source of RFC: IETF - NON WORKING GROUPArea Assignment: art
See Also: RFC 8427 w/ inline errata
Errata ID: 5439
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Gibson
Date Reported: 2018-07-24
Verifier Name: Barry Leiba
Date Verified: 2020-11-25
Section 2.6 says:
o If the member name does not end in "HEX", the value is a domain name encoded as DNS labels consisting of UTF-8 codepoints from U+0000 to U+007F. Within a label, codepoints above U+007F and the codepoint U+002E (ASCII period) MUST be expressed using JSON's escaping rules within this set of codepoints. Separation between labels is indicated with a period (codepoint U+002E). Internationalized Domain Name (IDN) labels are always expressed in their A-label form, as described in [RFC5890].
It should say:
o If the member name does not end in "HEX", the value is a domain name encoded in common display format as DNS labels separated by U+002E "." characters. Internationalized Domain Name (IDN) labels are always expressed in their A-label form, as described in [RFC5890]. Label characters with code points equal to U+0022 QUOTATION MARK or U+005C REVERSE SOLIDUS or less than U+0020 SPACE MUST be expressed using the JSON escaping rules of [RFC8259]. U+002E "." and U+005C "\" characters within labels MUST be preceded by a backslash escape as specified by [RFC1035] (and that backslash must itself be escaped for use in a JSON string, resulting in either the three-character sequence "\\." or the four-character sequence "\\\\", respectively).
Notes:
The Original Text appears to specify inclusion of raw characters less than U+0020 in JSON strings, which is disallowed by section 7 of RFC 8259.
Further, as specifically noted in section 8 of RFC 8259, "implementations that compare strings with escaped characters unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not equal", a fact logically deducible from the preceding "when all the strings represented in a JSON text are composed entirely of Unicode characters [UNICODE] (however escaped), then that JSON text is interoperable in the sense that all software implementations that parse it will agree on the contents of names and of string values in objects and arrays" text. Therefore, _correct_ JSON implementations must not distinguish e.g. "a.b.example." from "a\u002Eb.example.", as seems to be required by the Original Text.