RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 16 records.

Status: Verified (10)

RFC 959, "File Transfer Protocol", October 1985

Note: This RFC has been updated by RFC 2228, RFC 2640, RFC 2773, RFC 3659, RFC 5797, RFC 7151

Source of RFC: Legacy
Area Assignment: app

Errata ID: 568
Status: Verified
Type: Technical
Publication Format(s) : TEXT

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: 3039
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Julien Moutinho
Date Reported: 2011-12-01
Verifier Name: Pete Resnick
Date Verified: 2011-12-29

Section 5.3.2 says:

<number> ::= any decimal integer 1 through 255

It should say:

<number> ::= any decimal integer 0 through 255

Notes:

if 0 is not allowed, one cannot even represent 127.0.0.1 with
<host-number> ::= <number>,<number>,<number>,<number>

[Verifier Note: This does allow syntactically for nonsense values for <byte-size>, <port-number>, and <host-number>, but this was also true in the current syntax.]

Errata ID: 4869
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Megan Ruggiero
Date Reported: 2016-11-21
Verifier Name: Barry Leiba
Date Verified: 2021-03-07

Section 5.4 says:

               CDUP
                  200
                  500, 501, 502, 421, 530, 550

It should say:

               CDUP
                  250
                  500, 501, 502, 421, 530, 550

Notes:

The reply codes for CDUP are supposed to be identical to those of CWD according to Appendix II - Reply Codes. Thus, the proper return code for a successful CDUP should be 250 - Requested file action okay, not 200 - Command okay.

Errata ID: 5451
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: David LAMBERT
Date Reported: 2018-08-03
Verifier Name: Barry Leiba
Date Verified: 2021-03-07

Section APPENDIX II says:

         CWD /usr/dm
         200 directory changed to /usr/dm

...
         CWD overrainbow
         431 No such directory

It should say:

         CWD /usr/dm
         250 directory changed to /usr/dm

...
         CWD overrainbow
         550 No such directory

Notes:

Reply codes in the examples are not conform to the specification :
200 is not a valid code for CWD. It should be 250 (Requested file action okay, completed).
431 is not a valid code for CWD and is not defined in the RFC. It should be 550 (Requested file action not taken).

Errata ID: 2410
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Anthony Bryan
Date Reported: 2010-08-03
Verifier Name: Alexey Melnikov
Date Verified: 2010-08-03

Section Appendix III says:

   Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
   Commands", RFC 776, BBN, December 1980.

It should say:

   Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP
   Commands", RFC 775, BBN, December 1980.

Notes:

Typo.
RFC 775 "Directory Oriented FTP Commands"
RFC 776 "Assigned Numbers"

Errata ID: 2024
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: John Klensin
Date Reported: 2010-01-27
Verifier Name: Alexey Melnikov
Date Verified: 2010-02-10

Section 4.1.3 says:

In the description of the SYST command, the second sentence reads:

"The reply shall have as its first
word one of the system names listed in the current version
of the Assigned Numbers document [4]."

Where [4] points to the then-current RFC 943.

It should say:

The reply shall have as its first
word one of the system names listed in the current version
of the IANA "Operating System Names" Registry (<http://www.iana.org/assignments/operating-system-names> at
the time of this writing)

Notes:

RFC 943 was several times obsolete by the time the community discontinued regular updates to the "Assigned Numbers" RFCs (see RFC 3232, January 2002). The clear intent was that SYST be able to use operating system names from that registry. An erratum pointing to the registry itself may aid the confused as well as providing better tracking and serving as placeholder in case RFC 959 is ever updated.

Errata ID: 4138
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Eugene Adell
Date Reported: 2014-10-21
Verifier Name: Barry Leiba
Date Verified: 2014-11-27

Section 2.1 says:

      This current edition of the FTP specification is intended to
      correct some minor documentation errors, to improve the
      explanation of some protocol features, and to add some new
      optional commands.

      In particular, the following new optional commands are included in
      this edition of the specification:

         CDUP - Change to Parent Directory

         SMNT - Structure Mount

         STOU - Store Unique

         RMD - Remove Directory

         MKD - Make Directory

         PWD - Print Directory

         SYST - System

      This specification is compatible with the previous edition.  A
      program implemented in conformance to the previous specification
      should automatically be in conformance to this specification.

It should say:

      This current edition of the FTP specification is intended to
      correct some minor documentation errors, to improve the
      explanation of some protocol features, to add some new
      optional commands, and to remove obsolete ones.

      In particular, the following new optional commands are included in
      this edition of the specification:

         CDUP - Change to Parent Directory

         SMNT - Structure Mount

         STOU - Store Unique

         RMD - Remove Directory

         MKD - Make Directory

         PWD - Print Directory

         SYST - System

      All commands for the mail service are now obsolete and removed
      from this FTP specification. These commands are MLFL, MAIL,
      MSND, MSOM, MSAM, MRSQ, MRCP.  The return codes used for the
      mail service are also removed: 151, 152, 354.  Return code 215
      is reassigned here to another use.

      This specification is compatible with the previous edition.  A
      program implemented in conformance to the previous specification
      should automatically be in conformance to this specification, as
      long as it does not use the obsolete commands.

Notes:

Before claiming the specification is compliant with the previous version, noting what is added is not enough; we need to note what was removed also.

Errata ID: 6455
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Panchenko
Date Reported: 2021-03-07
Verifier Name: Barry Leiba
Date Verified: 2021-03-07

Section 2.3 says:

         Ease of implementaion, sharing code, and modular programming
         argue for the second approach.

It should say:

         Ease of implementation, sharing code, and modular programming
         argue for the second approach.

Notes:

Typo.

Errata ID: 6456
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Panchenko
Date Reported: 2021-03-07
Verifier Name: Barry Leiba
Date Verified: 2021-03-07

Section 2.1 says:

      RFC 354 obsoleted RFCs 264 and 265.  The File Transfer Protocol
      was now defined as a protocol for file transfer between HOSTs on
      the ARPANET, with the primary function of FTP defined as
      transfering files efficiently and reliably among hosts and
      allowing the convenient use of remote file storage capabilities.

It should say:

      RFC 354 obsoleted RFCs 264 and 265.  The File Transfer Protocol
      was now defined as a protocol for file transfer between HOSTs on
      the ARPANET, with the primary function of FTP defined as
      transferring files efficiently and reliably among hosts and
      allowing the convenient use of remote file storage capabilities.

Notes:

Misspelled "transferring".

Errata ID: 6457
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Ivan Panchenko
Date Reported: 2021-03-07
Verifier Name: Barry Leiba
Date Verified: 2021-03-07

Section 3.3 says:

      Reuse of the Data Connection:  When using the stream mode of data
      transfer the end of the file must be indicated by closing the
      connection.  This causes a problem if multiple files are to be
      transfered in the session, due to need for TCP to hold the
      connection record for a time out period to guarantee the reliable
      communication.  Thus the connection can not be reopened at once.

It should say:

      Reuse of the Data Connection:  When using the stream mode of data
      transfer the end of the file must be indicated by closing the
      connection.  This causes a problem if multiple files are to be
      transferred in the session, due to need for TCP to hold the
      connection record for a time out period to guarantee the reliable
      communication.  Thus the connection can not be reopened at once.

Notes:

Misspelled "transferred".

Status: Reported (1)

RFC 959, "File Transfer Protocol", October 1985

Note: This RFC has been updated by RFC 2228, RFC 2640, RFC 2773, RFC 3659, RFC 5797, RFC 7151

Source of RFC: Legacy
Area Assignment: app

Errata ID: 7430
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Gordon Steemson
Date Reported: 2023-04-23

Section 5.2 says:

The direction of the transfer and the port used will be determined by the FTP service command.

It should say:

The direction of the transfer will be determined by the FTP service command.

Notes:

Per RFC 1123 (section "4.1.2.12 Connections"), the clause "and the port used" was a remnant of an earlier version of the standard, and ought to have been removed during the rewrite that produced RFC 959. Admittedly, RFC 1123 does only use the term "should" in saying to ignore the wording, as the behaviour described had been correct at one time -- but that time was meant to have ended 38 years ago. For the few brave souls who attempt to program FTP support in the modern day, this really ought to explicitly annotate the actual RFC.

Status: Held for Document Update (3)

RFC 959, "File Transfer Protocol", October 1985

Note: This RFC has been updated by RFC 2228, RFC 2640, RFC 2773, RFC 3659, RFC 5797, RFC 7151

Source of RFC: Legacy
Area Assignment: app

Errata ID: 2411
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Anthony Bryan
Date Reported: 2010-08-03
Held for Document Update by: Peter Saint-Andre

Section 2.2 says:

      type

         The data representation type used for data transfer and
         storage.  Type implies certain transformations between the time
         of data storage and data transfer.  The representation types
         defined in FTP are described in the Section on Establishing
         Data Connections.

It should say:

      type

         The data representation type used for data transfer and
         storage.  Type implies certain transformations between the time
         of data storage and data transfer.  The representation types
         defined in FTP are described in the Section on Data Representation
         and Storage.

Notes:

The representation types defined in FTP are described in Section 3.1, Data Representation and Storage, or more specifically Section 3.1.1, Data Types.

Errata ID: 1941
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Tomasz Kluza
Date Reported: 2009-11-09
Held for Document Update by: Peter Saint-Andre

Section 3.1.1.5. says:

(...)Therefore, these types have a second parameter
            specifying one of the following three formats:
3.1.1.5.1.  NON PRINT
(...)
3.1.1.5.2.  TELNET FORMAT CONTROLS
(...)
     
3.1.1.5.2.  CARRIAGE CONTROL (ASA)

It should say:

(...)Therefore, these types have a second parameter
            specifying one of the following three formats:
3.1.1.5.1.  NON PRINT
(...)
3.1.1.5.2.  TELNET FORMAT CONTROLS
(...)
     
3.1.1.5.3.  CARRIAGE CONTROL (ASA)

Notes:

Two Sections in the RFC have the same number in the document whereas the The Carriage Control (ASA) should have 3.1.1.5.3. in the structure of the RFC document since its a third format of the possible value for the parameter mention in the statement "Therefore, these types have a second parameter specifying one of the following three formats" ATM it has the same 3.1.1.5.2. as the Telnet Format Controls.

Errata ID: 2503
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Anthony Bryan
Date Reported: 2010-08-26
Held for Document Update by: Peter Saint-Andre

Section 5.3 says:

   5.3.  COMMANDS

      The commands are Telnet character strings transmitted over the
      control connections as described in the Section on FTP Commands.
      The command functions and semantics are described in the Section
      on Access Control Commands, Transfer Parameter Commands, FTP
      Service Commands, and Miscellaneous Commands.

It should say:

   5.3.  COMMANDS

      The commands are Telnet character strings transmitted over the
      control connections as described in the Section on FTP Commands.
      The command functions and semantics are described in the Section
      on Access Control Commands, Transfer Parameter Commands, and FTP
      Service Commands.

Notes:

There does not appear to be a section on Miscellaneous Commands, although SITE and NOOP are listed as "Miscellaneous Commands" in Section 5.4, Sequencing of Commands and Replies. SITE and NOOP are described in 4.1.3, FTP Service Commands.

Status: Rejected (2)

RFC 959, "File Transfer Protocol", October 1985

Note: This RFC has been updated by RFC 2228, RFC 2640, RFC 2773, RFC 3659, RFC 5797, RFC 7151

Source of RFC: Legacy
Area Assignment: app

Errata ID: 3040
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: mark hays
Date Reported: 2011-12-01
Rejected by: Pete Resnick
Date Rejected: 2011-12-29

Section 5.3.2 says:

<number> ::= any decimal integer 1 through 255

It should say:

<byte-size> ::= any decimal integer 1 through 255
[...]
<number> ::= any decimal integer 0 through 255

Notes:

I agree with the author of errata ID 3039 that excluding 0 from <number> is problematic. However, <number> is also used in the definition of <byte-size>. The text in 3.1.1.4 says that"The value of Byte size must be a decimal integer; there is no default value." Strictly speaking, then, 0 is a valid value but I don't see how zero could lead to a sensible result. Indeed the term "decimal integer" is undefined so perhaps negative values are permissible?
--VERIFIER NOTES--
See Erratum 3039. Though the change there does allow for nonsense values for <byte-size>, so does the current syntax in 959. I have accepted 3039 and rejected this as duplicate.

Errata ID: 4575
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Dave Mackay
Date Reported: 2016-01-01
Rejected by: Barry Leiba
Date Rejected: 2016-01-21

Section 5.2. says:

         User-PI - Server A                User-PI - Server B
         ------------------                ------------------

         C->A : Connect                    C->B : Connect
         C->A : PASV
         A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2
                                           C->B : PORT A1,A2,A3,A4,a1,a2
                                           B->C : 200 Okay
         C->A : STOR                       C->B : RETR
                   B->A : Connect to HOST-A, PORT-a

It should say:

         User-PI - Server A                User-PI - Server B
         ------------------                ------------------

         C->A : Connect                    C->B : Connect
         C->A : PASV
         A->C : 227 Entering Passive Mode. (A1,A2,A3,A4,a1,a2).
                                           C->B : PORT A1,A2,A3,A4,a1,a2
                                           B->C : 200 Okay
         C->A : STOR                       C->B : RETR
                   B->A : Connect to HOST-A, PORT-a

Notes:

The reply code for 227 in sections 4.2.1 and 4.2.2. shows <host-port> surrounded by parenthesis with a period at the end, whereas the example in section 5.2 does not.
--VERIFIER NOTES--
As Section 4.2 states, only the numeric value of the reply code is significant to the protocol; the text is intended for human readers. The parentheses and period are not significant.

Report New Errata



Advanced Search