Subject: Ftp-WG: thoughts on ftp extensions and caching

From: Dave Cridland <[email-masked]>
Date: Tue, 6 Jun 2000 14:03:39 -0500

My theory:
 
1) We have a problem here. We know that much.
2) The problem is in three parts:
a) STREAM mode transfers, which I think probably account for all FTP
transfers these days, do not have any indication of whether a file has been
successfully RETRieved, although the response code after the transfer will
usually give it away.
b) HTTP->FTP gateways are required to give some indication of when the file
has been transferred, either in advance, by the Content-Length method, or
inherently, using the Chunked Encoding method. These are required by
HTTP/1.1 for keeping alive connections, as I understand things.
c) HTTP->FTP gateways which perform some kind of policy based caching
require some file size indication in order to know whether to consider the
file for caching or not. There is some speculation about whether the size
here needs to be wholly accurate, or whether it can be approximate.
3) There is significant overhead, as discussed before on this list, for
determining the transfer size (as given by the SIZE command) of a file.
There is no significant overhead in giving an approximate size, as given by
the "size" fact of MLS*.
 
My suggestions:
 
a) In the real world, I've experienced few problems with being unsure of
whether the file has been transferred or not. In the absence of finding the
transfer size, I find that the use of the response code afterwards seems to
give a reliable indication with today's networks and technology.
 
Having said that, it'd be nice if the file transfer size was indicated
during commencement of a download. However, if I relied on it, I'd be using
SIZE beforehand.
 
So, FTP servers which support our currently non-existent extension should
give a "transfer-size" fact in any MLS* line, including that given by
responses to RETR, where this does not place a significant burden on the FTP
server. This includes caching responses to previous requests for SIZE if
this is possible and/or desirable.
 
Note that this is only a solution for downloads, and not for uploads. The
only way I can think of for uploads would be to suggest the use of the ALLO
command prior to the upload, or else define another, similar, command for
this use. This is a tad unfortunate, as I have a sneaky feeling that uploads
in STREAM mode are by far the more problematic.
 
b) The solution to this seems to me to be Chunked Encoding, where the
transfer-size is not available, and Content-Length where it is. It fits the
bill nicely, and is interoperable with all current FTP servers.
 
HTTP->HTTP gateways chaining onto the back of the HTTP->FTP gateway may
suffer some loss of meta-information, however. See below:
 
c) Where the transfer-size is available form the FTP server, the HTTP->FTP
gateway should use this.
 
Where it isn't, the HTTP->FTP server should use the approximate size, where
available, for policy decisions. This should be accurate enough in almost
every case. Where there is no size information available, which includes
current FTP servers, the method for policy decision making is undefined,
however, HTTP->FTP gateway implementors should be aware that using STAT
<file> on MLST capable FTP servers will be faster than SIZE <file> in some
cases.
 
Ideally, however, the HTTP->FTP gateway should avoid using multiple commands
due to latency issues, and should instead attempt to either cache the
information from previous MLSD requests, or make their decisions based on
some other means.
 
Since HTTP->HTTP gateways chaining onto the HTTP->FTP gateway may also
require this information for their own policy decisions, this "approximate
size" meta-information, however derived, should be passed back in some as
yet undefined HTTP header (Content-Approx-Length?).

That's my thoughts for now, anyways. Feel free to rip them apart, but do
bear in mind that while I realise there's a problem for HTTP->FTP gateways,
I'm fairly sure it's really two seperate problems, and if the problems
appear to be in the current, limited set of implementations, then its these
which we should fix as a priority.

 -----Original Message-----
From: Stephen Head [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Tuesday, June 06, 2000 5:58 PM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and caching

Dave Cridland wrote: 

I'm unconvinced that it's needed, though, in any case. 

Yes, if a HTTP->FTP proxy system really wants to use Content-Length headers,
that's fine, but given that we're mainly interested in HTTP/1.1, I can't see
the issue here - Chunked Encoding should work fine for giving the size of
the data transfer, simply by buffering a handful of k. The startup time
would then be as it is now, and the whole thing fits into both standards as
of now. Obviously in the case of HTTP/1.0, there's no need to give any
indication of the download length, so there's no need to attempt to support
it.

Although again the use of chunked-encoding can result in added processing
burden 
in proxies.  Also any benefit from the potential use of Content-Length along
the way 
to the destination client is completely foiled, and avoiding it seems to
imply it 
has relatively little value to begin with, etc.... 

Putting in a MLST line in the response for a file being downloaded makes
sense to me, simply because it can be done with ease - and gives cues on
whether the proxy should consider this file for caching. This is a
performance advantage for the proxy, and the way MLST is designed, a minumum
hit on the server. 

If Squid, Apache and the others are actually issuing SIZE commands and
Content-Length headers, then it's my thinking that they're doing things the
wrong way in any case.

Perhaps but it might conceivably also be interpreted as acts of desperation
on the part of the authors (?) 
in lieu of a reliable standard to begin with. 

-----Original Message----- 
From: Stephen Tihor [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, June 06, 2000 4:39 AM 
To: FTPEXT Working Group 
Subject: Ftp-WG: thoughts on ftp extensions and caching 

Nope it would not. Seems to be letting the HTTP tail wag the host file 
system dog though.

Maybe though caching seems to be attracting considerable interest these
days. 

RFC 959 contains the following which also may be relevant to discussions: 

         A comment on transfer modes.  The stream transfer mode is 
         inherently unreliable, since one can not determine if the 
         connection closed prematurely or not.  The other transfer modes 
         (Block, Compressed) do not close the connection to indicate the 
         end of file.  They have enough FTP encoding that the data 
         connection can be parsed to determine the end of the file. 

It seems as if it would be nice to be able to clear this up one way or
another. 

-s

---

From: Stephen Head <[email-masked]>
Date: Tue, 6 Jun 2000 16:47:57 -0500

<<devil's advocate mode on>>

On using the response code to determine whether a file has been
successfully
retrieved, it certainly seems to imply that the server application
process
(assuming it is implemented as a process) considers all the data to have

been presented to its underlying TCP module without error.  It is
unclear
to me exactly why, if the contention is true, that the note still exists

in RFC 959; if it is a warning about a condition that can always be
avoided,
why include it (somewhat rhetorically)?  But if there is some valid
problem
(what?), then having exact size information up front would certainly
fix it as far as I can tell.  [Either way, it is possible that RFC 959
could
benefit at a minimum from some textual wordsmithing in this regard
if it is indeed a no-op in practice.]

[Certainly Content-Length can be useful for keepalive connections
but its use predated HTTP/1.1 which it is my understanding introduced
connection re-use for requests except for experimental versions
(I am looking at HTTP/1.0 RFC 1945, section 1.3).  Content-Length
is present (though not required yet) acc. to HTTP/1.0 RFC 1945 section
10.4.]

[I am relatively neutral on the merit of a Content-Approx-Length HTTP
header since I do not now perceive its value currently to be of
sufficient worth
that I would personally go out of my way to use it to any significant
degree
if I encountered it.  I am however noting it for further consideration
and my opinion might change in the future.]

Whether approximate size is "accurate enough" for cache servers
raises some concerns which I tried to illustrate in my previous message.

Stephen Tihor mentioned earlier that accuracy could vary by at least a
factor
of 2-4.  For implementation purposes one presumeably ought to be
concerned,
fortunately or otherwise, with worst cases in order to avoid problems.
I would
be hesitant to rely very much on a value which could be off by a factor
of 2-4 or more for anything I would want to try to implement that relied
on
an approximation of size.  An alternative is to try to cache everything
and
bail out when some policy criterion is exceeded on a per-transaction
basis;
however, it is often the case that such a policy incurs
price/performance
penalties for the caching server and the downstream clients it serves.
An accurate size up front would help to avoid such penalties.

Making the up front reporting of accurate size information
is, IMHO, of sufficient value such that the working group may
wish to consider ways to encourage reporting it by conforming
servers, since it seems (to me at least) of general benefit
to network health at large in minimizing net message overhead,
response latency, and so on.  Correspondingly, to the extent it is
made optional ("should") and to the extent that it is not reliably
available
for use downstream reduces the benefit (at times, probably
resulting in missed opportunities for optimizing overall net bandwidth).

[Upload considerations do not appear to be a caching concern so I leave
this
to others.]

<<devil's advocate mode off>>

Philosophically, if there is a network-transfer-related benefit
to be obtained by calculation of a static value, it would seem
advantageous to consider slanting the playing field in favor
of reporting that value for the benefit of the more
restrictive-constrained
systems involved in the dynamic transfer in contrast to requiring
those systems to compensate by added complexity, impaired
functionality, or both.  Were someone seriously/frequently using ftp for

some kind of tunneling of dynamically generated data (?) I would
be more reluctant to put forward such an argument.

-s

-----

Dave Cridland wrote:

> transfers these days, do not have any indication of whether a file has
> been successfully RETRieved, although the response code after the
> transfer will usually give it away.
> b) HTTP->FTP gateways are required to give some indication of when the
> file has been transferred, either in advance, by the Content-Length
> method, or inherently, using the Chunked Encoding method. These are
> required by HTTP/1.1 for keeping alive connections, as I understand
> things.
> require some file size indication in order to know whether to consider
> the file for caching or not. There is some speculation about whether
> the size here needs to be wholly accurate, or whether it can be
> approximate.
> 3) There is significant overhead, as discussed before on this list,
> for determining the transfer size (as given by the SIZE command) of a
> file. There is no significant overhead in giving an approximate size,
> as given by the "size" fact of MLS*.
>
> My suggestions:
> a) In the real world, I've experienced few problems with being unsure
> of whether the file has been transferred or not. In the absence of
> finding the transfer size, I find that the use of the response code
> afterwards seems to give a reliable indication with today's networks
> and technology.
> during commencement of a download. However, if I relied on it, I'd be
> using SIZE beforehand.
> So, FTP servers which support our currently non-existent extension
> should give a "transfer-size" fact in any MLS* line, including that
> given by responses to RETR, where this does not place a significant
> burden on the FTP server. This includes caching responses to previous
> requests for SIZE if this is possible and/or desirable.
> Note that this is only a solution for downloads, and not for uploads.
> The only way I can think of for uploads would be to suggest the use of
> the ALLO command prior to the upload, or else define another, similar,
> command for this use. This is a tad unfortunate, as I have a sneaky
> feeling that uploads in STREAM mode are by far the more problematic.
> transfer-size is not available, and Content-Length where it is. It
> fits the bill nicely, and is interoperable with all current FTP
> servers.
> HTTP->HTTP gateways chaining onto the back of the HTTP->FTP gateway
> may suffer some loss of meta-information, however. See below:
> c) Where the transfer-size is available form the FTP server, the
> HTTP->FTP gateway should use this.
> Where it isn't, the HTTP->FTP server should use the approximate size,
> where available, for policy decisions. This should be accurate enough
> in almost every case. Where there is no size information available,
> which includes current FTP servers, the method for policy decision
> making is undefined, however, HTTP->FTP gateway implementors should be
> aware that using STAT <file> on MLST capable FTP servers will be
> faster than SIZE <file> in some cases.
> Ideally, however, the HTTP->FTP gateway should avoid using multiple
> commands due to latency issues, and should instead attempt to either
> cache the information from previous MLSD requests, or make their
> decisions based on some other means.
> require this information for their own policy decisions, this
> "approximate size" meta-information, however derived, should be passed
> back in some as yet undefined HTTP header (Content-Approx-Length?).
>
> That's my thoughts for now, anyways. Feel free to rip them apart, but
> do bear in mind that while I realise there's a problem for HTTP->FTP
> gateways, I'm fairly sure it's really two seperate problems, and if
> the problems appear to be in the current, limited set of
> implementations, then its these which we should fix as a priority.
>
>

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Tue, 6 Jun 2000 17:31:57 -0500

> if it is indeed a no-op in practice.]

Jumping in in the middle ...

As I see it, determining if a up/down load was complete is fairly easy.

At end-of-file, the sender half-closes the data connection and waits for the
receiver to half-close the connection; this brings us to a "closed" state
(per TCP) which is required by 959.  Once the data connection is in a
"closed" state, the server sends the positive reply.
Upon receipt of the positive reply, the client may safely assume the
transfer was complete.

While this addresses the problem of determining if a transfer was complete,
it does not aid in pre-determining the byte-count.

My problem with pre-determining the exact byte-count comes when some
conversion or generation of data occurs during the data transfer.  The only
way, for instance, to accurately determine the exact size of an on-the-fly
tar'd and gzip'd downloaded directory would be to peform the entire
operation prior to beginning the data transfer.  This would add an
unacceptable delay to the beginning of a transfer, and place an unacceptable
load on the server host.

I could see a 'middle ground' ...

If the size of the data transfer can be exactly predicted, then that size
MUST be provided as a property and MUST appear in the positive intermediate
reply to the download.

If the size cannot be exactly predicted, then the size property MUST NOT be
present and MUST NOT be given in the intermediate reply.

I would say, given the wide error range which would be required, any
'approximation' would be a load of whew-y and should treated as such.

---

From: Stephen Head <[email-masked]>
Date: Tue, 6 Jun 2000 17:59:31 -0500

> As I see it, determining if a up/down load was complete is fairly easy.

Agreed, possibly with the following consideration.

> Upon receipt of the positive reply, the client may safely assume the

In theory,  it seems as if the TCP FIN sent by the server on the data channel
could be delayed in transmission relative to the positive reply sent by the
server
on the control channel.  The client can presume the file to be successfully
transmitted in total, therefore, if both conditions become true in either order

(or at least, so it would seem).  If so, the problem referred to in RFC 959
does not exist in practice (and if so becomes a candidate for wordsmithing
out).

[In what form will the eventual FTP extension reach the RFC stage?--
if rolling RFC959 in its entirety with a new RFC #, then this might be
opportune to address at that time.]

> present and MUST NOT be given in the intermediate reply.

I would only observe that the process of placing the file in the server NVS to
begin with, presuming accomplished via some form of file copy operation
native to the server OS, typically (?) involves writing the contents of the
file
to that server's secondary storage.  If so, keeping a cumulative count
of the number of valid (re-readable in image format) bytes written to the file
would appear to be relatively trivial (in theory at least) and invariant with
time
(ie it is always predictable).

Storing and later retrieving on demand such information concurrently with file
retrieval
is additional work but not necessarily involving a significant delay if done
intelligently.

> 'approximation' would be a load of whew-y and should treated as such.

No objection from here...

-s

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Tue, 6 Jun 2000 20:38:35 -0500

> opportune to address at that time.]

In practice, WU-FTPD 2.6.0 made the switch.  What we've found is a few
(actually, very few) clients which will lock up waiting for the reply before
closing the data channel.  The list is fairly short, most vendors made
updates when it was pointed out to them (if they'd not already run across
the problem .. seems some far-less-often used daemons were doing the same
thing).

We support backward compatability with a compile-time option.  From the
questions on the support mailing lists, while the subject is a FAQ (and
covered there), it seems the sites most in need of the backward
compatability are those in support of specific products where the client is
a legacy and having users upgrade is infeasable or impractical in the
short/middle term.  Sites where most users come in using graphical clients
such as IE and NS have no such problems and generate very few pleas for
help.

> is additional work but not necessarily involving a significant delay if
done

What I'm referring to is massive pre-processing such as tar/gzip like we do
in wu-ftpd's ftpconversions.  I can (and have) ftp'd multi-Gbyte directories
as a tar/gzip piped to the data channel.  If I needed to wait for the
tar/gzip to complete it could be several minutes and the server host would
be required to store the entire tar/gzip in temp storage (which I hope is
disk otherwise a sufficiently large archive will cause massive swapping on
the host).  Technically, it's possible.  As a practical matter, though, I
would never ask our users to live with such.

--

On the subject of rolling RFC 959 into a new RFC; I'd like to see that.
Heck, I'd like to see simply clarification and modernization of the language
in RFC 959.  I'm not sure, however, I'd like to see that begun until we've
sealed and shipped the MLST and HOST RFCs.  Let's not derail the work on
those with a massive new project, yet.

---

From: "Brad Clements" <[email-masked]>
Date: Wed, 7 Jun 2000 08:58:01 -0500

> during commencement of a download. However, if I relied on it, I'd be using

Uh, would it be possible to have a second intermediate response code 
sent after the transfer, reporting the number of octets transmitted?

This response would come before "transfer complete".

This way the server doesn't have to pre-calculate the size, yet can tell 
the client exactly how many bytes the file was.

> this use. This is a tad unfortunate, as I have a sneaky feeling that
> uploads in STREAM mode are by far the more problematic.

Same solution here, an intermediate response code from the server .. 
that says how many octets where received before saying "transfer 
complete".

Brad Clements,                [email-masked]   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               AOL-IM: BKClements

---

From: Stephen Tihor <[email-masked]>
Date: Wed, 7 Jun 2000 09:38:40 -0500

In terms of sending sizes this is a wonderful idea.  Would it be an
incompatible change in the state transitions that would break clients?

---

From: "Brad Clements" <[email-masked]>
Date: Wed, 7 Jun 2000 09:51:09 -0500

> incompatible change in the state transitions that would break clients?

Oh, yeah.. existing clients.. 

What if the 226 "transfer complete" was "standardized" in some way?

An ugly idea:   226 transfer complete, sent: 8363343 octets

I don't like this idea, but it would be compatible with old clients and not 
involve a state machine change.

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Wed, 7 Jun 2000 10:48:42 -0500

> the client exactly how many bytes the file was.

Adding an intermediate response could break a vast number of clients.

If the desire is for a proxy to have the information required to make a
policy decision prior to the data transfer, the information should be
available prior to sending the data transfer command.  For RETR-type, the
MLST facts, and possibly the SIZE command, should be sufficient for this
purpose.  For STOR-type, there would need to be some means to communicate
the expected size to the remote server; the ALLO command comes to mind here.

If the desire is for a client to be able to determine whether a specific
upload/download is complete; proper use of TCP and sequencing of the
data-channel activity with the command-channel replies is sufficient.

So, the question becomes simply: should there be a standardized format for
the intermediate and final reply?

Let's examine what's done now (using a command-line client and WU-FTPD).
Here's a sample session:

    $ ftp ftp.vr.net
    Connected to www.vr.net.
    220 ftp.vr.net FTP server ready.
    Name (ftp.vr.net:lundberg): anonymous
    331 Guest login ok, send your complete e-mail address as password.
    Password:
    230 Guest login ok, access restrictions apply.
    Remote system type is UNIX.
    Using binary mode to transfer files.
    ftp> ls /pub/pgp-keys/[email-masked]
    200 PORT command successful.
    150 Opening ASCII mode data connection for /bin/ls.
    -r--r--r--   1 lundberg vrnet         712 Jul  9  1999
/pub/pgp-keys/[email-masked]
    226 Transfer complete.
    ftp> bin
    200 Type set to I.
    ftp> size /pub/pgp-keys/[email-masked]
    213 712
    ftp> asc
    200 Type set to A.
    ftp> size /pub/pgp-keys/[email-masked]
    213 727

It appears, at least for WU-FTPD, the size command already provides the
necessary information to make a policy decision for this file.

    ftp> size /pub/pgp-keys/[email-masked]
    550 /pub/pgp-keys/[email-masked]: No such file or directory.

Although WU-FTPD does not go to the work of running any complex conversions
on the file simply to support the SIZE command.  Ah well.  For a
cache/no-cache decision, at least, there appears to be enough information
already available.

    ftp> bin
    200 Type set to I.
    ftp> get /pub/pgp-keys/[email-masked] aaaa
    local: aaaa remote: /pub/pgp-keys/[email-masked]
    200 PORT command successful.
    150 Opening BINARY mode data connection for
/pub/pgp-keys/[email-masked] (712 bytes).

On this reply we see, among other things, the exact size.  Should this be
formalized?  Why not.  While the original intention of the FTP was that the
numeric codes be sufficient for the client, by formalizing the information
on the 150 reply we enable (or ease) automata.

The minimum requirement should remain the numeric replies; the server MAY
send additional information in some predetermined format; the client MUST be
able to handle a 150 reply with non-formatted textual information and even
MUST be able to handle a "150 " reply with no textual information at all.

    226 Transfer complete.
    712 bytes received in 0.00109 secs (6.4e+02 Kbytes/sec)

Here my client has helpfully displayed the number of bytes transferred.  As
a human, I can easily compare this to the size given on the 150 reply to see
the transfer was complete.  Using a formatted reply enables additional
cross-checks, which is probably a Good Thing (even if not strictly
required).  The server MAY send the size information again; the client MUST
NOT depend upon the server actually doing so.

    ftp> get /pub/pgp-keys/[email-masked] bbbb
    local: bbbb remote: /pub/pgp-keys/[email-masked]
    200 PORT command successful.
    150 Opening ASCII mode data connection for /pub/pgp-keys/[email-masked]
(712 bytes).

Now we see that the WU-FTPD is giving an incorrect fact (which I guess I
should note as a bug :).  We know from the SIZE command earlier, the daemon
_could_ determine the correct value.  But that might mean doing what we did
for the SIZE command; processing the entire file to determine the size and
discarding the resulting data stream.  Since we're about to transmit the
file, pre-processing just to send an accurate size seems a waste of time and
resources.  If the server does not already have the size information
available (ie., by stat'ing the file) or the information can be expected to
be incorrect, I would say it MUST NOT send that information in the initial,
intermediate reply.

    226 Transfer complete.
    727 bytes received in 0.00515 secs (1.4e+02 Kbytes/sec)

Again, my client knows how many bytes (octets) were received.  But as a
human I am confused; the numbers do not match.  At this point, the server
SHOULD send the actual number of bytes (octets) transmitted.

Now here's an issue: how should it be worded?  I'd like to see the server
only sending the size information once.  But sometimes that information is
available prior to the transfer, sometimes not until after.  If sent before
the transfer the client (proxy?) can use the information to make policy
decisions (cache/no-cache).  But it's

    ftp> quot allo 727
    202 ALLO command ignored.

Sigh.  Well, this isn't really what ALLO was intended for.  I suppose
WU-FTPD _could_ do a filesystem space availability check.  But that would be
very hard to do inside a chroot'd environment.  The best way to check would
be to actually try creating a file of the desired size, but we don't know
where to create the file and even if we did I'd think long and hard about
the DoS possibilities.

    ftp> bin
    200 Type set to I.
    ftp> put aaaa /incoming/aaaa
    local: aaaa remote: /incoming/aaaa
    200 PORT command successful.
    150 Opening BINARY mode data connection for /incoming/aaaa.
    226 Transfer complete.
    712 bytes sent in 0.000797 secs (8.7e+02 Kbytes/sec)
    ftp> asc
    200 Type set to A.
    ftp> put bbbb /incoming/bbbb
    local: bbbb remote: /incoming/bbbb
    200 PORT command successful.
    150 Opening ASCII mode data connection for /incoming/bbbb.
    226 Transfer complete.
    727 bytes sent in 0.000873 secs (8.1e+02 Kbytes/sec)

Obviously the server has no size information.  But it probably SHOULD give a
read-back of the bytes received.

    ftp> quit
    221 Goodbye.

As to Alun's comments about changing the accepted textual reply ...

If the existing definition is "unspecified", and if the new specification is
no stronger than SHOULD on the server, and the client MUST be able to handle
the case of "unspecified" or even missing textual information, I don't see a
problem.

The RFC gives example relies for those which are "unspecified".  I see those
as no more than recommendations.  Also, a client which depended upon the
recommended replies would have problems handling a server which was using
non-English text in replies.

The best method, if we don't want to change the final reply, is to use
extended replies, such as:

226-727 bytes received
226 Transfer complete.

---

From: Alun Jones <[email-masked]>
Date: Wed, 7 Jun 2000 12:03:22 -0500

>the case of "unspecified" or even missing textual information, I don't see a

I think you misunderstand me.  You seem to be merging my two points into 
one.  Since I already stated that they were largely contradictory (perhaps 
"complementary", or "orthogonal" would have been better), this isn't 
appropriate.

Again, the first argument is that numerical responses should be sufficient 
for most operations; by adding requirements on the text presented, we will 
be preventing a server from supplying the data that it previously chose to 
provide (for whatever custom purpose).  The server will have to choose 
between remaining usable in its current configuration, or breaking that 
functionality to support a new RFC.

The second argument is that there is _already_ a de-facto standard for the 
150 response, that is used by many graphical FTP clients to create a 
progress bar.  To change from this standard to a new one would again cause 
servers to make the choice between supporting old standards or new 
ones.  Presumably the clients would catch up eventually to the new 
standards, but in the meantime, functionality that I presume users consider 
valuable would be lost.

>non-English text in replies.

The clients do not depend on the response, but they use the byte count if 
it is there.

>extended replies, such as:

Any client that couldn't handle a change to "226 Transfer complete (727 
bytes)." would be seriously broken.  I see no objections to including a 
byte count in the termination response [though remember that a QUIT and 
close of the command/response stream does _not_ disconnect a transfer 
associated with that connection - an FTP client that disconnects before the 
transfer is complete, of course, pretty much deserves not to know whether 
it got all the data].

To clarify, my objection is with requiring a change to the 150 text, as it 
would require the generation of information that is often complex to 
generate (the size fact isn't necessarily the only slow fact to generate), 
and it would break an existing, commonly-used, albeit de-facto, standard 
format of response.  I have no objection to adding a byte count to the 226 
response, since there is no existing functionality to break (AFAIK), and 
the information is no harder to generate than to simply hold a count of 
bytes accepted by the send() function.

If the client wants to know the MLST facts when retrieving a file, why not 
simply call MLST prior to retrieving the file?

Alun.
~~~~

--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us
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.

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Wed, 7 Jun 2000 12:33:37 -0500

> "complementary", or "orthogonal" would have been better), this isn't

I like "contradictory" .. fits more with what I think when reading 959.

> bytes accepted by the send() function.

I agree with all of this, and your point about changing the 150 intermediate
reply is well taken.