Subject: RFC 3659

From: Alfred Hönes <[email-masked]>
Date: Sat, 14 Apr 2007 13:20:57 +0200 (MESZ)

Hello,
after studying the recently published RFC 3659 (FTP Ext'ns)
authored by you, I would like to send you a few comments.

First of all, thanks for eventually completing this effort!
Apparently this document has suffered a record-breaking delay
in the publication process.
Perhaps, there are hidden reasons (that should not be made public
and that I do not really need to know) that have lead to the final
change in the author list, dropping R. Elz from it.
I just have observed that I have not received any more responses on
messages sent to R. Elz (related to this topic), since several years.

My personal entry into the IETF 'business' has been closely related
with that project:

Back in 2001, we were running into trouble with interoperability
problems using HP's FTP implementations under various operating
systems; the hotline finally arrived at arranging a contact with
the HP Labs, where Rick Adams in turn redirected me to Robert Elz,
which then pointed me to the then current ftpext-mlst draft for
documentation that was missing from HP's man pages, where, instead
of giving details, pointers to an "upcoming RFC" had been placed.

It must have been near the end of 2001 when I then performed my
first detailed I-D review ever, on that draft, sending a long
list of editorial enhancement proposals to Robert Elz.

Many of these issues have been addressed; but, unfortunately,
reading the published RFC I find a few textual flaws left in
the text, or newly introduced since 2001.
These are listed below.

Related deficiencies with the IANA registry per Section 10 of
RFC 3659 have just been reported in a separate message to the
IANA that has been copied to you, Paul.  I expect they will be
contacting you for cross-checking.

(1)  Typo

In Section 6.5 of RFC 3659, on mid-page 22, there is a typo;
"sever" apparently should be "server".
Thus the paragraph,
                                                               vvvvv
|  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.

should in fact say:
                                                               vvvvvv
|  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.

(2)  Typo

The final paragraph of Section 7, on page 23, 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 perhaps better 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.  [...]
                                                          ^^^

(3)  Improper specification?

The first paragraph of Section 7.5.4, on page 33, 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.

IMHO, the last sentence is inappropriate and should better have been
deleted.

Rationale:

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).

(4)  Typo (punctuation)

In the 5th line of the text in Section 7.7.3, on page 39,

     "... relative to the servers current directory ..."

should better say:

     "... relative to the server's current directory ..."

(5)  Typo (word replication)

The text at the end of Section 7.7.11, on mid-page 49, says:

                                                           [...]  Note
   also that this server does not show a "pdir" entry when listing the
|  contents of the root directory of the virtual filestore; however, it
|  does however include multiple "cdir" and "pdir" entries when it feels
   inclined.  [...]

It should perhaps avoid the repeated "however" and say:

                                                           [...]  Note
   also that this server does not show a "pdir" entry when listing the
   contents of the root directory of the virtual filestore; however, it
|  does include multiple "cdir" and "pdir" entries when it feels
   inclined.  [...]

(6)  Garbled text?

The last paragraph of Section 9, on page 55, 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.  [...]
                              ^^^^^^^^^^^^^^^^^^^^^^^^

This sentence apparently is garbled a bit.  I suspect that 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.  [...]
                              ^^^^^^^^^^^^^^^^^^^^

I leave it to your decision whether to address these issues
by an RFC Errata Note, and which items to include there.
Preferrably, you should submit an Author's Errata Note, making
freely use of the material supplied above.  But if you like,
I can formally submit an Errata Note on my own, with your consent.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+