RFC Errata
Found 8 records.
Status: Verified (3)
RFC 3659, "Extensions to FTP", March 2007
Source of RFC: ftpext (app)
Errata ID: 899
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Verifier Name: RFC Editor
Date Verified: 2007-11-02
Section 6.5 says:
That those pathnames all exist does not imply that the TVFS sever will necessarily grant any kind of access rights to the named paths, or that access to the same file via different pathnames will necessarily be granted equal rights.
It should say:
That those pathnames all exist does not imply that the TVFS server will necessarily grant any kind of access rights to the named paths, or that access to the same file via different pathnames will necessarily be granted equal rights.
Notes:
typo: sever --> server
from pending
Errata ID: 900
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Verifier Name: RFC Editor
Date Verified: 2007-11-02
Section 7 says:
The MLST and MLSD commands also extend the FTP protocol as presented in STD 9, RFC 959 [3] and STD 3, RFC 1123 [9] to allow that transmission of 8-bit data over the control connection.
It should say:
The MLST and MLSD commands also extend the FTP protocol as presented in STD 9, RFC 959 [3] and STD 3, RFC 1123 [9] to allow the transmission of 8-bit data over the control connection.
Notes:
typo: that --> the
from pending
Errata ID: 6252
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Kissane
Date Reported: 2020-08-08
Verifier Name: Orie Steele
Date Verified: 2024-03-29
Section 10.2 says:
To add a file type to this OS specific registry of OS specific file types, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific file type, a definition of the syntax of the fact value, which must conform to the syntax of a token as given in this document, and a specification of the semantics to be associated with the particular fact and its values.
It should say:
To add a file type to this OS specific registry of OS specific file types, an applicant must send to the IANA a request, in which is specified the OS name, the OS specific file type, and a specification of the semantics to be associated with the particular OS specific file type.
Notes:
It appears that the text in section 10.2 has been copy/pasted from section 10.1, without applying the necessary adjustments for the differences between OS-specific facts and OS-specific filetypes. While OS-specific facts do have values (see section 7.2), there is no concept of a "value" of an OS-specific filetype defined in the RFC (see section 7.5.1.5).
This error effectively makes it impossible to register an OS-specific filetype with IANA, were IANA to follow the wording of the RFC to the letter – IANA must demand a "definition of the syntax of the fact value" for every filetype registration, despite the fact that request makes no sense for a filetype as defined in the RFC.
Status: Held for Document Update (4)
RFC 3659, "Extensions to FTP", March 2007
Source of RFC: ftpext (app)
Errata ID: 1500
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Maik Reiß (Reiss)
Date Reported: 2008-09-02
Held for Document Update by: Barry Leiba
Section 7.7.4 says:
7.7.4. A More Complex Example ... C> MLSD test S> 150 BINARY connection open for MLSD test D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test D> Type=pdir;Perm=e;Unique=keVO1+d?3; .. D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar
It should say:
7.7.4. A More Complex Example
...
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=symlink;Perm=;Unique=keVO1+4G4; foobar
... more lines ...
D> Type=dir;Perm=;Unique=keVO1+4G4; /foobar; does originally point to here
Notes:
The sample sequence in chapter 7.7.4 uses an example which is completely wrong, because it violates the basic BNF rules of its own document.
Please, see the definition, which is violated:
7.2. Format of MLSx Response
The format of a response to an MLSx command is as follows:
...
entry = [ facts ] SP pathname
facts = 1*( fact ";" )
fact = factname "=" value
...
Remember, a fact may not contain ";" or SPC (" ")!
Now take a look into the bad example:
7.7.4. A More Complex Example
...
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=slink:/foobar;Perm=;Unique=keVO1+4G4; foobar
the last line uses the fact "Type=OS.unix=slink:/foobar;". While this line in special not violates the rules at the moment, it implies that "Type=OS.unix=slink:" starts printing the original link target of any given symbolic link. Not wrong till here, but in case a link points to an original directory which name contains a ";" or, most worse, a "; " sequence, it will
lead any client side PI into misinterpretation of the line.
Even more worse, some actual public servers already use this bad syntax. Some can be found at least in the Swiss. It looks like they are running proftpd under Linux operating system, but this is unconfirmed for now.
Solution:
The chapter 7 of the same document allows another approach to tell the client about the original destination of a symlink. This solution uses two lines of answer, see my example:
C> MLSD test
S> 150 BINARY connection open for MLSD test
D> Type=cdir;Perm=el;Unique=keVO1+ZF4; test
D> Type=pdir;Perm=e;Unique=keVO1+d?3; ..
D> Type=OS.unix=symlink;Perm=;Unique=keVO1+4G4; foobar points somewhere else
... more lines ...
D> Type=dir;Perm=;Unique=keVO1+4G4; /foobar; does originally point to here
because of the "Unique" fact, a client PI can now collect all lines with the fact "Type=OS.unix=symlink" and file it under an associative array (map, hastable) with "keVO1+4G4" as the access key. Once the client side parser again gets "Unique=keVO1+4G4", it now can record "/foobar; does point to here" as the original point where foobar points to.
This is exactly, what chapter 7.5.1.5 defines about the "Unique" fact. Please read:
Note: Where the underlying system supports a file type that is
essentially an indirect pointer to another file, the NVFS
representation of that type should normally be to represent the file
that the reference indicates. That is, the underlying basic file
will appear more than once in the NVFS, each time with the "unique"
fact (see immediately following section) containing the same value,
indicating that the same file is represented by all such names.
Useful to say, setting the slink into double quotes like suggested by some developers:
D> Type=OS.unix="slink:/foobar";Perm=;Unique=keVO1+4G4; foobar
would violate the same documents BNF rules (see RCHAR), as well it would require escaping of any DQUOTE in the link pathname itself. This, again, would violate RFC959 which not defines escaping of characters.
Finally, FTP does not support 2 pathnames at the same line at all. This convention sould never been broken.
Errata ID: 2850
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Mykyta Yevstifeyev
Date Reported: 2011-06-29
Held for Document Update by: Peter Saint-Andre
Section 2.5 says:
and each sequence of lines that begin "D> " was sent from the server-PI to the user-PI over a data connection created just to send those lines and closed immediately after.
It should say:
and each sequence of lines that begin "D> " was sent from the server-DTP to the user-DTP over a data connection created just to send those lines and closed immediately after.
Notes:
In this case the acting parties are DTPs, not PIs.
Errata ID: 903
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Held for Document Update by: Peter Saint-Andre
Section 9 says:
[...]. Unless the "media-type" fact is
provided in a MLSx response nor is any advice given here that would
allow determining the content type. [...]
It should say:
[...]. Unless the "media-type" fact is
provided in a MLSx response, no advice is given here that would allow
determining the content type. [...]
Notes:
This sentence apparently is garbled a bit.
from pending
Errata ID: 2496
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Anthony Bryan
Date Reported: 2010-08-21
Held for Document Update by: Peter Saint-Andre
Throughout the document, when it says:
3.2 ... Various 4xy replies are also possible in appropriate circumstances. 4.2 ... Various 4xy replies are also possible in appropriate circumstances. 7.2.1 Many of the 4xy and 5xy responses defined in section 4.2 of STD 9, RFC 959 [3] are possible in response to the MLST and MLSD commands. ... Other replies (530, 553, 503, 504, and any of the 4xy replies) are also possible in appropriate circumstances.
It should say:
3.2 ... Various 4yz replies are also possible in appropriate circumstances. 4.2 ... Various 4yz replies are also possible in appropriate circumstances. 7.2.1 Many of the 4yz and 5yz responses defined in section 4.2 of STD 9, RFC 959 [3] are possible in response to the MLST and MLSD commands. ... Other replies (530, 553, 503, 504, and any of the 4yz replies) are also possible in appropriate circumstances.
Notes:
RFC 959, Section 4.2 refers to these reply codes as 4yz and 5yz, instead of 4xy and 5xy.
Status: Rejected (1)
RFC 3659, "Extensions to FTP", March 2007
Source of RFC: ftpext (app)
Errata ID: 901
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-04-14
Rejected by: Pete Resnick
Date Rejected: 2011-05-16
Section 7.5.4 says:
The create fact indicates when a file, or directory, was first created. Exactly what "creation" is for this purpose is not specified here, and may vary from server to server. About all that can be said about the value returned is that it can never indicate a later time than the modify fact.
It should say:
The create fact indicates when a file, or directory, was first created. Exactly what "creation" is for this purpose is not specified here, and may vary from server to server.
Notes:
It is one of the benefits of 'Create' timestamps for directory
entries that there is *no* enforced relationship between that
timestamp and the 'Modify' timestamp related to the file *content*.
We still support legacy systems from Hewlett-Packard that indeed
maintain three timestamps per directory entry: 'Create', 'Modify',
and 'Access'. The very useful behaviour of the File System and
the proprietary Networking Services is as follows: If you move a
file to another directory or copy it (within a system, or across
the network), the 'Modify' timestamp does not change (since the
file content is unchanged from what it was then), only the 'Create'
timestamp of the new directory entry is set to the current time.
(This means the 'Modify' timestamp behaves like a 'last update'
timestamp embedded in the file content, e.g., in a PDF file.)
In this case, the create fact would have to be *later* than the
modify fact, for RFC 3659. Naturally, if a file was being edited,
the 'Modify' timestamp changes and will then be later than the
'Create' timestamp.
The natural behaviour of a hypothetical FTP client implementing
RFC 3659 in such environment, when performing a 'get' operation,
would be to obtain the modify timestamp of the remote file via
MLSx or MDTM and, after performing the RETR (and, perhaps verifying
the 'atomicity' of the transfer via another MDTM that should deliver
the same response again) setting the 'Modify' timestamp of the local
copy of the file to the moment corresponding to the MDTM result
value (or the modify fact value from the MLSx).
--VERIFIER NOTES--
This is a technical change that may be against the consensus of a WG and therefore is not appropriate for an erratum.