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

From: Stephen Head <[email-masked]>
Date: Fri, 2 Jun 2000 18:36:32 -0500

How about:

The control channel responses for RETR are a 125 response
(non STREAM mode) and a 150 response (STREAM mode).

An extended 125 response consists of:

        "125-Ext" CRLF
         1*( SP entry CRLF )
         "125 End" CRLF

An extended 150 response consists of:

        "150-Ext" CRLF
         1*( SP entry CRLF )
         "150 End" CRLF

where:

        entry            = [ facts ] SP pathname
        facts            = 1*( fact ";" )
        fact             = factname "=" value
        factname         = "Binary-Size" / "Size" / "Modify" / "Create"
/
                           "Type" / "Unique" / "Perm" /
                           "Lang" / "Media-Type" / "CharSet" /
                           os-depend-fact / local-fact
        os-depend-fact   = <IANA assigned OS name> "." token
        local-fact       = "X." token
        value            = *RCHAR

and where pathname is the fully qualified pathname of the object*
and facts MUST include the following factname-value pairs**
if FEAT returns "X150" or "X125":

        Binary-Size
        Modify

Note that a caching proxy server has the option of fetching
the binary version of the file, even if it is ASCII that is being
requested by the client.  This makes reporting the Size
(in contrast to Binary-Size, which would be the binary size
of the file only) appear to be somewhat less critical.

-s

* permits managing file object cache using fully qualified pathname,
presumed to be unique (even in presence of symbolic links on
the server).

** presumeably the states of the other stuff is explicitly managed
by the client and so not needed.  I haven't exhaustively checked
that this is the case (eg for 3-party transfers, etc.).

-----

Dave Cridland wrote:

>
>
> Before I commence wittering, a caveat: It's before noon here, and I'm
> hungover, and can't remember everything in the MLST spec, and
> unfortunately I'm at work and somewhat busy.
>
> However, I suggest the following:
>
> In responses to RETR commands, the Server-PI SHOULD respond with the
> following as the text of the response:
>
> response = identifier SP mlst-line
>
> identifier = "<EXT>" (or some such - more than a character should
> avoid confusion)
>
> And also include the extra facts, not normally put in:
>
> "download-mode", "download-type", "download-structure" - defining the
> method of downloading. Assuming I've remembered these right.
>
> The "size" fact, if present, should indicate to a reasonable degree
> the size of the file being downloaded - perhaps not wholly accurately
> for ASCII mode downloads, but enough for policy based caching systems
> to take a view on whether to cache or not.
>
> Perhaps include an optional "download-size" fact for the exact size.