RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (6)

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

Note: This RFC has been updated by RFC 1349, RFC 2181, RFC 5321, RFC 5966, RFC 7766, RFC 9210

Source of RFC: Legacy

Errata ID: 558
Status: Verified
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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.

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

Reported By: David LAMBERT
Date Reported: 2018-08-12
Verifier Name: Mirja Kühlewind
Date Verified: 2018-08-13

Section 4.1.2.5 says:

                 This is required because of the long delay after a TCP
                 connection is closed until its socket pair can be
                 reused, to allow multiple transfers during a single FTP
                 session.  Sending a port command can avoided if a
                 transfer mode other than stream is used, by leaving the
                 data transfer connection open between transfers.

It should say:

                 This is required because of the long delay after a TCP
                 connection is closed until its socket pair can be
                 reused, to allow multiple transfers during a single FTP
                 session.  Sending a port command can be avoided if a
                 transfer mode other than stream is used, by leaving the
                 data transfer connection open between transfers.

Notes:

The verb is missing in the last sentence.
"Sending a port command can avoided..."

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

Reported By: Ivan Panchenko
Date Reported: 2021-03-11
Verifier Name: Benjamin Kaduk
Date Verified: 2021-03-16

Section 6.1.3.6 says:

                 on the the existence of a TXT or WKS RR in most
                 domains.

It should say:

                 on the existence of a TXT or WKS RR in most domains.

Notes:

Doubled word.

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

Reported By: Ivan Panchenko
Date Reported: 2021-03-11
Verifier Name: Benjamin Kaduk
Date Verified: 2021-03-16

Section 3.2.1 says:

         option-negotiation loops.  A host MUST refuse (i.e, reply

It should say:

         option-negotiation loops.  A host MUST refuse (i.e., reply

Notes:

Missing full stop.

Status: Rejected (4)

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

Note: This RFC has been updated by RFC 1349, RFC 2181, RFC 5321, RFC 5966, RFC 7766, RFC 9210

Source of RFC: Legacy

Errata ID: 1081
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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: 6134
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Abel
Date Reported: 2020-04-28
Rejected by: Barry Leiba
Date Rejected: 2020-04-28

Section 5.2.2 says:

5.2.2  Canonicalization: RFC-821 Section 3.1

         The domain names that a Sender-SMTP sends in MAIL and RCPT
         commands MUST have been  "canonicalized," i.e., they must be
         fully-qualified principal names or domain literals, not
         nicknames or domain abbreviations.  A canonicalized name either
         identifies a host directly or is an MX name; it cannot be a
         CNAME.

It should say:

RFC5321 Section 2.3.5.  Domain Names

Only resolvable, fully-qualified domain names (FQDNs) are permitted
   when domain names are used in SMTP.  In other words, names that can
   be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
   in Section 5) are permitted, as are CNAME RRs whose targets can be
   resolved, in turn, to MX or address RRs.

Notes:

Section 2.3.5 from RFC 5321 seems to contradict the section 5.2.2 from 1123.

In RFC5321 it is implied that you can have a domain CNAME pointing to another that has an MX record that is not a CNAME and it should work. However 1123 states that it's not possible.
--VERIFIER NOTES--
Errata reports are for mistakes in the published document -- errata at the time of publication. Anything that might have changed since then is appropriate for a new document, but isn't errata in the old one.

Errata ID: 2464
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

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



Advanced Search