errata logo graphic

Found 7 records.

Status: Verified (2)

RFC3659, "Extensions to FTP", March 2007

Source of RFC: ftpext (app)

Errata ID: 899

Status: Verified
Type: Editorial

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

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


Status: Held for Document Update (4)

RFC3659, "Extensions to FTP", March 2007

Source of RFC: ftpext (app)

Errata ID: 1500

Status: Held for Document Update
Type: Technical

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

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

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

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)

RFC3659, "Extensions to FTP", March 2007

Source of RFC: ftpext (app)

Errata ID: 901

Status: Rejected
Type: Technical

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.


Report New Errata