Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10

From: Dave Cridland <[email-masked]>
Date: Tue, 13 Jun 2000 07:45:38 -0500

Well, what I was suggesting is that for the UNIX/ASCII case, no files would
appear with this fact (but clients would get something with SIZE), but for
the UNIX/Binary case, all of them would.

-----Original Message-----
From: Alun Jones [mailto:[email-masked]]
Sent: Tuesday, June 13, 2000 12:11 PM
To: FTPEXT Working Group
Subject: Ftp-WG: Re: minor example error in draft-ietf-ftpext-mlst-10

At 05:22 AM 6/13/2000, you wrote:
>If we're (sorry, you're) going over the draft again, is it worthwhile 
>adding a 'transfer-size' or similar fact, which defines the number of 
>octets of the file which would be transmitted using the current mode, 
>type, etc?
>
>With an additional note specifying that the Server-PI may choose not to 
>present this for certain files under certain download parameters, on the 
>basis that this may present a significant cost to the server? (Should the 
>Client really want to know, it can try using SIZE, which may have a higher 
>cost threshold.)

I believe the last time something like this was suggested, it was shot down 
as something that would considerably slow down MLSx responses.  If you're 
in ASCII mode, for instance, you'd have to open _every_ file that was being 
listed, read _every_ byte in every file, and add up the number of 
line-feeds to add to the size of the stored file.

In this case, should the client actually require this information, you're 
right, SIZE is the way to go.  SIZE is documented as producing this data.

The facts for MLSx should be kept to those that can reasonably be provided 
in a directory listing, without unreasonably delaying that listing - if for 
no other reason than that authors are going to be tempted to run FEAT, 
choose _all_ the MLST OPTS they can, and set them on prior to listing - 
after all, more information is _always_ good, right? :-)

Particularly with options for MLSx being switched on and off by a separate 
command, I'd say that adding such a weighty fact to the list would be 
overburdening a server.

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: Robert Elz <[email-masked]>
Date: Tue, 13 Jun 2000 08:22:12 -0500

Date:        Tue, 13 Jun 2000 07:45:38 -0500
    From:        Dave Cridland <[email-masked]>
    Message-ID:  <[email-masked]>

  | Well, what I was suggesting is that for the UNIX/ASCII case, no files would
  | appear with this fact (but clients would get something with SIZE), but for
  | the UNIX/Binary case, all of them would.

For the unix/binary case, size and transfer_size are going to be the
same thing in any rational implementation.  That's likely true in almost
any implementation - if transfer_size is trivial to compute, its value
will be used for the size fact, otherwise transfer_size would be omitted.
If there really any gain there?

Aside from restart (which is what the SIZE command was invented for)
I have yet to see a plausible excuse for knowing the exact transfer size
of a file ... being able to stick in wacky HTTP headers by http->ftp gateway
type things (why do they exist anyway, browsers do ftp?) seems to me to be
no rationale at all.

That the size fact is an "approximate" size is something that would allow
for a bunch of vagueness for sure, but that's really a quality of
implementation issue - ftp servers that don't get the size fairly close
most of the time (enough for deciding whether a file is too big, or too small
to cache, or to use for progress bars) aren't going to be very popular I
would have thought.

kre