RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 8427, "Representing DNS Messages in JSON", July 2018

Source of RFC: IETF - NON WORKING GROUP
Area 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.

Report New Errata