RFC Errata
Found 13 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 ')'