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

["Mark P. Peterson" <[e-mail]>]

Hi Ángel,

RMDA
-------
> 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.

I will add this to the document.

THMB
-------
>  It should allow full MIME types, so an application/x-better-image-format could be used.

I cannot find a reason to disagree, so I agree that following a standard for
identifying the thumbnail type should be used.  I could use your help here
clarifying my document.

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

I prefer specifying the parameters in the command for two primary reasons.

1) By requiring a client to use OPTS to specify output type and resolution
the client and server must exchange this information in a separate command.
Commands require a handshake and consequently some latency between the
server and client for the exchange.  Depending on many different factors this
latency, even on a fast connection, can be noticeable.  If the client wants different
sized images frequently, let's say for every thumbnail image, it would be
even more noticeable.  The bandwidth required to specify 10 bytes or less as a
parameter to the command is trivial by comparison even on the slowest
connections.

2) By requiring a client to use OPTS to identify the parameters, both the client
and the server must maintain the parameters for this command, more-or-less
as a state.  I'm a big fan of keeping things very simple.

3) End-user support is easier when parameters are specified with the command.
When end-users or customers have problems they'll often provide a portion of a
log to identify what is going on with the communication between the server and
client.  Technicians analyzing the log may not have all of the required information
regarding the THMB command.  With the parameters being issued with the
command analysis is far simpler and accurate.

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

Could you give me some examples or how you would like to see this worded
and where you would like to see this placed in the document?

Mark P. Peterson - President
http://www.RhinoSoft.com
Voice: [phone]
FAX: [phone]


--------------------------------------------------
From: "Ángel González" <[e-mail]>
Sent: Tuesday, November 23, 2010 5:54 PM
To: <[e-mail]>
Cc: "Robert McMurray" <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions

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.