RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (3)

RFC 5890, "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", August 2010

Source of RFC: idnabis (app)

Errata ID: 4695
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Juan Altmayer Pizzorno
Date Reported: 2016-05-17
Verifier Name: Alexey Melnikov
Date Verified: 2016-10-07

Section 2.3.2.1 says:

expansion of the A-label form to a U-label may produce strings that are
much longer than the normal 63 octet DNS limit (potentially up to 252
characters)
^^^^^^^^^

It should say:

expansion of the A-label form to a U-label may produce strings that are
much longer than the normal 63 octet DNS limit (potentially up to 252
octets)
^^^^^

Notes:

The sentence should have used "octets" instead of "characters".

A separate erratum was files for possible tightening of the upper bound in a future revision of this document.

Errata ID: 4696
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Juan Altmayer Pizzorno
Date Reported: 2016-05-17
Verifier Name: Alexey Melnikov
Date Verified: 2016-10-07

Section 4.2 says:

Because A-labels (the form actually used in the
DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
in general, more compressed that UTF-16 or UTF-32), U-labels that
obey all of the relevant symmetry (and other) constraints of these
documents  may be quite a bit longer, potentially up to 252 characters
(Unicode code points).

It should say:

Because A-labels (the form actually used in the
DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
in general, more compressed that UTF-16 or UTF-32), U-labels that
obey all of the relevant symmetry (and other) constraints of these
documents  may be quite a bit longer, potentially up to 252 octets.
                                                        ^^^^^^^^^^

Notes:

Similar to Erratum 4695.

Errata ID: 7291
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: John Klensin
Date Reported: 2022-12-26
Verifier Name: Murray Kucherawy
Date Verified: 2023-06-01

Throughout the document, when it says:

Request for Comments: 5890
Obsoletes: 3490
Category: Standards Track

It should say:

Request for Comments: 5890
Obsoletes: 3490
Updates: 4343
Category: Standards Track

Notes:

I have no idea whether this correction is Editorial or Technical , nor what to use as a Section indication. However...

RFC 5890 (or IDNA2008 more generally), should have updated RFC 4343 and the IDN discussion in its Section 5. The latter references the IDNA2003 documents and makes some statements that are, at best, confusing in the context of IDNA2008.

See the extended notes for RFC 4343 in https://www.rfc-editor.org/errata/eid7290 for more discussion and details.

Recommendation: Hold for document update unless this appears to anyone to be a serious problem, in which case a separate RFC, using the notes on Errata ID 7290 as a starting point, may be in order.

[AD Note:] Marking this as Verified, and will direct the RFC Editor to update the metadata about both documents.

Status: Held for Document Update (3)

RFC 5890, "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", August 2010

Source of RFC: idnabis (app)

Errata ID: 4824
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Juan Altmayer Pizzorno
Date Reported: 2016-05-17
Held for Document Update by: Alexey Melnikov
Date Held: 2016-10-07

Section 4.2 says:

Because A-labels (the form actually used in the
DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
in general, more compressed that UTF-16 or UTF-32), U-labels that
obey all of the relevant symmetry (and other) constraints of these
documents may be quite a bit longer, potentially up to 252 characters
(Unicode code points).

It should say:

Because A-labels (the form actually used in the
DNS) are potentially much more compressed than UTF-8 (and UTF-8 is,
in general, more compressed that UTF-16 or UTF-32), U-labels that
obey all of the relevant symmetry (and other) constraints of these
documents may be quite a bit longer, potentially up to 59 Unicode
code points, or up to 236 octets.

Notes:

(The same rationale as my report for 2.3.2.1 applies:)

The contents of U-labels are encoded in the up to 59 ASCII characters (see 2.3.2.1)
output by the Punycode algorithm in their corresponding A-labels. The Punycode
decoder (https://tools.ietf.org/html/rfc3492#section-6.2) consumes at least one
of those ASCII characters for each code point inserted into the U-label. An U-label,
thus, can contain at the most 59 Unicode code points.

Since U-labels are defined (in 2.3.2.1) to be expressed in a standard Unicode Encoding
Form, and UTF-32, UTF-16 and UTF-8 (as revised by RFC3629) all can encode a code
point in at most 4 octets, 236 octets is an upper bound for an U-label's length.

I think it should be possible to derive a tighter bound, but its rationale would likely be
less straighforward.

I imagine the number 252 was originally derived by multiplying 63, the maximum
length of an A-label (including the "xn--" prefix), by 4, the maximum number of
octets needed to represent a code point.

Errata ID: 4823
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Juan Altmayer Pizzorno
Date Reported: 2016-05-17
Held for Document Update by: Alexey Melnikov
Date Held: 2016-10-07

Section 2.3.2.1 says:

expansion of the A-label form to a U-label may produce strings that are
much longer than the normal 63 octet DNS limit (potentially up to 252
characters)

It should say:

expansion of the A-label form to a U-label may produce strings that are
much longer than the normal 63 octet DNS limit (potentially up to 59
Unicode code points or 236 octets)

Notes:

The contents of U-labels are encoded in the up to 59 ASCII characters (see 2.3.2.1 itself)
output by the Punycode algorithm in their corresponding A-labels. The Punycode
decoder (https://tools.ietf.org/html/rfc3492#section-6.2) consumes at least one
of those ASCII characters for each code point inserted into the U-label. An U-label,
thus, can contain at the most 59 Unicode code points.

Since U-labels are defined (in 2.3.2.1) to be expressed in a standard Unicode Encoding
Form, and UTF-32, UTF-16 and UTF-8 (as revised by RFC3629) all can encode a code
point in at most 4 octets, 236 octets is an upper bound for an U-label's length.

I think it should be possible to derive a tighter bound, but its rationale would likely be
less straighforward.

I imagine the number 252 was originally derived by multiplying 63, the maximum
length of an A-label (including the "xn--" prefix), by 4, the maximum number of
octets needed to represent a code point.

Errata ID: 5484
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Peter Occil
Date Reported: 2018-08-28
Held for Document Update by: Murray Kucherawy
Date Held: 2023-01-04

Section 2.3.2.1 says:

   For IDNA-aware applications, the three types of valid labels are
   "A-labels", "U-labels", and "NR-LDH labels", each of which is defined
   below.

It should say:

   For IDNA-aware applications, the three types of valid labels are
   "A-labels", "U-labels", and "NR-LDH labels", each of which is defined
   below and in section 2.3.1.

Notes:

The term NR-LDH label is actually defined in section 2.3.1, not later in this section.

[Note from the document author: In reality, at least from the author's perspective, "NR-LDH label" is defined in the section of that name, i.e., 2.3.2.2, which is "below" 2.3.2.1. Whether 2.3.1 also "defines" it or supplements that definition (or if 2.3.2.1 supplements what 2.3.1 has to say) is a matter for debate, but it is clear that the text cited would benefit from a reference to 2.3.1.]

Report New Errata



Advanced Search