[ftpext] draft-peterson-streamlined-ftp-command-extensions

[Robert McMurray <[e-mail]>]

[Note: Renaming the thread from 'Submitting new drafts'.]

> Anthony Bryan wrote:
> 
> I don't mean to single you out, but
> you showed interest in an CSID/AGNT
> command. Do you have any opinion on
> the other 4 commands in the draft?

Thanks, Anthony.

No worries - I meant to send a better response in the wake of my withdrawn AGNT draft and Mark's current Streamlined FTP Command Extensions draft, but I had been remiss at taking the time to collect my thoughts in a more meaningful way. But since you asked, this seems like as good at time as any. ;-]

CSID - As evidenced by my short-lived AGNT proposal, I think it's very useful to have some sort of client/server discovery command. FEAT does a good job of advertising the list of commands that are supported by a server, but Mark's proposed CSID command sequence provides a much better way for servers and client to identify their features to each other in detail. For security reasons I would probably want the CSID exchange to occur AFTER the client has logged in, but I might be overreacting.

RMDA - This could be a very useful command, and it would parallel the functionality that I'm sure we all typically use in a native operating system environment. In a server implementation I would probably make this command configurable, so administrators would have an option to disable the feature. In which case I would probably hide the command from a FEAT response so it would not be discoverable and have the server return a 500 or 502 reply when RMDA is sent by the client and disabled at the server.

(Note: I mention my thoughts about server implementation details just to open up the discussion as to whether any implementation details should be called out in the draft, or if we should leave that up to the implementers to decide.)

AVBL - This command could be very useful in a client/server world; our FTP server implementation currently returns the available size after a successful login sequence, and the available size is based on server disk quotas and such. That being said, not every FTP client will bubble that information up to the user interface. Having an AVBL command would make it possible for a client to determine whether enough storage space is available at the server BEFORE sending a file, which would be great when you're about to send a 10GB file and you only have 9.99GB of storage space left. ;-]
 
DSIZ - This could certainly be useful, although I would probably want a user to be logged in (not anonymous) before I supported this command in order to reduce the risk of denial-of-service. I'd probably make it configurable so as not to tie up too many server resources for large directory structures; and once again, if the feature were disabled I would probably hide the command from a FEAT response so it would not be discoverable and return a 500 or 502 reply when DSIZ is sent by the client and disabled at the server.

THMB - I have to admit, I don't work on a graphical FTP client, so this command is less useful to me personally, but I can see the merit that it might have to someone that designs a graphical client. That being said, I'm not a big fan of computing the thumbnail dynamically, nor am I fond of allowing the client to specify the thumbnail format and size. I think that it would be better if the server could pre-cache thumbnails for any file type in a server-determined size and image format, and then return the binary data and image format information to the client. For example, most graphically-based operating systems have some method for displaying file icons to a user that is seated at a computer terminal, so an FTP server implementation could simply return that same icon to a client in response to a THMB request.

Please bear in mind, I haven't given a lot of thought as to what the client/server interchange might look like if the server were more in control of the response to a THMB request, but it would probably be sufficient to simply return the image type as part of the response and let the client determine the image dimensions based on the client's capabilities for reading the image data. (As a server guy I like to push any client-friendly processing on the client whenever possible. ;-]) You could borrow an idea from the HASH discussion that we've been having and make the thumbnail image type configurable for the client by using an OPTS command, which might look like the following examples.

In this first example, the server has a pre-configured thumbnail image type of JPG, and may have pre-cached the thumbnails for files; any THMB request with no OPTS specified would use the server's pre-configured thumbnail image type of JPG and image type is specified in the command channel response:

  C> THMB widget.png
  S> 150 JPG Starting thumbnail transfer (1234 Bytes) for widget.png
  S> 226 Transfer complete.

In these next examples a client is asking for different thumbnail image types by using OPTS commands, and the thumbnail image types would still be specified in the command channel responses:

  C> OPTS THMB GIF
  S> 200 OPTS THMB GIF command successful.

  C> THMB widget.psp
  S> 150 GIF Starting thumbnail transfer (1234 Bytes) for widget.psp
  S> 226 Transfer complete.

  C> OPTS THMB PNG
  S> 200 OPTS THMB PNG command successful.

  C> THMB widget.doc
  S> 150 PNG Starting thumbnail transfer (1234 Bytes) for widget.doc
  S> 226 Transfer complete.

In this next example a client is asking for an unsupported image type, so the server would simply return the appropriate error reply:

  C> OPTS THMB FOO
  S> 501 Unsupported thumbnail format.

In this next example a client is asking for the currently-configured thumbnail image type, so the server would return the appropriate response:

  C> OPTS THMB
  S> 200 JPG

You might take this one step further - the server might choose to only support its pre-configured thumbnail image type, thereby allowing pre-caching of all thumbnails in one specific image format. In this example a client is asking for PNG thumbnails, which SHOULD be a supported image type, but the server only supports a pre-configured thumbnail image type for JPG files and returns the appropriate error reply (504?) and the server's pre-configured thumbnail image type is specified in the subsequent command channel response to a THMB request:

  C> OPTS THMB PNG
  S> 504 Specifying thumbnail formats is unsupported.

  C> THMB widget.xls
  S> 150 JPG Starting thumbnail transfer (1234 Bytes) for widget.xls
  S> 226 Transfer complete.

As I said earlier, I hadn't given much thought as to what the client/server THMB interchange might look like if you put the server in control instead of the client, but as a server guy I'd rather see THMB look a little more like the examples that I gave. ;-]

Thanks again!

Robert McMurray
[e-mail]