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

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 1 Sep 2000 03:35:14 -0500

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

If all you're missing is an assignment of an address family name/number
from IANA, the best solution would be to take that route.  It should make a
number of things easier as well; for or instance, I would not be surprise
to find that, with the assignment, you would find it a lot easier to get
POSIX acceptance of XTP's address family for such things as the bind()
function.

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

Historically, the intention of FTP was _file_ transfer.  Not record
transfer, nor any form of partial-file transfer.

The use of REST to restore an interrupted transfer arose from the
realization that most files available via FTP do not change very often (if
ever), some are exremely large, and one would desire to not have to spend
the bandwidth on retransmission of the first few gigabyte of a download
simply because of a loss of connectivity.

The problem with REST is there is no way to ensure the file has, in fact,
not changed.  This is why its use with stream-mode transfers has never been
sanctioned.  The MLST draft codifies existing practice in this respect,
simply by pointing out that one must take steps to attempt to avoid the
problem of pasting the end of one generation of a file onto the beginning
of an earlier one; it offers suggestions on how to do this, but no
solutions.

You will find the FTP Working Group divided on the subject of partial
transfers.  The majority view, however, has historically been that the FTP
is not intended to be a replacement for more general file access methods
(such as NFS and SMB).  So I would expect sufficient resistance to a
generalized record-update method such as your proposal appears to be
attempting to provide to effectively block any such effort.

The question is: what are you attempting to accomplish?  If what you're
trying to do is provide a means to download (and, perhaps, upload and
replace), say, a specific frame or scene from a multi-frame or multi-scene
video file I would suggest the best way to handle this would be to
synthesis some form of "partioning" on the file.  One could take the view
that your "video file" is simply a "directory" and that each "file" within
it corresponds to some "frame" or "scene".

With such a scheme, one approach would be to normalize the naming
(addressing) within the FTP NVFS.  Since your current desire is to use raw
offsets and lengths, this does not seem appealing.  If, however, one
chooses to view a video file as a "partitioned dataset" where each part has
a symbolic name, this would seem the way to go.

Another scheme would be, as you seem to be suggesting, some form of
parametric lead-in command.  I would envision this working similar to RNFR,
in that the lead-in command would return an intermediate reply and the
server would enter a state waiting for a STOR or RETR command.

Bear in mind that there will be no means to ensure synchonization.  This
means that read-modify-write sequences will be inherently unreliable.  We
have that problem now, but only at the "file" level, and the problem is
mitigated by the fact that most FTP sites separate upload and download
areas, leaving the problem of in-place replacement of files to the users to
handle.

It's late, and the only reason I'm online right now is my cold meds wore
off.  My mind is spinning with ideas on how to handle what I see as the
problem you're trying to solve.  I'll leave this subject for now, with the
following thoughts:

 - as I see it, there are two issues; the support for XTP as a transport
   mechanism .. which obtaining IANA assignment would be the first step
   toward solving .. and the ability to store or retrieve partial files.

 - I do not see how partial file support is a _requirement_ for XTP
   support.

 - it would help me if I knew what you're trying to accomplish with partial
   file support.  Specifically, is raw byte-offset the only acceptable
   method to you?  If what you're really trying to do is say "replace this
   scene with this other one", that's a completely different problem from
   simple byte offsets.

 - the problem of synchonization in partial file support is sufficiently
   complex that it's unlikely you will be able to solve it within the
   confines of the FTP.  While it is possible to offer some limited support
   for it, you might be better off shifting the problem to some other
   protocol which already has solutions (such as NFS or SMB).

 - separating your needs to support XTP as a transport mechanism from your
   needs for partial file support is probably a Good Idea(tm).  It means
   the base support of the transport mechanism can go forward.  At the same
   time discussion of partial file support could be made more generic.  Put
   another way: I see apples and oranges in your basket; why not make it
   two baskets so those who only want apples don't have to take the oranges
   with them?

> 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?

Yes.  And OPTN could be used to modify the value if you so desire.

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

What I was getting at was that you were attempting to discover a "fact"
about a file.  While MLST is not yet at RFC stage, my suggestion is that it
would be more appropriate to use MLST to discover the fact.  All that
should be required in this case (once MLST reaches RFC stage) would be the
registration of the "fact" code(s) with IANA.

-- 

Gregory A Lundberg              WU-FTPD Development Group
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195