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.