Subject: Ftp-WG: Fwd: I-D ACTION:draft-saul-ftp-plus-00.txt

From: Mike Saul <[email-masked]>
Date: Thu, 31 Aug 2000 14:16:16 -0500

> >         Title           : FTP Plus
> >         Author(s)       : M. Saul
> >         Filename        : draft-saul-ftp-plus-00.txt
> >         Pages           : 22
> >         Date            : 29-Aug-00

> I would suggest a better name for the proposal would be "XTP extensions for
> FTP".  This avoids any possible confusion that your specification in a
> replacement for standard FTP.  At a quick glance, I would suggest this would
> simplify your specification considerably .. I see a number of places where
> you say "both FTP and FTP+".  Viewing your work as an extension to the
> existing FTP means you will only need to discuss where your specification
> departs from FTP.

> In addition, phrasing such as "a superset of RFC 959" can be misleading.  Do
> you mean to say that when using your XTP extensions, *ONLY* the protocol
> specified by RFC 959 should be implemented, or do you mean to say that your
> extensions are to be usable with which ever additional FTP-related RFCs may
> also be desired (including future specifications)?  Since you make reference
> to post-959 RFCs, I assume the later case applies.

Gregory,

Thanks for your comments.
In this specification, the details of what FTP is and how "both FTP 
and FTP+" exhibit similar characteristics were primarily for the benefit of 
the SMPTE audience.  For this forum, I agree that we only need to be
concerned with how FTP plus differs from FTP.

Leaving aside the name change for now, I do view this specification as an 
extension to FTP.  And this extension should be usable with RFC 959 as well as
additional FTP-related RFCs.

> Your use of X-commands is a poor choice for a specification.  The X-commands
> are reserved for local extensions and should not be used in formal
> specifications of this type.  If you have an existing implementation using
> these X-commands, you should list those commands for historical purposes;
> but you should define a new set of (non-X) commands, show the mapping from
> the X-command to the new specification, and encourage those using the
> X-commands to update to the new one.

> Some specific comments:
> 5.3.1.2
> Is it your intention here to create new lists of values for the IANA to
> maintain?

> You state that valid values for the transport specifier are "IP4" and "IP6"
> (which, I presume, you mean to be case-insensitive), what about future
> transport methods?  If IP8 were to be specified, do you envision your
> specification a _precluding_ its use?  What about vendor transport methods?
> Similar comments about network specifiers.

Perhaps a better solution here would be to use the EPRT and EPSV definitions 
of RFC 2428 in place of the XPRT and XPSV commands.  The only trouble is 
there is no address family number for XTP in RFC 1700.  We would have 
to get one from IANA.

> 5.3.1.4
> Your XPSV command requires knowledge of the server host's architecture which
> may not be available to the client.  The best solution would be to eliminate
> the need for the client to specify the "interface name".  Your comments at
> the end of the specification imply this is not possible.  Therefore, you
> should include some means for the server to report to the client when an
> "interface name" is required, and for the client to discover the set of
> correct values for the "interface name".

The "interface_name" parameter is optional.  However I agree
that the server should make this information available to the client.

> 5.3.1.6
> Your specification for the STOR command is un-parsable.  When I say
>     STOR My Documents/User Guide 2000 08 29
> I mean to store a file named "My Documents/User Guide 2000 08 29".  Your
> specification would have me storing a file named "My Documents/User Guide
> 2000", updating an existing file of that name by overwriting the 9th through
> 37th bytes (I'm assuming you mean 'offset' to be zero based).

> 5.3.1.7
> Same problem as 5.3.1.6

I understand.  So I would like to propose some other ways to do this.  
One alternative is to modify the REST command to add an optional length 
parameter.  The only problem is that in some cases we are not trying to 
RESTART a transfer and we are just trying to send part of a file.  So
instead of overloading the REST command perhaps a better solution would be 
to create a STPA (Store Parameters) and a RTPA (Retrieve Parameters) command?
There would be no file names associated with these commands, so the 
"file names with spaces" problem would be eliminated.  Note that having
both an offset and a length parameter (to some acceptable command) should
be of general interest to this working group and the IETF community.

> 5.3.2.1
> Your use of STAT with no filename is improper.  You should use FEAT to
> discover whether threading is supported.
> Your allegation that "the second form of STAT will never be used unless
> threading is supported" is false.  In addition, I see no reason to specify
> the reply text "must be" in any given format.  If your protocol requires
> formatted progress information, you should provide a command to that
> purpose.  Otherwise, a XTP-enabled FTP client could have significant
> difficult communicating with a non-XTP-enable server.

I believe that when this FTP+ draft was first proposed, RFC 2389 had not
been published.  RFC959 does state that for the STAT command "If no argument
is given, the server should return general status information about the server 
FTP process".  Perhaps FTP+ was interpreting this too broadly.  In any case,
I agree that the FEAT command would be more appropriate.
 
> 5.3.2.2
> Use FEAT instead of SITE to discover information about the server's
> implementation and capabilities.

Here we are not trying to find out whether the server supports the RATE
command; we want to know the current value.  Is FEAT still more appropriate?

> 5.3.2.3
> Unparsable (see my comments about 5.3.1.6).  Also, probably unnecessary; use
> MLST to discover information about files, directories, or other objects on
> the server.

I understand.  The second parameter to SIZE is not really necessary.

Mike