errata logo graphic

Found 6 records.

Status: Verified (3)

RFC1123, "Requirements for Internet Hosts - Application and Support", October 1989

Source of RFC: Legacy

Errata ID: 558

Status: Verified
Type: Technical

Reported By: Ben Harris
Date Reported: 2003-02-12

Section 2.5 says:

Host names of up to 635 characters |2.1 |x| | | | | 

It should say:

Host names of up to 63 characters |2.1 |x| | | | | 

Notes:

Section 2.1 says "Host software MUST handle host names of up to 63 characters" and doesn't mention the number 635 at all.


Errata ID: 584

Status: Verified
Type: Editorial

Reported By: Ben Harris
Date Reported: 2003-02-12

Section 7 says:

[TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, December 1983. 

It should say:

[TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-885, December 1983.

Notes:

RFC 855 is "Telnet Option Specifications"; RFC 885 is "Telnet end of record option".


Errata ID: 1354

Status: Verified
Type: Editorial

Reported By: John Klensin
Date Reported: 2008-03-08
Verifier Name: Lisa Dusseault
Date Verified: 2008-07-14

Section 2.1 says:

The syntax of a legal Internet host name was specified in RFC-952 [DNS:4].

It should say:

The syntax of a legal Internet host name was specified in RFC-952
[DNS:4] and reiterated in RFC-1034 Section 3.5 [DNS:1].

Notes:

This essentially trivial editorial change makes it slightly easier for
anyone (or any tool) that tracks changes and updates to host and domain
naming rules to identify the applicability of this section.


Status: Rejected (3)

RFC1123, "Requirements for Internet Hosts - Application and Support", October 1989

Source of RFC: Legacy

Errata ID: 1081

Status: Rejected
Type: Technical

Reported By: Frank Ellermann
Date Reported: 2007-11-20
Rejected by: Lisa Dusseault
Date Rejected: 2008-07-14

Section 2.1 says:

                        However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.

It should say:

                        However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be not all-numeric.

Notes:

RFC 3696 section 2 states: "There is an additional rule that essentially requires that top-level domain names not be all-numeric." The eleven IDN test TLDs created in September 2007 contain hyphen-minus as specified in the IDNA RFCs.
--VERIFIER NOTES--
This errata is in conflict with errata 1353. A new I-D and community consensus are probably needed.


Errata ID: 1353

Status: Rejected
Type: Technical

Reported By: John Klensin
Date Reported: 2008-03-08
Rejected by: Lisa Dusseault
Date Rejected: 2008-07-14

Section 2.1, ID 1081 says:

Errata ID 1081, reported 2007-11-20, identifies a problem with the
evolution of naming of top-level domains and the text of RFC 1123.
It reads:

Section 2.1 says:

                        However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.

It should say:

                        However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be not all-numeric.

Notes:

RFC 3696 section 2 states: "There is an additional rule that 
essentially requires that top-level domain names not be 
all-numeric." The eleven IDN test TLDs created in 
September 2007 contain hyphen-minus as specified in the 
IDNA RFCs. 

It should say:

However, a valid host name can never have the dotted-decimal 
form #.#.#.#, since this change does not permit the highest-level 
component label to start with a digit even if it is not all-numeric.

Notes:

This is a correct identification of the problem, but the wrong fix. RFC 3696, which ID 1081 cites, is an informational document that is deliberately relaxed about the fine details and says so. It is not relevant to determination of the text that should have been (with perfect knowledge of the future) in 1123.

Based on discussions when we were doing RFC 1591 and subsequently, the expectation then (and presumably when 1123 was written) was that the name of any new TLD would follow the rules for the existing ones, i.e., that they would be exactly two or three characters long and be all-alphabetic (which is exactly what 1123 says). The slightly-odd "will be" language in 1123 was, I believe, because that restriction was expected to be enforced by IANA, rather than being a protocol issue. ICANN, with a different set of assignment policies, effectively eliminated the length rule with the TLDs allocated in 2000. IDNA (RFC 3490) uses a syntax for IDNs that requires embedded hyphens in TLDs if there were ever to be an actual IDN TLD (hence the comment in ID 1081 about the IANA IDN testbed).

While the proposed correction in Errata ID 1081 would fix the problem by imposing the narrowest possible restriction ("not all-numeric"), the original host name rule and the original statement in 1123 both assume the possibility of a minimal check to differentiate between domain names and IP addresses, i.e., checking the first digit only. Because I believe that there are probably implementations that depend on such minimal parsing --some probably ancient and embedded-- it would appear to be wise to relax the rule as little as possible and, in particular, to restrict the "leading digit" exception to domains below the top-level, as 1123 effectively does.

The suggested text above reflects that reasoning. Because of the possible consequences of this issue, I would hope that it would be discussed with the relevant DNS-related WGs, the Root Server Advisory Committee (RSAC), and with IANA for comment and as a heads-up. This issue is substantive enough that it should probably be dealt with by a document that explicitly updates 1123 and that is processed on the Standards Track, but an accurate statement in the errata is the next-best option until that can be done. In the interim and while this suggestion is being discussed, Errata ID 1081 should probably be taken out of "validated" status.
--VERIFIER NOTES--
This errata is in conflict with errata 1081. A new I-D and community consensus are probably needed.


Errata ID: 2464

Status: Rejected
Type: Editorial

Reported By: Anthony Bryan
Date Reported: 2010-08-15
Rejected by: ron bonica
Date Rejected: 2011-10-12

Section 4.1.2.6 says:

            IMPLEMENTATION:
                 The format of the 227 reply to a PASV command is not
                 well standardized.  In particular, an FTP client cannot
                 assume that the parentheses shown on page 40 of RFC-959
                 will be present (and in fact, Figure 3 on page 43 omits
                 them).

It should say:

            IMPLEMENTATION:
                 The format of the 227 reply to a PASV command is not
                 well standardized.  In particular, an FTP client cannot
                 assume that the parentheses shown on page 40 of RFC-959
                 will be present (and in fact, Figure 3 on page 45 omits
                 them).

Notes:

In RFC 959, Figure 3 is actually on page 45, not page 43.
--VERIFIER NOTES--
I see figure 3 at the top of page 45.


Report New Errata