RFC Errata
Found 20 records.
Status: Verified (13)
RFC 2812, "Internet Relay Chat: Client Protocol", April 2000
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 384
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeroen Peschier
Date Reported: 2002-12-16
Section 2.3 says:
The presence of a prefix is indicated with a single leading ASCII
colon character (':', 0x3b), which MUST be the first character of
the message itself.
It should say:
The presence of a prefix is indicated with a single leading ASCII
colon character (':', 0x3a), which MUST be the first character of
the message itself.
Errata ID: 385
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alejandro Grijalba
Date Reported: 2004-06-10
Section 2.3.1 says:
chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
It should say:
chanstring = %x01-06 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B
Errata ID: 386
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Konstantin Zemlyak
Date Reported: 2003-01-18
Section 5.3 says:
244 RPL_STATSHLINE 244 RPL_STATSSLINE
It should say:
244 RPL_STATSHLINE 245 RPL_STATSSLINE
Errata ID: 2821
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ricardo Garcia
Date Reported: 2011-06-05
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-10
Section 5.1 says:
341 RPL_INVITING
"<channel> <nick>"
It should say:
341 RPL_INVITING
"<nick> <channel>"
Notes:
Numeric reply 341 is used by the server to report a sucessful invitation attempt to the original client sending the invitation. The RFC mentions the reply arguments are the channel and the nickname, but every client and server I have tested expect the nickname first, followed by the channel name.
Errata ID: 2822
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ricardo Garcia
Date Reported: 2011-06-05
Verifier Name: Peter Saint-Andre
Date Verified: 2011-06-10
Section 5.1 says:
The original text is missing.
It should say:
416 ERR_TOOMANYMATCHES
"<channel> :Output too long (try locally)"
- Returned by a server in response to a LIST or NAMES
message to indicate the result contains too many
items to be returned to the client.
Errata ID: 2991
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Campbell
Date Reported: 2011-10-11
Verifier Name: Peter Saint-Andre
Date Verified: 2011-10-17
Section 3.2.3 says:
The original text is missing.
It should say:
ERR_NOSUCHCHANNEL
Notes:
Numeric reply list for Channel Modes should include ERR_NOSUCHCHANNEL.
Errata ID: 3001
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matthew Campbell
Date Reported: 2011-10-21
Verifier Name: Peter Saint-Andre
Date Verified: 2011-11-12
Section 3.2.4 says:
The original text is missing.
It should say:
ERR_NOSUCHCHANNEL
Notes:
Numeric reply list for Topic should include ERR_NOSUCHCHANNEL.
Errata ID: 3783
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Diman Todorov
Date Reported: 2013-11-05
Verifier Name: Barry Leiba
Date Verified: 2013-11-05
Section 2.3.1 says:
chanstring = %x01-07 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B chanstring =/ %x2D-39 / %x3B-FF
It should say:
chanstring = *49(%x01-06 / %x08-09 / %x0B-0C / %x0E-1F / %x21-2B /
%x2D-39 / %x3B-FF)
Notes:
Unfortunately the text in 1.3 which elaborates the interpretation of this BNF rule is unclear as to whether it's permitted to have 0 chanstring characters. The total length of the "channel" construct is 50 characters, so no chanstring can ever be more than 49 characters... but not all 49 characters will always be available, depending upon how "channel" is constructed.
Note that errata 385 addresses the same rule but a different issue. Errata 385 has been taken into consideration in this correction.
Errata ID: 4836
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Brenden Case
Date Reported: 2016-10-19
Verifier Name: Barry Leiba
Date Verified: 2019-04-30
Section 2.3.1 says:
key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
; any 7-bit US_ASCII character,
; except NUL, CR, LF, FF, h/v TABs, and " "
It should say:
key = 1*23( %x01-05 / %x07-08 / %x0C / %x0E-1F / %x21-7F )
; any 7-bit US_ASCII character,
; except NUL, CR, LF, ACK, h/v TABs, and " "
OR
key = 1*23( %x01-08 / %x0E-1F / %x21-7F )
; any 7-bit US_ASCII character,
; except NUL, CR, LF, FF, h/v TABs, and " "
Notes:
The hex for ACK and FF are x06 and x0C, respectively. The expression of the original text excludes ACK and includes FF. Therefore there is an error in either the expression or the comments following.
If the error is in the comments, then the first corrected text should be selected.
If the error is in the expression, then the second corrected text should be selected.
----- Verifier Notes -----
This is quite correct, though I have no idea which correction is right. In practice, I imagine it makes little difference, as it's unlikely that either character will actually be used.
Errata ID: 3255
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Robrecht Dewaele
Date Reported: 2012-06-12
Verifier Name: Barry Leiba
Date Verified: 2012-06-13
Section 5. Replies says:
353 RPL_NAMREPLY
"( "=" / "*" / "@" ) <channel>
:[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )
- "@" is used for secret channels, "*" for private
channels, and "=" for others (public channels).
It should say:
353 RPL_NAMREPLY
"( "=" / "*" / "@" ) <channel>
:[ "@" / "+" ] <nick> *( " " [ "@" / "+" ] <nick> )"
- "@" is used for secret channels, "*" for private
channels, and "=" for others (public channels).
Notes:
Missing double qoutes to end the reply string.
Errata ID: 3573
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Matthew Helsley
Date Reported: 2013-03-29
Verifier Name: Barry Leiba
Date Verified: 2013-03-29
Section 5.1 says:
returned. The exception to this is when a NAMES
message is sent with no parameters and all visible
channels and contents are sent back in a series of
RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
the end.
It should say:
returned. The exception to this is when a NAMES
message is sent with no parameters and all visible
channels and contents are sent back in a series of
RPL_NAMREPLY messages with a RPL_ENDOFNAMES to mark
the end.
Notes:
RPL_NAMEREPLY should be RPL_NAMREPLY
Errata ID: 4289
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tony Tam
Date Reported: 2015-03-06
Verifier Name: Barry Leiba
Date Verified: 2015-03-06
Section 2.3.1 says:
target = nickname / server
It should say:
target = nickname / servername
Notes:
There is no "server" rule.
Errata ID: 5017
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Les De Ridder
Date Reported: 2017-05-14
Verifier Name: Alexey Melnikov
Date Verified: 2017-05-19
Section 5.1 says:
352 RPL_WHOREPLY
"<channel> <user> <host> <server> <nick>
( "H" / "G" > ["*"] [ ( "@" / "+" ) ]
^
:<hopcount> <real name>"
It should say:
352 RPL_WHOREPLY
"<channel> <user> <host> <server> <nick>
( "H" / "G" ) ["*"] [ ( "@" / "+" ) ]
:<hopcount> <real name>"
Notes:
'>' should be ')'
Status: Reported (1)
RFC 2812, "Internet Relay Chat: Client Protocol", April 2000
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 8064
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mikhail Klimenko
Date Reported: 2024-08-04
Section 3.1.1 says:
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
It should say:
Numeric Replies:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
ERR_PASSWDMISMATCH
Notes:
Numeric reply list for the PASS message should include ERR_PASSWDMISMATCH as defined in section 5.2: Returned to indicate a failed attempt at registering a connection for which a password was required and was either not given or incorrect.
Status: Held for Document Update (4)
RFC 2812, "Internet Relay Chat: Client Protocol", April 2000
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 991
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Stefan Hoffmeister
Date Reported: 2007-06-10
Held for Document Update by: Peter Saint-Andre
Date Held: 2010-06-24
Section 2.3.1 says:
shortname = ( letter / digit ) *( letter / digit / "-" )
*( letter / digit )
; as specified in RFC 1123 [HNAME]
It should say:
shortname = ( letter / digit ) [ *( letter / digit / "-" ) ( letter / digit ) ]
Notes:
>From RFC 1123:
2.1 Host Names and Numbers
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
In RFC 952 the definition of a shortname looks like this
<name> ::=3D <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
from pending
Errata ID: 2306
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Timo Buhrmester
Date Reported: 2010-06-18
Held for Document Update by: Peter Saint-Andre
Section 1.3 says:
Space is used as parameter separator and command is used as a list item separator by the protocol).
It should say:
Space is used as parameter separator and comma is used as a list item separator by the protocol).
Errata ID: 3246
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jakob Kramer
Date Reported: 2012-06-06
Held for Document Update by: Barry Leiba
Section 3.1.8 says:
:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; Command
from Trillian from to disconnect
"cm22.eng.umd.edu" from the net with
comment "Server out of control".
It should say:
:Trillian SQUIT cm22.eng.umd.edu :Server out of control
; Command from Trillian to disconnect
"cm22.eng.umd.edu" from the net with
comment "Server out of control".
Notes:
A "from" too much. (I also inserted a new line break to make it look nicer and lined the comments up.)
Errata ID: 3786
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Diman Todorov
Date Reported: 2013-11-05
Held for Document Update by: Barry Leiba
Date Held: 2013-11-05
Section 3. says:
If multiple parameters is presented, then each MUST be checked for validity and appropriate responses MUST be sent back to the client.
It should say:
If multiple parameters are present, then each MUST be checked for validity and appropriate responses MUST be sent back to the client.
Notes:
We don't use errata for minor, obvious typos.
Status: Rejected (2)
RFC 2812, "Internet Relay Chat: Client Protocol", April 2000
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 3784
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Diman Todorov
Date Reported: 2013-11-05
Rejected by: Barry Leiba
Date Rejected: 2013-11-05
Section 2.5 says:
mask = *( nowild / noesc wildone / noesc wildmany )
It should say:
mask = *( nowild / (noesc wildone) / (noesc wildmany) )
Notes:
--VERIFIER NOTES--
The suggested change is not wrong, but neither is the existing text. In ABNF, concatenation
takes precedence over alternatives.
Errata ID: 3785
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Diman Todorov
Date Reported: 2013-11-05
Rejected by: Barry Leiba
Date Rejected: 2013-11-05
Section 2.3.1 says:
params = *14( SPACE middle ) [ SPACE ":" trailing ] =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
It should say:
params = *13( SPACE middle ) [ SPACE ":" trailing ] =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]
Notes:
--VERIFIER NOTES--
The correction is not wrong, but the original text is not wrong either. They're functionally equivalent.