|
|
|
|
Published RFCs never change. Although every published RFC has been submitted to careful proofreading by the RFC Editor and the author(s), errors do sometimes go undetected.
Note that this list of errata may include both verified and unverified errata. Those marked "Verified" have been approved by the authors or the relevant party (e.g., the IESG for IETF documents). Those marked "Reported" have not yet been verified.
To report errata, please use the Errata Query Form.
Errata ID: 582
Status: Verified
Type: Editorial
Reported By: Zhang Xin Liang
Date Reported: 2005-05-23
In the Forward, it says:
It was generally agreed beforehand that the runmning of interactive programs across the network was the first problem that would be faced.
It should say:
It was generally agreed beforehand that the running of interactive programs across the network was the first problem that would be faced.
Errata ID: 581
Status: Verified
Type: Technical
Reported By: Jim Ursetto
Date Reported: 2000-09-25
Section 7 says:
This size declaration should appear at the end of the message description; thus, forcing the reader to postpone an early consideration of bit details. xmodmap -e "add lock = Caps_Lock"
It should say:
This size declaration should appear at the end of the message description; thus, forcing the reader to postpone an early consideration of bit details.
Errata ID: 1053
Status: Reported
Type: Technical
Reported By: Noel Chiappa
Date Reported: 2007-08-13
On page 3, it says:
It is important to remember that there are 356 links in each direction and that no relationship among these is imposed by the network.
It should say:
It is important to remember that there are 256 links in each direction and that no relationship among these is imposed by the network.
Errata ID: 580
Status: Verified
Type: Editorial
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 2 says:
Any transsfer begins with a request to read or write a file, which also serves to request a connection.
It should say:
Any transfer begins with a request to read or write a file, which also serves to request a connection.
Notes:
from pending
Errata ID: 703
Status: Verified
Type: Editorial
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 5 says:
The mode field contains the string "netascii", "octec", or "mail" (or any comibnation of upper and lower case, such as "NETASCII", "NetAscii", etc.) in netascii indicating the three modes defined in the protocol.
It should say:
The mode field contains the string "netascii", "octec", or "mail" (or any combination of upper and lower case, such as "NETASCII", "NetAscii", etc.) in netascii indicating the three modes defined in the protocol.
Notes:
spelling error: comibnation/combination
from pending
Errata ID: 716
Status: Reported
Type: Technical
Reported By: Damien Mattei
Date Reported: 2007-01-03
Section 3.1 says:
+--------+--------+--------+--------+
|10001000|00000010| Stream ID |
+--------+--------+--------+--------+
Type=136 Length=4
It should say:
+--------+--------+--------+--------+
|10001000|00000100| Stream ID |
+--------+--------+--------+--------+
Type=136 Length=4
Rationale:
This number count the length which is 4 and not 2.
10 in binary is 2 in decimal, 100 in binary is 4 in decimal.
The option-length octet counts the option-type octet and the
option-length octet as well as the option-data octets.(see page 15)
The length is 4 for the Stream identifier option as we have 4 bytes and
it is well written in page 16 of RFC 791:
The following internet options are defined:
CLASS NUMBER LENGTH DESCRIPTION
----- ------ ------ -----------
0 0 - End of Option list. This option occupies only
1 octet; it has no length octet.
0 1 - No Operation. This option occupies only 1
octet; it has no length octet.
0 2 11 Security. Used to carry Security,
Compartmentation, User Group (TCC), and
Handling Restriction Codes compatible with DOD
requirements.
0 3 var. Loose Source Routing. Used to route the
internet datagram based on information
supplied by the source.
0 9 var. Strict Source Routing. Used to route the
internet datagram based on information
supplied by the source.
0 7 var. Record Route. Used to trace the route an
internet datagram takes.
0 8 4 Stream ID. Used to carry the stream
identifier.
2 4 var. Internet Timestamp.
Notes:
from pending
Errata ID: 579
Status: Verified
Type: Editorial
Reported By: Pavel Uvarov
Date Reported: 2004-06-16
On page 21, it says:
The intitial contents of the route data area must be zero.
It should say:
The initial contents of the route data area must be zero.
Errata ID: 583
Status: Verified
Type: Editorial
Reported By: Pavel Uvarov
Date Reported: 2004-06-16
On page 23, it says:
The intitial contents of the timestamp data area must be zero or internet address/zero pairs.
It should say:
The initial contents of the timestamp data area must be zero or internet address/zero pairs.
Notes:
Spelling error.
Errata ID: 578
Status: Reported
Type: Editorial
Reported By: Yin Shuming
Date Reported: 2006-02-18
Section 3.2 says:
Note that this is consistent with the the datagram total length field (of course, the header is counted in the total length and not in the fragments).
It should say:
Note that this is consistent with the datagram total length field (of course, the header is counted in the total length and not in the fragments).
Errata ID: 577
Status: Verified
Type: Technical
Reported By: Beren Sanders
Date Reported: 2002-09-09
Report Text:
On page 16, the section 'Timestamp and Timestamp Reply Messages' has the header 'IP Fields:' - first mentioned after the graph and then again after 'Addresses'. The second one should actually be 'ICMP Fields:'. This error also occurs in the discussion of the 'Information Request and Information Reply Message' on page 18. The second 'IP Fields:' section of these two sets of message descriptions are really talking about fields in the ICMP header not the IP header.
Errata ID: 576
Status: Verified
Type: Editorial
Reported By: Arun Darlie Koshy
Date Reported: 2004-03-26
In the Introduction, fourth paragraph, it says:
Also ICMP messages are only sent about errors in handling fragment zero of fragemented datagrams. (Fragment zero has the fragment offeset equal zero).
It should say:
Also ICMP messages are only sent about errors in handling fragment zero of fragmented datagrams. (Fragment zero has the fragment offset equal zero).
Errata ID: 1231
Status: Reported
Type: Editorial
Reported By: Stéphane Bortzmeyer
Date Reported: 2008-01-04
Section Introduction says:
no ICMP messages are sent about ICMP messages
It should say:
no ICMP messages are sent about ICMP error messages
Notes:
For instance, echo replies are sent about echo messages. The context of the original sentence indicates that the author only referred to error messages but the sentence itself is not clear and I've seen the editorial error reproduced in some places.
Errata ID: 573
Status: Verified
Type: Technical
Reported By: Robert Braden
Date Reported: 2007-02-22
A number of details in RFC 793 were corrected, modified, or clarified in RFC 1122. Familiarity with RFC 1122 and more recent TCP documents is imperative any implementation of RFC 793 is attempted.
TCP Feature RFC 793 Ref See RFC 1122 Section Received PUSH bit Section 2.8 4.2.2.2 Urgent Pointer Section 3.1 4.2.2.4 TCP state diagram Section 3.2, p.23 4.2.2.8 Simultaneous Open Section 3.4, Fig 8 4.2.2.10 Retransmission Timeout Section 3.7 4.2.2.15, 4.2.3.1 Event Processing Section 3.9 4.2.2.20
Errata ID: 784
Status: Reported
Type: Technical
Reported By: Ian D. Allen
Date Reported: 2006-09-22
Section 3.2 says:
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ | WAIT |
+---------+ rcv FIN \ +---------+
| rcv ACK of FIN ------- | CLOSE |
| -------------- snd ACK | ------- |
V x V snd FIN V
+---------+ +---------+ +---------+
|FINWAIT-2| | CLOSING | | LAST-ACK|
+---------+ +---------+ +---------+
| rcv ACK of FIN | rcv ACK of FIN |
| rcv FIN -------------- | Timeout=2MSL -------------- |
| ------- x V ------------ x V
\ snd ACK +---------+delete TCB +---------+
------------------------>|TIME WAIT|------------------>| CLOSED |
+---------+ +---------+
TCP Connection State Diagram
Figure 6.
It should say:
[not supplied]
Notes:
Compare with RFC 1122:
" 4.2.2.8 TCP Connection State Diagram: RFC-793 Section 3.2,
page 23
There are several problems with this diagram:
(a) The arrow from SYN-SENT to SYN-RCVD should be labeled
with "snd SYN,ACK", to agree with the text on page 68
and with Figure 8."
Either RFC1122 is wrong (in which case *it* needs an Errata entry), or
RFC793 is wrong, in which case *it* needs an Errata entry. They can't
both be right!
Because of the above protocol diagram change given in RFC1122 (and others
in the same section), RFC1122 should also be mentioned as "updating"
RFC793, and RFC793 should be documented as being "updated by" RFC1122.
from pending
Errata ID: 575
Status: Verified
Type: Editorial
Reported By: Morris M. Keesan
Date Reported: 2003-10-29
Section 2.7 says:
If there are several pending passive OPENs (recorded in TCBs) with the
same local socket, an foreign active OPEN ...
It should say:
If there are several pending passive OPENs (recorded in TCBs) with
the same local socket, a foreign active OPEN ...
Errata ID: 574
Status: Verified
Type: Editorial
Reported By: Yin Shuming
Date Reported: 2005-05-22
In Section 3.7, page 43, it says:
If the the user signals a push function then the
data must be sent even if it is a small segment.
It should say:
If the user signals a push function then the
data must be sent even if it is a small segment.
Errata ID: 572
Status: Verified
Type: Editorial
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 2.1 says:
The format of data blocks exchanged within the a network will generally not be of concern to us.
It should say:
The format of data blocks exchanged within the network will generally not be of concern to us.
Notes:
from pending
Errata ID: 700
Status: Verified
Type: Editorial
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 3.7 says:
One procedure for determining a retransmission time out is given here as an illustration.
It should say:
One procedure for determining a retransmission timeout is given here as an illustration.
Notes:
from pending
Errata ID: 701
Status: Verified
Type: Editorial
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 3.8 says:
since it will be specified in detail by the specification of the lowel level protocol.
It should say:
since it will be specified in detail by the specification of the lower level protocol.
Notes:
from pending
Errata ID: 1283
Status: Reported
Type: Editorial
Reported By: Pei-chun Cheng
Date Reported: 2008-01-14
Section 3.3 says:
One way to deal with this problem is to deliberately delay emitting
segments for one MSL after recovery from a crash- this is the "quite
time" specification. Hosts which prefer to avoid waiting are
willing to risk possible confusion of old and new packets at a given
destination may choose not to wait for the "quite time".
Implementors may provide TCP users with the ability to select on a
connection by connection basis whether to wait after a crash, or may
informally implement the "quite time" for all connections.
Obviously, even where a user selects to "wait," this is not
necessary after the host has been "up" for at least MSL seconds.
It should say:
One way to deal with this problem is to deliberately delay emitting
segments for one MSL after recovery from a crash- this is the "quiet
time" specification. Hosts which prefer to avoid waiting are
willing to risk possible confusion of old and new packets at a given
destination may choose not to wait for the "quiet time".
Implementors may provide TCP users with the ability to select on a
connection by connection basis whether to wait after a crash, or may
informally implement the "quiet time" for all connections.
Obviously, even where a user selects to "wait," this is not
necessary after the host has been "up" for at least MSL seconds.
Notes:
"quite time" should be "quiet time"
Errata ID: 1083
Status: Reported
Type: Technical
Reported By: Peter Backes
Date Reported: 2007-11-21
Section 3.1.4. says:
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ atom
(the) comment
Vegas atom
. special
WBA atom
It should say:
Muhammed atom
. special
(I am the greatest) comment
Ali atom
@ special
(the) comment
Vegas atom
. special
WBA atom
Notes:
Apparently an artifact introduced by copying and incompletely adapting the example in RFC733, section III.B.e, which uses the atom "at" instead of the special "@".
Errata ID: 571
Status: Reported
Type: Technical
Reported By: SungWoon Lee
Date Reported: 2006-08-18
Section 3 says:
Neither can unilaterally seize control from the other; rather the controlling end must relinguish its control explicitly.
It should say:
Neither can unilaterally seize control from the other; rather the controlling end must relinquish its control explicitly.
Errata ID: 570
Status: Verified
Type: Technical
Reported By: Gerald Park
Date Reported: 2001-03-28
In Section Frame Format:
The minimum length of the data field of a packet sent over an Ethernet is 1500 octets, thus the maximum length of an IP datagram sent over an Ethernet is 1500 octets.
It should say:
The maximum length of the data field of a packet sent over an Ethernet is 1500 octets, thus the maximum length of an IP datagram sent over an Ethernet is 1500 octets.
Errata ID: 569
Status: Reported
Type: Technical
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 4 says:
How can the server send an IP datagram to the client, if the client doesnt know its own IP address (yet)?
It should say:
How can the server send an IP datagram to the client, if the client doesn't know its own IP address (yet)?
Errata ID: 568
Status: Verified
Type: Technical
Reported By: Juan Li
Date Reported: 2001-01-03
Section 2.1 says:
The use of a "Set Data Type" transaction was proposed in RFC 294 in January 1982.
It should say:
The use of a "Set Data Type" transaction was proposed in RFC 294 in January 1972.
Errata ID: 679
Status: Reported
Type: Technical
Reported By: Anvish
Date Reported: 2002-02-25
I found something strange in rfc1001 Maybe my code is wrong, but it returns "Tge NetBIOS tame" instead of "The NetBIOS name" when I try to encode FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF "For example, the NetBIOS name "The NetBIOS name" in the NetBIOS scope "SCOPE.ID.COM" would be represented at level one by the ASCII character string: FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM"
It should say:
[not submitted]
Notes:
from pending
Errata ID: 567
Status: Reported
Type: Editorial
Reported By: Sir Dystic
Date Reported: 2001-04-26
Section 4.2.16 says:
WAIT FOR ACKNOWLEDGEMENT (WACK) RESPONSE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NULL (0x0020) | IN (0x0001) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
The values for the first field (the resource record type) are defined above
in section 4.2.1.3. RESOURCE RECORD:
NULL 0x000A NULL Resource Record (See WAIT FOR
ACKNOWLEDGEMENT RESPONSE)
NB 0x0020 NetBIOS general Name Service Resource Record
(See NB_FLAGS and NB_ADDRESS, below)
Notes:
The value for type NULL is defined as 0x000A and the
comment specifically mentions WACK responses. The value shown in the packet
layout is 0x0020, the value for NB resource records, the most common value
for this field. In truth, I can't get Windows boxes to respond to this
packet as documented with either value in that field.
Errata ID: 566
Status: Reported
Type: Editorial
Reported By: "CFeng"
Date Reported: 2002-05-05
Section 7 says:
SRI.COM. NS
*Here-->> KL.SRI.COM. KL.SRI.COM. A 10.1.0.2.
It should say:
SRI.COM. NS KL.SRI.COM.
*Here-->> KL.SRI.COM. A 10.1.0.2.
Notes:
You can refer to RR "NS (Name Server)" on Page 6 in the same RFC for the reason.
Errata ID: 564
Status: Verified
Type: Technical
Reported By: Chlisin
Date Reported: 2003-02-06
Section 3.3 says:
The usual mail address <local-part>@<mail-domain> is mapped into a domain name by converting <local-part> into a single label (regardles of dots it contains), converting <mail-domain> into a domain name using the usual text format for domain names (dots denote label breaks), and concatenating the two to form a single domain name.
It should say:
The usual mail address <local-part>@<mail-domain> is mapped into a domain name by converting <local-part> into a single label (regardless of dots it contains), converting <mail-domain> into a domain name using the usual text format for domain names (dots denote label breaks), and concatenating the two to form a single domain name.
Errata ID: 755
Status: Reported
Type: Technical
Reported By: John Kristoff
Date Reported: 2006-03-13
Section 6.1. ends this way: Relative and absolute domain names may be freely intermixed in a master which is incomplete. It's unclear exactly how that sentence may have been intended to end, but minimally I would suggeste it at least terminated with 'file.'. Section 6.2.8. in the diagram shows 'QTYPE=A', but should be of type 'CNAME' based on the context of the example.
It should say:
[see above]
Notes:
from pending
Errata ID: 565
Status: Verified
Type: Editorial
Reported By: "Yin Shuming"
Date Reported: 2006-02-18
Section 4.3.1 says:
This bit specifies specifies whether the requester wants recursive service for this query. Clients may.....
It should say:
This bit specifies whether the requester wants recursive service for this query. Clients may.....
Errata ID: 1074
Status: Verified
Type: Editorial
Reported By: John Kristoff
Date Reported: 2006-03-13
Section 2.2. says: - Where there tradeoffs between the cost of acquiring data, the but should probably say: - Where there are tradeoffs between the cost of acquiring data, the Section 3.6.2. says: For example, suppose a name server was processing a query with for but should probably simply say: For example, suppose a name server was processing a query for Section 4.3.4. misspells 'because': This feature can be particularly important in a system which implements naming short shorts that use search lists beacuse
It should say:
[see above]
Notes:
from pending
Errata ID: 562
Status: Verified
Type: Technical
Reported By: CFeng
Date Reported: 2003-02-09
Section 6.4.2 says:
+-----------------------------------------+
Header | OPCODE=RESPONSE, ID=997 |
+-----------------------------------------+
Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
+-----------------------------------------+
Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
It should say:
+-----------------------------------------+
Header | OPCODE=IQUERY, ID=997, QR=1 |
+-----------------------------------------+
Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
+-----------------------------------------+
Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | <empty> |
+-----------------------------------------+
Notes:
There is an error in the Header line. It should be
"OPCODE=IQUERY, ID=997, QR=1" because the OPCODE does not have a
value of RESPONSE (see Section 4.1.1).
Errata ID: 563
Status: Reported
Type: Editorial
Reported By: Allan Edward Prentice
Date Reported: 2006-03-04
Section 5.1 says:
Because these files are text files several special encodings are
necessary to allow arbitrary data to be loaded. In particular:
of the root.
@ A free standing @ is used to denote the current origin.
It should say:
Because these files are text files several special encodings are necessary to allow arbitrary data to be loaded. In particular: @ A free standing @ is used to denote the current origin.
Notes:
"of the root." makes no sense here.
Errata ID: 561
Status: Verified
Type: Technical
Reported By: Florian Weimer
Date Reported: 2001-05-17
Section 2.1.4 says:
If the message is submitted in response to another message (e.g., is a follow-up) the default subject should begin with the four characters "Re:", and the "References" line is required.
It should say:
If the message is submitted in response to another message (e.g., is a follow-up) the default subject should begin with the four characters "Re: ", and the "References" line is required.
Errata ID: 1329
Status: Reported
Type: Technical
Reported By: Mark Taunton
Date Reported: 2008-02-25
Section Frame Format says:
The minimum packet size used with ARP is 24 octets, which is 20
(ARP with 2 octet hardware addresses and 4 octet protocol
addresses) + 8 (LLC+SNAP header) = 24 octets (not including the
MAC header).
It should say:
The minimum packet size used with ARP is 28 octets, which is 20
(ARP with 2 octet hardware addresses and 4 octet protocol
addresses) + 8 (LLC+SNAP header) = 28 octets (not including the
MAC header).
Errata ID: 1330
Status: Reported
Type: Technical
Reported By: Mark Taunton
Date Reported: 2008-02-25
Section Frame Format says:
In typical situations, the packet size used with ARP is 32 octets,
which is 28 (ARP with 6 octet hardware addresses and 4 octet
protocol addresses) + 8 (LLC+SNAP header) = 32 octets (not
including the MAC header).
It should say:
In typical situations, the packet size used with ARP is 36 octets,
which is 28 (ARP with 6 octet hardware addresses and 4 octet
protocol addresses) + 8 (LLC+SNAP header) = 36 octets (not
including the MAC header).
Notes:
Further instance of arithmetic error, previously reported in the preceding paragraph.
Errata ID: 560
Status: Verified
Type: Editorial
Reported By: Tim Moors
Date Reported: 2004-04-05
Section 4.1 says:
while( count > 1 ) {
/* This is the inner loop */
sum += * (unsigned short) addr++;
count -= 2;
It should say:
while( count > 1 ) {
/* This is the inner loop */
sum += * (unsigned short *) addr++;
count -= 2;
Errata ID: 559
Status: Verified
Type: Editorial
Reported By: Grzegorz R. Gryczka
Date Reported: 2002-10-19
Section 1.1.3 incorrectly implies that all support protocols are at the Application layer. In particular, it mentions that support protocol RARP (Reverse ARP), which is not an application-layer protocol.
Errata ID: 618
Status: Verified
Type: Editorial
Reported By: Bob Braden
Date Reported: 2007-10-25
Verifier Name: Bob Braden
Date Verified: 2007-11-12
Section 4.2.5 says:
OPEN to broadcast/multicast IP Address |4.2.3.14| | | | |x| Silently discard seg to bcast/mcast addr |4.2.3.14|x| | | | |
It should say:
OPEN to broadcast/multicast IP Address |4.2.3.10| | | | |x| Silently discard seg to bcast/mcast addr |4.2.3.10|x| | | | |
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: 1081
Status: Reported
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2007-11-20
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.
Errata ID: 1353
Status: Reported
Type: Technical
Reported By: John Klensin
Date Reported: 2008-03-08
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.
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: Reported
Type: Editorial
Reported By: John Klensin
Date Reported: 2008-03-08
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: 557
Status: Verified
Type: Technical
Reported By: Vincent Berger
Date Reported: 2002-03-27
Section 5.4.2 says:
egp(5), ggp(6), hello(7), rip(8), is-is(9), es-is(10), ciscoIgrp(11), bbnSpfIgp(12), ospf(13) bgp(14)
It should say:
egp(5), ggp(6), hello(7), rip(8), is-is(9), es-is(10), ciscoIgrp(11), bbnSpfIgp(12), ospf(13), bgp(14)
Errata ID: 556
Status: Verified
Type: Technical
Reported By: Chao Yel
Date Reported: 2000-02-28
In Section 5.10, Table 12 - Delta's Route Table: [Based on Figure 9] Network "factory" should correspond to Delta Interface #2; Network "accounting" should correspond to Delta Interface #3.
Errata ID: 683
Status: Reported
Type: Technical
Reported By: Joerg Ammon
Date Reported: 2003-03-04
Section 3.3 says:
In chapter '3.3 Addressing Routers in ISIS Packets' the RFC describes a standard procedure for deriving NSAP-addresses for IS in IP-only environments. However, the DFI as well as the AA are defined to be 'xx' and 'xx xx xx' respectively, which represents neither a valid decimal nor hexadecimal value.
It should say:
[not submitted]
Notes:
from pending
Errata ID: 1398
Status: Reported
Type: Editorial
Reported By: Christopher Witkowski
Date Reported: 2008-03-30
Section all says:
see Notes below
It should say:
see Notes below
Notes:
In the PDF version (from RFC-all.zip downloaded on 2008.03.20 15:15 EDT)
the letter spacing is screwed up. Some letters overlap each other while
others have too much space between them. This is in Adobe Reader 6.0.1 in
Windows 98 SE. The PDF starts with %PDF-1.1 so my software can't be too
old. The PostScript version displays OK and I can convert it to a PDF that
also displays OK so I think you just need to retry the conversion.
I've put a screen capture of what I see at:
http://web.ncf.ca/ab234/Capture-03-31-0001.png
Errata ID: 1397
Status: Reported
Type: Editorial
Reported By: Christopher Witkowski
Date Reported: 2008-03-30
Section all says:
I get an error if I don't fill in this field
It should say:
or this field. So just ignore this and read the Notes.
Notes:
In the PDF version (from RFC-all.zip downloaded on 2008.03.20 15:15 EDT)
the letter spacing is screwed up. Some letters overlap each other while
others have too much space between them. This is in Adobe Reader 6.0.1 in
Windows 98 SE. The PDF starts with %PDF-1.1 so my software can't be too
old. The PostScript version displays OK and I can convert it to a PDF that
also displays OK so I think you just need to retry the conversion.
I've put a screen capture of what I see at:
http://web.ncf.ca/ab234/Capture-03-30-0001.png
Errata ID: 554
Status: Verified
Type: Technical
Reported By: Jem Berkes
Date Reported: 2002-01-30
Section 3.1 says:
Padding is performed as follows: "i" bytes of value "i" are appended to the message so that the length in bytes of the padded message becomes congruent to 0, modulo 16. At least one byte and at most 16 16 bytes are appended.
It should say:
Padding is performed as follows: "i" bytes of value "i" are appended to the message so that the length in bytes of the padded message becomes congruent to 0, modulo 16. At least one byte and at most 16 bytes are appended.
Errata ID: 555
Status: Verified
Type: Technical
Reported By: David Hopwood
Date Reported: 2002-02-11
Section 3.2 says:
...
/* Process each 16-word block. */
For i = 0 to N/16-1 do
/* Checksum block i. */
For j = 0 to 15 do
Set c to M[i*16+j].
Set C[j] to S[c xor L].
Set L to C[j].
end /* of loop on j */
end /* of loop on i */
The 16-byte checksum C[0 ... 15] is appended to the message. Let
M[0
with checksum), where N' = N + 16.
It should say:
...
/* Process each 16-word block. */
For i = 0 to N/16-1 do
/* Checksum block i. */
For j = 0 to 15 do
Set c to M[i*16+j].
Set C[j] to C[j] xor S[c xor L].
Set L to C[j].
end /* of loop on j */
end /* of loop on i */
The 16-byte checksum C[0 ... 15] is appended to the (padded)
message.
Let M[0..N'-1] be the message with padding and checksum appended,
where N' = N + 16.
Errata ID: 552
Status: Verified
Type: Technical
Reported By: Michael Amling
Date Reported: 2000-04-12
Section 3.4 says:
the each bit of F(X,Y,Z) will be independent
It should say:
then each bit of F(X,Y,Z) will be independent
Errata ID: 550
Status: Verified
Type: Technical
Reported By: Matt Borland
Date Reported: 2001-01-19
In Section A.4:
#define MD MD5
It should say:
#define MD 5
Errata ID: 551
Status: Verified
Type: Technical
Reported By: Gregory Smith
Date Reported: 2002-06-14
Section 3.4 says:
/* Round 3. */
/* Let [abcd k s t] denote the operation
a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */
/* Do the following 16 operations. */
It should say:
/* Round 3. */
/* Let [abcd k s i] denote the operation
a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */
/* Do the following 16 operations. */
Errata ID: 585
Status: Verified
Type: Technical
Reported By: Gregory Smith
Date Reported: 2002-06-14
Section 3.4 says:
/* Round 4. */
/* Let [abcd k s t] denote the operation
a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */
It should say:
/* Round 4. */
/* Let [abcd k s i] denote the operation
a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */
Errata ID: 553
Status: Reported
Type: Technical
Reported By: Gennaro Prota
Date Reported: 2006-11-15
Appendix A says:
printf
("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
TEST_BLOCK_LEN, TEST_BLOCK_COUNT);
It should say:
printf
("MD%d time trial. Digesting %d %d-byte blocks ...", MD,
TEST_BLOCK_COUNT, TEST_BLOCK_LEN);
Errata ID: 1434
Status: Reported
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2008-06-07
Section 3.3.1 says:
[Footnote: Although a domain's selection policies are not explicitly distributed, they have an impact on the routes available to other domains. A route that may be preferred by a particular domain, and not prohibited by transit restrictions, may still be unavailable due to the selection policies of some intermediate domain. The ability to compute and install alternative routes that may be lost using hop-by-hop routing (either LS of PV) is the critical functionality provided by SDR.].
It should say:
[Footnote: Although a domain's selection policies are not explicitly distributed, they have an impact on the routes available to other domains. A route that may be preferred by a particular domain, and not prohibited by transit restrictions, may still be unavailable due to the selection policies of some intermediate domain. The ability to compute and install alternative routes that may be lost using hop-by-hop routing (either LS or PV) is the critical functionality provided by SDR.].
Errata ID: 549
Status: Reported
Type: Editorial
Reported By: Jean Delvare
Date Reported: 2002-07-08
On page 87, it says:
SUN OS 3.5 SUN OS 4.0
It should say:
SUN-OS-3.5 SUN-OS-4.0
Notes:
The white space isn't supposed to be accepted as part of a system name.
Errata ID: 548
Status: Verified
Type: Editorial
Reported By: Tymon Rzes'niowiecki
Date Reported: 2004-08-17
Section 6 says:
3) The 512 character limit on user IDs and the 64
character limit on tokens should be understood to mean
as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
token will be defined that has a length greater than 64
It should say:
3) The 512 character limit on user IDs and the 64
character limit on tokens should be understood to mean
as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
will be defined that has a length greater than 64
Errata ID: 547
Status: Verified
Type: Technical
Reported By: Mr. Sharky
Date Reported: 2002-03-30
Section 1 says:
It has become clear that the first two of these problems are likely to become critical in the near term. Classless Inter-Domain Routing (CIDR) ttempts to deal with these problems by defining a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers.
It should say:
It has become clear that the first two of these problems are likely to become critical in the near term. Classless Inter-Domain Routing (CIDR) attempts to deal with these problems by defining a mechanism to slow the growth of routing tables and reduce the need to allocate new IP network numbers.
Errata ID: 546
Status: Verified
Type: Technical
Reported By: Jim Withnall
Date Reported: 2001-10-31
Section 4.4.4 says:
Any DHCPACK messages that arrive with an 'xid' that does not match the When the client receives a DHCPACK from the server, the client computes the lease expiration time as the sum of the time at which the client sent the DHCPREQUEST message and the duration of the lease in the DHCPACK message.
It should say:
Any DHCPACK messages that arrive with an 'xid' that does not match the 'xid' of the client's DHCPREQUEST message are silently discarded. When the client receives a DHCPACK from the server, the client computes the lease expiration time as the sum of the time at which the client sent the DHCPREQUEST message and the duration of the lease in the DHCPACK message.
Errata ID: 545
Status: Verified
Type: Technical
Reported By: Tyler Tidman
Date Reported: 2001-09-05
Section 2 says:
Any message received by a DHCP server that includes a 'DHCP message type' (51) option is assumed to have been sent by a DHCP client.
It should say:
Any message received by a DHCP server that includes a 'DHCP message type' (53) option is assumed to have been sent by a DHCP client.
Errata ID: 1084
Status: Reported
Type: Editorial
Reported By: Justin Pryzby
Date Reported: 2007-11-27
Section Public vs... says:
it it is possible to "intercept" the search by matching against an
It should say:
it is possible to "intercept" the search by matching against an
Errata ID: 1085
Status: Reported
Type: Editorial
Reported By: Justin Pryzby
Date Reported: 2007-11-27
Section Solution(s) says:
starburst,astro.DESERTU.EDU,
It should say:
starburst.astro.DESERTU.EDU, (only 90% sure about this change)
Errata ID: 544
Status: Verified
Type: Technical
Reported By: Grzegorz R. Gryczka
Date Reported: 2002-10-24
Section 3.1.1 says:
If a client falls into this category, it SHOULD set (to 1) the newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY messages it generates. This will provide a hint to BOOTP servers and relay agents that they should attempt to broadcast their BOOTREPLY messages to the client.
It should say:
If a client falls into this category, it SHOULD set (to 1) the newly-defined BROADCAST flag in the 'flags' field of BOOTREQUEST messages it generates. This will provide a hint to BOOTP servers and relay agents that they should attempt to broadcast their BOOTREPLY messages to the client.
Notes:
(i.e. the first instance of "BOOTREPLY" should be "BOOTREQUEST".)
Errata ID: 543
Status: Reported
Type: Editorial
Reported By: Stuart Cheshire
Date Reported: 2006-09-27
Section 5.4 says:
On reception of a Configure-Reject, the Identifier field MUST match that of the last transmitted Configure-Request. Additionally, the Configuration Options in a Configure-Reject MUST be a proper subset of those in the last transmitted Configure- Request. Invalid packets are silently discarded.
It should say:
On reception of a Configure-Reject, the Identifier field MUST match that of the last transmitted Configure-Request. Additionally, the Configuration Options in a Configure-Reject MUST be a subset of those in the last transmitted Configure- Request. Invalid packets are silently discarded.
Notes:
The word "proper" should be deleted. (I discussed this a while ago with
the author, Bill Simpson, and he agreed.)
If A is a subset of B, then set A contains only elements that are also in
set B, up to and including all the elements of B (in which case A == B).
If A is a PROPER subset of B, then A contains only elements that are in
B, up to BUT NOT including all the elements of B.
In this case, the word "proper" is just a mistake, perhaps added because
someone thought it made the sentence sound better, without realizing that
the mathematical term "proper subset" has a specific precise meaning,
which is the wrong meaning in this case. As written in the RFC, the
sentence states that if a Configure-Request packet has n Configuration
Options in it, ALL of which are not recognizable or not acceptable, then
when the implementation returns its Configure-Reject packet, it's only
allowed to indicate that up to n-1 options were rejected, when in truth
ALL were rejected. Removing the word "proper" removes this unintended and
incorrect limitation.
Errata ID: 542
Status: Verified
Type: Technical
Reported By: Charles Cranford
Date Reported: 2002-03-07
In the References Section:
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
STD 50, RFC 1661, Daydreamer, July 1994.
It should say:
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, Daydreamer, July 1994.
Errata ID: 1404
Status: Reported
Type: Editorial
Reported By: Harald Tveit Alvestrand
Date Reported: 2008-04-03
Section 6 says:
RFC822: Harald.Alvestrand@uninett.no X.400: C=no; ADMD=; PRMD=uninett; O=uninett; S=alvestrand; G=harald
It should say:
RFC822: Harald.Alvestrand@uninett.no X.400: G=Harald; S=alvestrand; O=uninett; P=uninett; C=no
Notes:
The RFC is about the format of O/R names. The address as given in the author's address section should be consistent with the format recommended by the RFC.
Errata ID: 541
Status: Reported
Type: Technical
Reported By: "Coleman, Arthur"
Date Reported: 2006-03-09
Section 3 says:
the definitions for Latitude and Longitude are swapped.
I believe this can be considered a typo as the actual values in the
resource record can (and should) be kept in their current order.=20
The correct descriptions are (in general terms):=20
Latitude is the degrees North or South of the Equator and can be
referenced with a range of -90 to +90.=20
Longitude is the degrees East or West of the prime meridian and can
be referenced with a range of -180 to +180.
Below is my attempt to write the errata. If someone wants to make
suggestion about how the errata should be written, please tell me and I
will make a go at doing it as requested.
Art Coleman acoleman@verisign.com
In RFC 1712 the terms Latitude and Longitude are swapped in that each
was given the other's definition. =20
Also the preferred order of the terms is Latitude then Longitude. In
addition to matching the terms with their correct definitions, this
ordering is also addressed.
In Section 3, page 3 is a table, it says:
MSB LSB=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ LONGITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ LATITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ ALTITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
It should say:
MSB LSB=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ LATITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ LONGITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=20
/ ALTITUDE /=20
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Rational: It is only the terms that are being corrected, the value
ranges associated with the first (-90..90) and second (-180..180)
arguments are in the preferred order.
In Section 3, page 3 under 'where:', it says:
LONGITUDE The real number describing the longitude encoded as a=20
printable string. The precision is limited by 256 charcters
within the range -90..90 degrees. Positive numbers=20
indicate locations north of the equator.
LATITUDE The real number describing the latitude encoded as a=20
printable string. The precision is limited by 256 charcters=20
within the range -180..180 degrees. Positive numbers=20
indicate locations east of the prime meridian.
Is should say:
LATITUDE The real number describing the latitude encoded as a=20
printable string. The precision is limited by 256 characters
within the range -90..90 degrees. Positive numbers=20
indicate locations north of the equator.
LONGITUDE The real number describing the longitude encoded as a=20
printable string. The precision is limited by 256
characters=20
within the range -180..180 degrees. Positive numbers=20
indicate locations east of the prime meridian.
Rational: to match the terms with their correct definitions, and fix the
spelling of the word 'characters'.
In Section 4, page 3, it says:
GPOS has the following format:=20
<owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
It should say:
GPOS has the following format:=20
<owner> <ttl> <class> GPOS <latitude> <longitude> <altitude>
Rational: It is only the terms that are being corrected, the value
ranges associated with the first (-90..90) and second (-180..180)
arguments are in the preferred order.
In Section 4, page 4, it says:
The owner, ttl, and class fields are optional and default to the last
defined value if omitted. The longitude is a floating point number=20
ranging from -90 to 90 with positive values indicating locations=20
north of the equator. For example Perth, Western Australia is=20
located at 32^ 7` 19" south of the equator which would be specified=20
as -32.68820. The latitude is a number ranging from -180.0 to 180.0.
For example Perth, Western Australia is located at 116^ 2' 25" east=20
of the prime meridian which would be specified as 116.86520. Curtin=20
University, Perth is also 10 meters above sea-level.
It should say:
The owner, ttl, and class fields are optional and default to the last
defined value if omitted. The latitude is a floating point number=20
ranging from -90 to 90 with positive values indicating locations=20
north of the equator. For example Perth, Western Australia is=20
located at 32^ 7` 19" south of the equator which would be specified=20
as -32.68820. The longitude is a number ranging from -180.0 to
180.0.=20
For example Perth, Western Australia is located at 116^ 2' 25" east=20
of the prime meridian which would be specified as 116.86520. Curtin=20
University, Perth is also 10 meters above sea-level.
Rational: to match the terms with their correct definitions.
Notes:
from pending
Errata ID: 540
Status: Verified
Type: Editorial
Reported By: Orly Nicklass
Date Reported: 2004-05-27
Section 9 says:
rip2IfConfAuthKey
OCTET STRING (SIZE(0..16)),
It should say:
rip2IfConfAuthKey
OCTET STRING,
Errata ID: 1086
Status: Reported
Type: Editorial
Reported By: Joseph Bowbeer
Date Reported: 2007-11-29
Section 7 says:
Note that if the number of lines requested by the POP3 client is greater than than the number of lines in the body, then the POP3 server sends the entire message.
It should say:
Note that if the number of lines requested by the POP3 client is greater than the number of lines in the body, then the POP3 server sends the entire message.
Notes:
Extraneous "than" in discussion of TOP command.
Errata ID: 539
Status: Verified
Type: Technical
Reported By: Pete Young
Date Reported: 2003-10-01
Section 4.3 says:
Total Path Attribute Length:
This 2-octet unsigned integer indicates the total length of
the Path Attributes field in octets. Its value must allow
the length of the Network Layer Reachability field to be
determined as specified below.
A value of 0 indicates that no Network Layer Reachability
Information field is present in this UPDATE message.
It should say:
A value of 0 indicates that the Path Attributes field is
not present in this UPDATE message.
Errata ID: 1059
Status: Verified
Type: Editorial
Reported By: Denis Duault
Date Reported: 2007-08-28
In the References, it says:
[7] Touch, J., Optimized MD5 software, <ftp://ftp.isi.edu/pub/hpcc-
papers/touch/md5-opt.tar>.
It should say:
[7] Touch, J., Optimized MD5 software, <ftp://ftp.isi.edu/pub/hpcc-
papers/touch/md5-opt.tar.Z>.
Notes:
I noticed a broken link.
(the final ".Z" is missing)
Errata ID: 537
Status: Verified
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2005-05-12
Section 11 says:
ROUTE:4.
Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3)", RFC 1267, cisco, T.J. Watson Research Center, IBM
Corp., October 1991.
It should say:
ROUTE:4.
Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
Errata ID: 538
Status: Verified
Type: Editorial
Reported By: Nikolai Malykh
Date Reported: 2005-05-12
Section 7.3.1 says:
Although it was not designed as an exterior gateway protocol, RIP (described in Section [7.2.4]) is sometimes used for inter-AS routing.
It should say:
Although it was not designed as an exterior gateway protocol, RIP (described in Appendix F.2) is sometimes used for inter-AS routing.
Errata ID: 536
Status: Verified
Type: Technical
Reported By: Dirk Nimmich
Date Reported: 2002-03-09
Every occurance of the string:
, boundary=
It should say:
; boundary=
Errata ID: 535
Status: Verified
Type: Editorial
Reported By: Florian Weimer
Date Reported: 2002-10-21
Section 6.2 says:
DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to
be sent with a NULL return address ("reverse-path").
It should say:
DISCUSSION: RFC 1123, section 5.3.3 requires error notifications to
be sent with a NULL return address ("reverse-path").
Notes:
RFC 1123, section 2.3.3., does not exist. The correct section is 5.3.3.
Errata ID: 534
Status: Verified
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2002-02-25
Section 9.4 says:
Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
Sun, 10 Jul 1994 00:36:51 +0100
To: owner-info-mime@cs.utk.edu
Date: Sun, 10 Jul 1994 00:36:51 +0100
Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
content-type: multipart/report; report-type=delivery-status;
boundary=foobar
It should say:
Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
Sun, 10 Jul 1994 00:36:51 +0100
To: owner-info-mime@cs.utk.edu
Date: Sun, 10 Jul 1994 00:36:51 +0100
Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
MIME-Version: 1.0
content-type: multipart/report; report-type=delivery-status;
boundary=foobar
Errata ID: 533
Status: Verified
Type: Technical
Reported By:
Date Reported: 1969-12-31
In the Title:
Variance for
The PPP Connection Control Protocol
and
The PPP Encryption Control Protocol
It should say:
Variance for
The PPP Compression Control Protocol
and
The PPP Encryption Control Protocol
Errata ID: 1419
Status: Reported
Type: Editorial
Reported By: Jack Parker
Date Reported: 2008-05-07
Section 3 says:
An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry.
It should say:
An enterprise that decides to use IP addresses within the address space defined in this document can do so without any coordination with IANA or an Internet registry.
Notes:
There appears to be a slight difference in interpretation with the existing phrase, "out of the address space." This 'could' be interpreted to mean "outside of the address space," hence changing the meaning of the entire statement, if the section's context is not considered. In the interest of clarification, would it be possible to rephrase this particular section to "within the address space?" I'm aware of one case in particular where attorneys argued over this issue ad nauseum, regardless of the network architects attempting to intervene.
Errata ID: 532
Status: Verified
Type: Technical
Reported By: John Ioannidis
Date Reported: 2003-04-08
Section 2 says:
the word is "agglutinate", not "aglutenate"
Errata ID: 531
Status: Verified
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2003-10-07
Section 7 says:
1) they should not be used on data flines which might end
up in the hands of very small children
It should say:
1) they should not be used on data files which might end up
in the hands of very young children
Errata ID: 530
Status: Verified
Type: Editorial
Reported By: Joe Touch
Date Reported: 2005-05-11
Section 4 says:
4-bit carry-lookahead 2's complement adder:
a,b : input data
p : carry propagate, where pi = ai*bi = (ai)(bi)
g : carry generate, where gi = ai + bi
It should say:
4-bit carry-lookahead 2's complement adder:
a,b : input data
p : carry propagate, where pi = ai + bi
g : carry generate, where gi = ai*bi = (ai)(bi)
Notes:
Note: This change affects only page 4; the PLD code is known correct.
Errata ID: 529
Status: Verified
Type: Technical
Reported By: Bernard Treine
Date Reported: 2003-11-02
Section 7 says:
The server should never reuse an
unique-id in a given maildrop, for as long as the entity
using the unique-id exists.
It should say:
The server should never reuse a
unique-id in a given maildrop for as long as the maildrop
exists.
Errata ID: 1088
Status: Reported
Type: Editorial
Reported By: Joseph Bowbeer
Date Reported: 2007-11-29
Section 7 says:
Note that if the number of lines requested by the POP3 client is greater than than the number of lines in the body, then the POP3 server sends the entire message.
It should say:
Note that if the number of lines requested by the POP3 client is greater than the number of lines in the body, then the POP3 server sends the entire message.
Notes:
Extraneous "than" in discussion of TOP command.
Errata ID: 528
Status: Verified
Type: Technical
Reported By: Kurt D. Zeilenga
Date Reported: 2001-02-07
Section 2 says:
<dn> ::= a string as defined in RFC 1485
It should say:
<dn> ::= a string as defined in RFC 1779
Errata ID: 527
Status: Verified
Type: Technical
Reported By: Bartlomiej Molenda
Date Reported: 2003-11-03
Section 3 says:
Length
3
It should say:
Length
4
Errata ID: 526
Status: Verified
Type: Editorial
Reported By: Bruce Lilly
Date Reported: 2004-01-11
Section 5 says:
&railing whitespace that occurs on lines in order to ensure =20
It should say:
& trailing whitespace that occurs on lines in order to ensure =20
Errata ID: 525
Status: Verified
Type: Technical
Reported By: Frank McKiernan
Date Reported: 2002-06-25
The DESCRIPTION of probeDownloadAction uses the wrong INTEGER definitions for downloadToPROM and downloadToRAM. On page 92, it reads:
probeDownloadAction OBJECT-TYPE
SYNTAX INTEGER {
notDownloading(1),
downloadToPROM(2),
downloadToRAM(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When this object is set to downloadToRAM(2) or
downloadToPROM(3), the device will discontinue its
normal operation and begin download of the image specified
by probeDownloadFile from the server specified by
probeDownloadTFTPServer using the TFTP protocol. If
downloadToRAM(2) is specified, the new image is copied
to RAM only (the old image remains unaltered in the flash
EPROM). If downloadToPROM(3) is specified
the new image is written to the flash EPROM
memory after its checksum has been verified to be correct.
When the download process is completed, the device will
warm boot to restart the newly loaded application.
When the device is not downloading, this object will have
a value of notDownloading(1)."
::= { probeConfig 8 }
It should say:
probeDownloadAction OBJECT-TYPE
SYNTAX INTEGER {
notDownloading(1),
downloadToPROM(2),
downloadToRAM(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"When this object is set to downloadToRAM(3) or
downloadToPROM(2), the device will discontinue its
normal operation and begin download of the image specified
by probeDownloadFile from the server specified by
probeDownloadTFTPServer using the TFTP protocol. If
downloadToRAM(3) is specified, the new image is copied
to RAM only (the old image remains unaltered in the flash
EPROM). If downloadToPROM(2) is specified
the new image is written to the flash EPROM
memory after its checksum has been verified to be correct.
When the download process is completed, the device will
warm boot to restart the newly loaded application.
When the device is not downloading, this object will have
a value of notDownloading(1)."
::= { probeConfig 8 }
Errata ID: 522
Status: Verified
Type: Technical
Reported By: Scott Bradner
Date Reported: 2002-08-01
Section 10.4 says:
"The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11..."
Notes:
The reference to BCP-11 should be to BCP-9 (RFC 2026 itself).
Errata ID: 524
Status: Verified
Type: Technical
Reported By: Bob Harvey
Date Reported: 2002-12-30
Section 2.1 says:
Some RFCs standardize the results of community deliberations about statements of principle or conclusions about what is the best way to perform some operations or IETF process function. These RFCs form the specification has been adopted as a BCP, it is given the additional label "BCPxxx", but it keeps its RFC number and its place in the RFC series. (see section 5)
It should say:
Some RFCs standardize the results of community deliberations about statements of principle or conclusions about what is the best way to perform some operations or IETF process function. These RFCs form the 'BCP' (Best Current Practice) subseries of the RFC series. When a specification has been adopted as a BCP, it is given the additional label "BCPxxx", but it keeps its RFC number and its place in the RFC series. (see section 5)
Notes:
The reference to BCP-11 should be to BCP-9 (RFC 2026 itself).
Errata ID: 523
Status: Verified
Type: Editorial
Reported By: Morris M. Keesan
Date Reported: 2003-10-07
Section 9.1 says:
This variance procedure is for use when a one-time waving of some
provision of this document is felt to be required.
It should say:
This variance procedure is for use when a one-time waiving of some
provision of this document is felt to be required.
Errata ID: 586
Status: Verified
Type: Editorial
Reported By: Morris M. Keesan
Date Reported: 2003-10-07
Section 10.3.1 says:
4. The contributor represents that contribution properly
acknowledge major contributors.
5. The contribuitor, the organization (if any) he represents and
the owners of any proprietary rights in the contribution, agree
that no information in the contribution is confidential and
that the ISOC and its affiliated organizations may freely
disclose any information in the contribution.
It should say:
4. The contributor represents that the contribution properly
acknowledges major contributors.
5. The contributor, the organization (if any) he represents and
the owners of any proprietary rights in the contribution, agree
that no information in the contribution is confidential and
that the ISOC and its affiliated organizations may freely
disclose any information in the contribution.
Notes:
verb agreement ("acknowledges") and spelling correction ("contributor")
Errata ID: 521
Status: Reported
Type: Editorial
Reported By: Pete Resnick
Date Reported: 2006-03-21
Section 3.6 says:
The IAB appoints the IETF chair and is responsible for approving other IESG candidates put forward by the IETF nominating committee.
It should say:
Full IAB members, including the IETF chair, are selected and appointed according to the procedures defined in [BCP 10].
Notes:
from pending
Errata ID: 764
Status: Reported
Type: Editorial
Reported By: Pete Resnick
Date Reported: 2006-03-21
Section 3.6 says:
The IAB is also responsible for reviewing and approving the charters of new Working Groups that are proposed for the IETF.
It should say:
The formation of a working group requires a charter which is primarily negotiated between a prospective working group Chair and the relevant Area Director(s), although final approval is made by the IESG with advice from the Internet Architecture Board (IAB).
Notes:
from pending
Errata ID: 518
Status: Verified
Type: Technical
Reported By: Joe Hutcheson
Date Reported: 2001-03-16
Section 3 says:
Note that when calculating the correspondence, 2000 is not a leap year.
Notes:
Please disregard above statement regarding Leap Year, as the year 2000
was indeed a Leap Year.
Errata ID: 517
Status: Verified
Type: Technical
Reported By: David L. Mills
Date Reported: 2001-05-04
Section 5 says:
d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.
It should say:
d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.
Errata ID: 516
Status: Reported
Type: Technical
Reported By: Ben Fountain
Date Reported: 2002-11-12
Section 1 says:
Each SNTP packet is transmitted as tht TS-Userdata parameter of a T-UNITDATA Request primitive.
It should say:
Each SNTP packet is transmitted as the TS-Userdata parameter of a T-UNITDATA Request primitive.
Errata ID: 519
Status: Verified
Type: Editorial
Reported By: Akinori Shoji
Date Reported: 2003-07-18
Section 5 says:
Field Name Unicast/Anycast Multicast
Request Reply
----------------------------------------------------------
LI 0 0-2 0-2
VN 1-4 copied from 1-4
request
Mode 3 4 5
Stratum 0 1-14 1-14
Poll 0 ignore ignore
It should say:
Field Name Unicast/Anycast Multicast
Request Reply
----------------------------------------------------------
LI 0 0-2 0-2
VN 1-4 copied from 1-4
request
Mode 3 4 5
Stratum 0 1-15 1-15
Poll 0 ignore ignore
Errata ID: 520
Status: Reported
Type: Editorial
Reported By: Ben Fountain
Date Reported: 2002-11-12
Section 1 says:
An important provision in this document is the reinterpretation of certain NTP Versino 4 header fields which provide for IPv6 and OSI addressing and optional anycast extensions designed specifically for multicast service.
It should say:
An important provision in this document is the reinterpretation of certain NTP Version 4 header fields which provide for IPv6 and OSI addressing and optional anycast extensions designed specifically for multicast service.
Errata ID: 515
Status: Reported
Type: Editorial
Reported By: vijeeshep
Date Reported: 2005-12-16
Section 5 says:
T = ((T2 - T1) + (T3 - T4)) / 2.
It should say:
T = ((T2 - T1) + (T4 - T3)) / 2.
Notes:
Because T4 always will be greater than (or equal to) T3
For example assume
T1 = 1
T2 = 3
T3 = 4
T4 = 6
Case 1: As per the given formula the local clock offset will be
T = ((3 - 1) + (4 - 6)) / 2 = 0 which is wrong
Case 2: As per the corrected formula the local clock offset will be
T = ((3 - 1)+ (6 - 4)) / 2 = 2 which is correct
Errata ID: 587
Status: Verified
Type: Technical
Reported By: Bob Baldwin
Date Reported: 2004-03-22
Section 8 says:
6. Decrypt En to create Pn-1.
It should say:
6. Decrypt En and exclusive-or with Cn-2 to create Pn-1. For short messages where Cn-2 does not exist, use the IV.
Errata ID: 514
Status: Verified
Type: Technical
Reported By: Bob Baldwin
Date Reported: 2004-03-26
Section 8 says:
1. Exclusive-or Pn-1 with the previous ciphertext
block, Cn-2, to create Xn-1.
It should say:
1. Exclusive-or Pn-1 with the previous ciphertext
block, Cn-2, to create Xn-1. For short messages where
Cn-2 does not exist, use IV.
Errata ID: 513
Status: Verified
Type: Editorial
Reported By: Bob Baldwin
Date Reported: 2004-03-22
Section 8 says:
This mode handles any length of plaintext and produces ciphertext whose length matches the plaintext length.
It should say:
This mode handles any length of plaintext longer than one block and produces ciphertext whose length matches the plaintext length.
Errata ID: 512
Status: Reported
Type: Editorial
Reported By: Ned Freed
Date Reported: 2005-02-24
Section 5.1 says:
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
It should say:
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <"> /
"/" / "[" / "]" / "?" / "="
Errata ID: 508
Status: Verified
Type: Technical
Reported By: Herman Meerlo
Date Reported: 2001-10-04
Appendix A states:
discard-text := *(*text CRLF)
It should say:
discard-text := *(*text CRLF) *text
Errata ID: 588
Status: Verified
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2001-12-22
Section 5.2.2.2 says:
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Subject: Audio mail Message-ID: <anotherid@foo.com>
It should say:
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Message-ID: <anotherid@foo.com> Subject: Audio mail
Errata ID: 589
Status: Verified
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2001-12-22
Section 5.2.3.7 says:
Content-Type: message/external-body;
access-type=mail-server
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
It should say:
Content-Type: message/external-body;
access-type=mail-server;
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Notes:
Semicolons were missing.
Errata ID: 507
Status: Verified
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2003-10-04
Section 5.1.5 says:
Date: Mon, 22 Mar 1994 13:34:51 +0000
It should say:
Date: Tue, 22 Mar 1994 13:34:51 +0000
Errata ID: 510
Status: Verified
Type: Editorial
Reported By: Bruce Lilly
Date Reported: 2001-12-22
Section 5.1.5 says:
undesireble seperate
It should say:
undesirable separate
Notes:
Spelling errors.
Errata ID: 509
Status: Verified
Type: Editorial
Reported By: Steve Bellovin
Date Reported: 2004-02-03
Section 9 says:
9. Security Considerations
It should say:
8. Security Considerations
Notes:
In the Table of Contents, the Security Considerations is listed to be in Section 8. However, in the text, both the Security Considerations and Authors' Addresses are in Section 9; there is no Section 8.
Errata ID: 511
Status: Reported
Type: Editorial
Reported By: Lars Kasper
Date Reported: 2005-01-06
Section 3 says:
(2) image -- image data. "Image" requires a display device
(such as a graphical display, a graphics printer, or a
FAX machine) to view the information. An initial
subtype is defined for the widely-used image format
JPEG. . subtypes are defined for two widely-used image
formats, jpeg and gif.
It should say:
(2) image -- image data. "Image" requires a display device
(such as a graphical display, a graphics printer, or a
FAX machine) to view the information. An initial
subtype is defined for the widely-used image format
JPEG.
Errata ID: 504
Status: Verified
Type: Technical
Reported By: Jose M. Cainzos
Date Reported: 2001-11-10
Section 5 says:
(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC
822 ABNF definition for 'comment' is amended as follows:
comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
contain the characters "(", ")" or "
'encoded-word' that appears in a 'comment' MUST be separated from
any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.
It should say:
(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC
822 ABNF definition for 'comment' is amended as follows:
comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
contain the characters "(", ")" or "\". In addition, an
'encoded-word' that appears in a 'comment' MUST be separated from
any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.
Errata ID: 506
Status: Verified
Type: Technical
Reported By: Bruce Lilly
Date Reported: 2003-02-13
Section 2 says:
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="
It should say:
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
<"> / "/" / "[" / "]" / "?" / "." / "="
Notes:
Also reported by Jon Steinhart 2002-01-17, but corrected by Bruce Lilly.
Errata ID: 503
Status: Verified
Type: Technical
Reported By: Mathieu Fenniak
Date Reported: 2002-05-28
Section 6.4.8 says:
Example: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 UID FETCH completed
It should say:
Example: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 OK UID FETCH completed
Notes:
A list of known errata can be found at: ftp://ftp.cac.washington.edu/mail/rfc2060-errata
Errata ID: 749
Status: Reported
Type: Technical
Reported By: Frank Ellermann
Date Reported: 2005-02-06
RfC 2069 (digest access authentication) chapter 2.4 is an example,
the userame is "Mufasa", the password is "CircleOfLife":
| username="Mufasa",
| realm="testrealm@host.com",
| nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
| uri="/dir/index.html",
| response="e966c932a9242554e42c8ee200cec7f6",
| opaque="5ccc069c403ebaf9f0171e9517f40e41"
The "respose" is MD5( MD5( A1 ) || ':' || nonce || ':' || MD5( A2 ))
MD5( A1 ) = MD5( username || ':' || realm || ':' || password )
= MD5( "Mufasa:testrealm@host.com:CircleOfLife" )
= "4945ecf42b1bb868634058a845bedde8"
MD5( A2 ) = MD5( Method || ':' || digest-uri-value )
= MD5( "GET:/dir/index.html" )
= "39aff3a2bab6126f332b942af96d3366"
This results in a response = "1949323746fe6a43ef61f9606e7febea"
instead of the shown value = "e966c932a9242554e42c8ee200cec7f6".
Quick reality check, the RfC 2617 example uses the same values
username = "Mufasa"
nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093"
realm = "testrealm@host.com"
A2 = "GET:/dir/index.html"
with a slightly different
password = "Circle Of Life"
resulting in MD5( A1 ) = "939e7578ed9e3c518a452acee763bce9"
The "respose" is MD5( MD5( A1 ) || ':' || X || ':' || MD5( A2 ))
for X = "dcd98b7102dd2f0e8b11d0f600bfb0c093:00000001:0a4f113b:auth"
and here the response = "6629fae49393a05397450978507c4ef1" works as
expected.
It should say:
[not submitted]
Notes:
I've tried to contact two of the RfC 2069 authors about this issue,
but got no reply.
from pending
Errata ID: 502
Status: Verified
Type: Technical
Reported By: kjyou@ajou.ac.kr
Date Reported: 2004-03-30
Section 3.3. says:
Triggered RIP will NOT fuction properly (and should NOT be used) if a routing information will be retained/advertised for an arbitrarily long period of time (until an update in the opposite direction fails to obtain a response).
It should say:
Triggered RIP will NOT function properly (and should NOT be used) if a routing information will be retained/advertised for an arbitrarily long period of time (until an update in the opposite direction fails to obtain a response).
Errata ID: 501
Status: Verified
Type: Editorial
Reported By: Gregory Ogonowski
Date Reported: 2005-06-23
Section 9 says:
MD5Update(&context, k_ipad, 64) /* start with inner pad */
It should say:
MD5Update(&context, k_ipad, 64); /* start with inner pad */
Notes:
Errata ID: 496
Status: Verified
Type: Technical
Reported By: Kurt Zeilenga
Date Reported: 2001-01-31
Section 6 says:
In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.
It should say:
In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions). For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.
Errata ID: 493
Status: Verified
Type: Technical
Reported By: Davidson, Malcolm
Date Reported: 2001-05-31
Section 1 says:
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
It should say:
2. MUST NOT This phrase, or the phrase "SHALL NOT", means that the definition is an absolute prohibition of the specification.
Errata ID: 495
Status: Verified
Type: Technical
Reported By: Davidson, Malcolm
Date Reported: 2001-05-31
Section 1 says:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
It should say:
1. MUST This word, or the terms "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the specification.
Notes:
Errata ID: 498
Status: Verified
Type: Technical
Reported By: Davidson, Malcolm
Date Reported: 2001-05-31
Section 1 says:
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
It should say:
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED", means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
Errata ID: 500
Status: Verified
Type: Technical
Reported By: Davidson, Malcolm
Date Reported: 2001-05-31
Section 1 says:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
It should say:
3. SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Errata ID: 494
Status: Verified
Type: Editorial
Reported By: Davidson, Malcolm
Date Reported: 2001-05-31
Verifier Name: RFC Editor
Date Verified: 2007-11-07
Section 6 says:
(e.g., limiting retransmisssions)
It should say:
(e.g., limiting retransmissions)
Errata ID: 499
Status: Reported
Type: Editorial
Reported By: Anders Langmyr
Date Reported: 2006-01-09
The abstract says:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
It should say:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Notes:
The phrase "NOT RECOMMENDED" is missing from this phrase.
Errata ID: 497
Status: Reported
Type: Editorial
Reported By: Kiyoshi Ogawa
Date Reported: 2006-07-10
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
It should say:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications should be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
Notes:
OR should say:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications is understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
The change request is "must" to "should".
It may be self definition.
For the balance of SHOULD and SHOULD NOT , it should use "should", not
"must".
Errata ID: 492
Status: Verified
Type: Technical
Reported By: Larry Masinter
Date Reported: 2002-03-21
Report Text:
All errata for these documents can be found at: http://purl.org/net/http-errata
Errata ID: 491
Status: Verified
Type: Technical
Reported By: Larry Masinter
Date Reported: 2002-03-21
Report Text:
All errata for these documents can be found at: http://purl.org/net/http-errata
Errata ID: 490
Status: Verified
Type: Editorial
Reported By: Sreeni R. Nair
Date Reported: 2004-01-13
Section 4.1 says:
Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery.
It should say:
Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery.
Notes:
typo (uicast -> unicast)
Errata ID: 489
Status: Verified
Type: Editorial
Reported By: Soohong Daniel Park
Date Reported: 2004-04-29
Section 3.1 number 5 says:
The client times out and retransmits the DHCPREQUEST message if the
client receives neither a DHCPACK or a DHCPNAK message.
...
If the client
receives neither a DHCPACK or a DHCPNAK message after employing the
retransmission algorithm, the client reverts to INIT state and
restarts the initialization process.
It should say:
The client times out and retransmits the DHCPREQUEST message if the
client receives neither a DHCPACK nor a DHCPNAK message.
...
If the client
receives neither a DHCPACK nor a DHCPNAK message after employing the
retransmission algorithm, the client reverts to INIT state and
restarts the initialization process.
Notes:
Errata ID: 488
Status: Reported
Type: Editorial
Reported By: Robert Floyd Jr
Date Reported: 2006-03-23
Section 1.2 says:
In other related work, the path minimum transmission unit (MTU) discovery algorithm can determine the MTU of an arbitrary internet path [14].
It should say:
In other related work, the path maximum transmission unit (MTU) discovery algorithm can determine the MTU of an arbitrary internet path [14].
Errata ID: 486
Status: Verified
Type: Technical
Reported By: George V. Neville-Neil
Date Reported: 2001-12-12
Section 9.6 says:
Code Len Type
+-----+-----+-----+
| 53 | 1 | 1-9 |
+-----+-----+-----+
It should say:
Code Len Type
+-----+-----+-----+
| 53 | 1 | 1-8 |
+-----+-----+-----+
Errata ID: 487
Status: Reported
Type: Technical
Reported By: "Tyler Tidman"
Date Reported: 2002-09-24
Section 3.18 says:
3.18. Swap Server
This specifies the IP address of the client's swap server.
The code for this option is 16 and its length is 4.
Code Len Swap Server Address
+-----+-----+-----+-----+-----+-----+
| 16 | n | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
It should say:
3.18. Swap Server
This specifies the IP address of the client's swap server.
The code for this option is 16 and its length is 4.
Code Len Swap Server Address
+-----+-----+-----+-----+-----+-----+
| 16 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
Errata ID: 1082
Status: Reported
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2007-11-20
Section 5 says:
MAILBOX SERVICE SPECIFICATIONS [...] USENET NNTP [RFC977] NEWS NNTP Synonym for USENET
It should say:
MAILBOX SERVICE SPECIFICATIONS [...] USENET NNTP [son-of-1036] NEWSMASTER NNTP Synonym for USENET
Notes:
RFC 977 (obsoleted by RFC 3977) as well as RFC 1036 (obsoleted by RFC.ietf-usefor-usefor) don't specify rôle accounts USENET or NEWS.
Section 1 states that "Other protocols have defacto standards for well known mailbox names, such as <USENET@domain> for NNTP (see [RFC977])", however the IETF USEFOR WG didn't add just as little as an informative reference to RFC 2142.
Errata ID: 862
Status: Verified
Type: Editorial
Reported By: Christian Aymon
Date Reported: 2006-05-16
In "UTF-7 Definition", it says:
Such characters include control characters such as carriage returns and line feeds; thus, a Unicode shifted sequence always terminates at the of a line.
It should say:
Such characters include control characters such as carriage returns and line feeds; thus, a Unicode shifted sequence always terminates at the end of a line.
Notes:
missing word
Errata ID: 1387
Status: Reported
Type: Editorial
Reported By: Frank Ellermann
Date Reported: 2008-03-25
Section 6.2 says:
ESC 21 41
It should say:
ESC 22 43
Notes:
ESC 21 41 invokes ISO-IR 7, an unrelated C0 set.
ESC