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

[" Ángel González " <[e-mail]>]

Hello all,

Robert McMurray wrote:
> 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.

I don't think a server should do that or be encouraged to. If a server
rejects a RMDA the client SHOULD fall back to a recursive listing and
removing.
As currently defined, on receiving a RMDA the server MUST delete
everything in the subpath the user is allowed to. I think that changing
it to also allow a not remove anything would solve the issue.
If the folder being RMDAed is not deletable by the logged in user, the
server MAY -based both on its configuration and user credentials-
directly reject the command. On the other hand, if it deletes one file
(and can not rollback the operation), it must continue the whole subtree.


About THMB:
The format is restricted to registered image subtypes. It should allow
full MIME types, so an application/x-better-image-format could be used.
And giving that step, always using the full mime for images would seem
more clear.

I also prefer the OPTS syntax, since that would allow larger options and
extensions, such as:

  C> OPTS THMB image/png 60 60 page=2
  S> 200 OPTS THMB PNG command successful.

  C> THMB document.doc
  S> 150 PNG Starting thumbnail transfer
  S> 226 Transfer complete.

for requesting a thumbnail for the second page of the document.

Since the OPTS would be given once at the beginning and then used for many files, it's also important for reducing its continuous repetition.


Robert McMurray wrote:
> 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.
Note that the server can compute it the first time, then cache the
thumbnails you have requested on previous sessions. Moreover, it could
get heuristics as 'Start prethumbnailing with the current options if it
has requested in order the thumbnails of the first three files in the
folder'.


There should be a note about the potential security issues of the THMB
command. Vulnerabilities processing images are common.



Mat Berchtold wrote:
> Server/Client fact requirement
> The draft proposes that the client must provide the name and version fact where for the server these facts are optional. For equality both parties involved should have equal requirements/rights. My proposal is that all facts are optional. The reasoning is that there is no need for the client to expose its name or version if it only wants to figure out the case sensitivity of the server file system.
Sad as it is, it may be useful for implementing client-specific
workarounds in the server.