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

From: Dave Cridland <[email-masked]>
Date: Wed, 7 Jun 2000 10:43:07 -0500

If I were to write an FTP server which supported dynamic archiving, then I'd
probably put it in the directory listings purely to allow downloads by GUI
clients with more ease. After all, it's in my interests, because it saves me
(hypothetical) bandwidth.

When I read through the MLST draft trying to see whether I was allowed to
drop a fact when the client had requested it, I couldn't find anything about
it, either way, which suggested to me in my pedantically crippled way that
it wasn't allowed - or at least, that it probably shouldn't be done from a
server PoV, but should be allowed for in a client context. It may well be
just me, though, I don't know if anyone else reads it that way. Of course, I
might have missed the critical phrase while skimming through it, at which
point I apologise profusely for my stupidity. :-)

Standardising the responses from RETR is surely fine if it only becomes
active with a OPT setting? Or not?

Having said that, Alun Jones makes very good sense indeed in his point (2).
Perhaps all that is needed is a mention of this de-facto standard in more
detail. If so, all the better.

I do still like the concept of the transfer-size fact being defined, though.

-----Original Message-----
From: Robert Elz [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 1:50 PM
To: FTPEXT Working Group
Subject: Ftp-WG: thoughts on ftp extensions and caching

    Date:        Wed, 7 Jun 2000 06:14:02 -0500
    From:        Dave Cridland <[email-masked]>
    Message-ID:
<[email-masked]>

  | Which
  | in itself may cause a problem with the MLST draft - if a fact cannot be
  | found for only some files in a listing, then does the MLST draft allow
us to
  | drop the fact for just those files? Reading the draft, it appears not
to.

That certainly wasn't the intent.   Any fact is supposed to be able to
be dropped when it cannot be supplied, or makes no sense.

In practice, dynamic archive type things tend not to appear in directory
listings anyway, as they don't really exist - the "RETR dir.tar.gz"
hack is truly that - using the ".tar.gz" part of the filename as a
set of options to the command to indicate to the server what it is
supposed to do with the entity requested (which is just "dir" in this
example).   It's totally legal FTP, but also horribly ugly.

kre

ps: is there no-one else but me here who believes that attempting to
standardise (in any form) the responses from RETR is just a little too
far from rational after all this time to even be discussing, however
benefitial it might be in some contexts?