RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 20 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 ')'

Status: Reported (1)

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

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

Report New Errata



Advanced Search