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

From: "Michael A. Dolan" <[email-masked]>
Date: Wed, 30 Aug 2000 08:52:38 -0500

I'd like to call this ID to the WG's attention.  Please direct your 
comments to the author, Mike Saul (cc'd above).

>To: IETF-Announce: ;
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-saul-ftp-plus-00.txt
>Date: Wed, 30 Aug 2000 06:49:46 -0400
>Sender: [email-masked]
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : FTP Plus
>         Author(s)       : M. Saul
>         Filename        : draft-saul-ftp-plus-00.txt
>         Pages           : 22
>         Date            : 29-Aug-00
>
>The terminology used in this document is a bit television centric
>and thus may be somewhat unusual to the internet community.  The
>reader is referred to a joint task force report of the Society of
>Motion Picture and Television Engineers (SMPTE) and the European
>Broadcast Union (EBU) [1] as background material.
>Also, this document may refer to itself as a
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-saul-ftp-plus-00.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-saul-ftp-plus-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-saul-ftp-plus-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-saul-ftp-plus-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-saul-ftp-plus-00.txt>

------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Wed, 30 Aug 2000 10:18:41 -0500

> >         Filename        : draft-saul-ftp-plus-00.txt

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.

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.

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

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

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.

5.3.2.2

Use FEAT instead of SITE to discover information about the server's
implementation and capabilities.

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.