Subject: Ftp-WG: I-D ACTION:draft-ietf-ftpext-mlst-05.txt

From: [email-masked]
Date: Tue, 22 Dec 1998 16:54:46 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Extensions to FTP Working Group of the IETF.

	Title		: Extensions to FTP
	Author(s)	: R. Elz, P. Hethmon
	Filename	: draft-ietf-ftpext-mlst-05.txt
	Pages		: 46
	Date		: 16-Dec-98
	
   In order to overcome the problems caused by the undefined format of
   the current FTP LIST command output, a new command is needed to
   transfer standardized listing information from Server-FTP to Client-
   FTP.  Commands to enable this are defined in this document.
 
   In order to allow consenting clients and servers to interact more
   freely, a quite basic, and optional, virtual file store structure is
   defined.
 
   This proposal also extends the FTP protocol to allow character sets
   other than US-ASCII[1] by allowing the transmission of 8-bit
   characters and the recommended use of UTF-8[2] encoding.
 
   Much implemented, but long undocumented, mechanisms to permit
   restarts of interrupted data transfers in STREAM mode, are also
   included here.
 
   Lastly, the HOST command has been added to allow a style of 'virtual
   site' to be constructed.
 
   In this version of this draft all previously open questions have been
   given answers, and thus deleted from the draft.  The HOST command
   appears for the first time in this draft, but the previous extended
   definition of the STAT command has been removed.  MLST now uses the
   control connection.  Some error response have been specified more
   precisely.  A few examples have been added, finally!  This paragraph
   will be deleted from the final version of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-05.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-ietf-ftpext-mlst-05.txt".

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-ftpext-mlst-05.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.

---

From: Alun Jones <[email-masked]>
Date: Tue, 22 Dec 1998 17:26:36 -0500

>	Filename	: draft-ietf-ftpext-mlst-05.txt

A couple of niggly comments...

HOST's 'ok' response is given as using a 234 code.  It may be helpful to
provide implementations if this code is changed to the normal greeting
code, 220 - this way, a very small wrapper could be written on, say, a Unix
inetd-based system to accept the HOST command and then pass the stream in
to a particularly configured copy of ftpd, without having to recompile ftpd.

Rather than saying the server "MUST NOT" reject the incoming client if it
does not send the HOST command, perhaps this should be a "SHOULD NOT".
After all, there's no reason for preventing the 'default environment' from
being one that is hostile to all logins.

The specification for "hostname" includes an optional period at its end.
Should this period be present, the HOST command should have no different
effect than if the period were not present.  Correct?

Perhaps we should mention in the preamble to the HOST command that this
does not require any changes in the URL format.

I just realised last week that the REST specs don't suggest whether a file
that is restarted should be truncated - i.e. if you've got a file of 20
bytes, and a client issues a REST 5 command, followed by a store of 10
bytes, how large should the file be?  Since STOR truncates the file, I
would suggest that RESTarting a STOR should do so also - but perhaps it
bears mentioning, so that no-one screws it up?

In my fevered state (without a computer) on vacation lately, I also dreamed
of a REST command that takes two parameters - the offset and the length -
allowing retrieval and storage of essentially random portions of files...
not in this draft, I hope, but I'm wondering if anyone has any interest in
this as a concept?

Alun.
~~~~

--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613     | us at [email-masked].  VISA / MC accepted.
Fax +1 (512) 378 3246   | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*******-- Alpha processors now supported under Windows NT --*******

---

From: Robert Elz <[email-masked]>
Date: Wed, 23 Dec 1998 02:28:06 -0500

Date:        Tue, 22 Dec 1998 17:26:36 -0500
    From:        Alun Jones <[email-masked]>
    Message-ID:  <[email-masked]>

  | HOST's 'ok' response is given as using a 234 code.

234 came from '2', positive completion (that part is obvious).
'3' Authentication and accounting
'4' Just to complete the sequence...

The second 2 in 220 would normally mean it was a message related to a
connection in some sense.   (The opening banner 220 is a message in response
to the connection being opened).

That's why a selected a 23x code, rather that something different.

All that said, if it is generally felt that a 220 might make implementations
easier, and no-one cares too much about blurring the 959 defined 
interpretations of the digits, then I will change it.

  | Rather than saying the server "MUST NOT" reject the incoming client if it
  | does not send the HOST command, perhaps this should be a "SHOULD NOT".
  | After all, there's no reason for preventing the 'default environment' from
  | being one that is hostile to all logins.

OK, sounds plausible enough (in practice, no-one will be able to reject
such things for a long time, as there are no distributed clients sending
HOST yet).

  | The specification for "hostname" includes an optional period at its end.
  | Should this period be present, the HOST command should have no different
  | effect than if the period were not present.  Correct?

Up to the server, I'd say.    I was trying to keep the syntax as loose as
possible.   I can add any clarifying text that is agreed upon of course
though.

  | Perhaps we should mention in the preamble to the HOST command that this
  | does not require any changes in the URL format.

There is no mention of URL anywhere in there, and personally, I would much
prefer to keep it that wat.

This is, of course, the first I-D that contains the HOST text (though that
section, or most of it, was previously posted to the list) so it is to be
expected that there will need to be some work on it.   Any suggestions for
improvements (especially those accompanied by actual text) will be gratefully
received.

  | I just realised last week that the REST specs don't suggest whether a file
  | that is restarted should be truncated

Good point, I shall correct that (for STOR, obviously this is irrelevant
for RETR, what the client chooses to do with the data it fetches is up to it).

For what it is worth though, the initial implementation of REST for stream
mode, the one that Rick Adams did (which is basically what my FTP server is),
did not operate that way.   I had never tried this before, and I doubt
that anyone else ever has either, but I managed to send a file, then by
the use of REST, replace a section in the middle of the file (I deliberately
sent a different, smaller, file into the middle of a larger one).

I'd consider that a bug though, just an unfortunate side effect of the
implementation.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 23 Dec 1998 03:50:21 -0500

When I came to attempt to insert appropriate text for this into the draft,
it dawned on me that this would probably be the wrong approach.

The REST command is intended to restart an interrupted transfer, not to
allow general file overwriting of some kind.

Because of that, my suggestion is that we make it undefined for the
client to send anything other than a file that had previously been
transmitted, and with a restart marker anything other than the result
of a SIZE command.

That allows the server to select a result for the SIZE command that will
allow it to correctly restart a transfer that had been interrupted, without
requiring them to be able to overwrite files from arbitrary byte counts.

That's always been the intent of the SIZE REST pair.

This also means that we don't really have to worry about what happens if
we overwrite a bit in the middle of a file - that can't possibly be continuing
an interrupted transfer, so would simply be undefined.

Any objections to that approach?

kre