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

[Damin <[e-mail]>]

Hi,

On 22 November 2010 19:32, Mark P. Peterson <[e-mail]> wrote:

> Hi Robert,
>
> Thank you for taking the time to review the commands.  If you don't mind I
> would
> like to respond to your comments:
>
> CSID:
> > For security reasons I would probably want the CSID exchange to occur
> AFTER the client has logged in, but I might be overreacting.
>
> There is a lot of discussion on the Internet about servers providing "too"
> much information, especially prior to login.  But having
> worked on both sides of the FTP process, it's usually very easy for the
> client to identify what brand or flavor the server is.
> There are details which usually identify the server such as the
> completeness of the FEAT response, the welcome message, responses to
> certain messages, etc.  So, I think it's okay to be available prior to
> login.  I could change the document to read that it should be
> up to the server's implementation whether or not it's available.
>
I prefer to edge on the side of caution. I don´t see any good reason that
this SHOULD be available before login. Commands available prior to login
should be as limited as possible.

>
> RMDA:
> > 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 my document specifies that it isn't configurable.  My
> implementation in Serv-U is configurable as is almost all other
> FTP commands.  I think this can be left up to the server implementation.
>  Your possible implementation is exactly how Serv-U
> implements it.  If the feature is disabled, it doesn't appear in the FEAT
> response, nor is it available through the HELP command.
>
>
AVBL:
> > ...
>
> Your comments address the reason for its existence.  The client-side
> implementation in SmartFTP uses the command in this manner.
>
> DSIZ:
> > This could certainly be useful, although I would probably want a user to
> be logged in...
>
> Any information about paths or files requires login in FTP.  I am sure this
> is the case here as well.  If a server wouldn't want the
> "anonymous" user to have access to this command it could be configured to
> disallow this command at the server's implementation or
> configuration.  This should be left up to the implementation of the server
> or administrator of the server.
>
> > I'd probably make it configurable so as not to tie up too many server
> resources for large directory structures;...
>
> Agreed, the time-consuming nature of the implementation is discussed but
> configuration by an administrator or server-implementation
> is not.   Do you think such verbiage is required?
>

> THMB:
> > 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.
>
> That's the point of the command, though.  It's to reduce the amount of data
> that is required to travel over the wire.  The idea is
> to shorten delivery time to the client, letting the client decide what is
> best for the client, not the server.  Some clients may
> want very small images, say for a Windows Explorer style listing, others
> may want larger images (640x480 for example) to show a
> slide show.  I think the client needs to make that determination.  If the
> server decides to cache these generated images it can.
>
> > 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.
>
> This could waste server-side resources, the client might not even make a
> request for thumbnail images.
>
> > 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.
>
> Right, but this isn't really the purpose of this command.  The purpose is
> to take an original image file and reduce it to a
> specified size, not to return the OS's icon representation for that
> particular file type (i.e., not SHGetFileInfo() in Windows).
>
> My proposed implementation is fairly straightforward.  If supported the
> FEAT command replies with THMB and the supported file types.
> When the client wants a thumbnail it asks for it with a single command.
>  Here is a sample result from FTP Voyager and Serv-U:
>
> PORT 192,168,0,30,199,53
> 200 PORT command successful.
> THMB PNG 98 88 Thomas.JPG
> 150 Opening thumbnail image transfer BINARY mode data connection (19738
> Bytes) for Thomas.JPG.
> 226 Transfer complete. 19,738 bytes (19,756 compressed to 100.09%)
> transferred. 19.29 actual KB/sec,  19.28 effective KB/sec.
>
> The client opens a data channel just like any other file transfer, then
> requests the file using THMB, followed by the output type,
> width, height, and the file name.  The server responds just like a file
> transfer but also includes the resulting size in
> parentheses.
>
> While designing this command the idea was to first make it simple for both
> sides, second to make it operate as any other download,
> and third to make it as flexible as possible, allowing the client to decide
> how the resulting data is to be used and what is needed.
> Of course the server could be configured in any way needed.  For example if
> the server wanted to limit the size of the thumbnails,
> the server could do that.  Our implementation limits the number of
> simultaneous threads allowed to create the thumbnails at any
> given time.  I think these details need to be left to the server
> implementation.
>
> As for using an OPT command to configure an upcoming THMB command for its
> image type and the thumbnail size, that seems to
> complicate the command.  It's very easy to add these parameters into a
> single command, eliminating the required handshaking between
> the client and server.  An added benefit is that neither the client nor the
> server are required to maintain these "options"
> throughout a session, rather all of the information required is sent in a
> single command.
>
> If you're interested in seeing it in action, download Serv-U and FTP
> Voyager or SmartFTP.  Login to the server, switch FTP Voyager
> to "Thumbnails" view.  With SmartFTP simply select an image file and a
> thumbnail image, of dynamic size, will appear in the preview
> pane.
>

> Thank you again for taking the time to provide your feedback.  I look
> forward to your comments to the above.
>
> Mark P. Peterson - President
> http://www.RhinoSoft.com
> Voice: [phone]
> FAX: [phone]
>
>
> --------------------------------------------------
> From: "Robert McMurray" <[e-mail]>
> Sent: Monday, November 22, 2010 5:01 PM
> To: <[e-mail]>; "'Anthony Bryan'" <[e-mail]>; <
> [e-mail]>
> Subject: [ftpext] draft-peterson-streamlined-ftp-command-extensions
>
> [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]
>
> _______________________________________________
> ftpext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ftpext
>
>
> _______________________________________________
> ftpext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ftpext
>