RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 13 records.

Status: Verified (13)

RFC 2812, "Internet Relay Chat: Client Protocol", April 2000

Source of RFC: IETF - NON WORKING GROUP
Area 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 ')'

Report New Errata