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

[Mat Berchtold <[e-mail]>]

Hello Mark ..

>CSID after login
I also think the CSID command should only be available after login. I cannot think of a good reason where a  client with good intentions would need it before. But maybe I'm missing something here?

>Facts
For the facts, I would propose the following facts which would replace the existing Name and Version facts:
VendorName
ProductName
ProductVersion
Where ProductVersion must be in the following format 1*DIGIT "." 1*DIGIT "." 1*DIGIT* "." 1*DIGIT which represents the version as following: major.minor.build.patch

An example:
VendorName: SmartSoft Ltd.
ProductName: SmartFTP
ProductVersion: 4.0.1145.0

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

Regards,
Mat


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of William F. Maton
Sent: Tuesday, 23 November, 2010 14:55
To: Mark P. Peterson
Cc: [e-mail]
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions

On Tue, 23 Nov 2010, Mark P. Peterson wrote:

> Hi All,
>
> Is there anyone else that agrees with Damin about CSID?  He says it SHOULD be available only after login.

Hi Mark,
        I'm certainly and old enough salt at systems administration to think that identification before authentication or authorization is not a good thing.  It makes it easier for the scanners to pick-off what servers are running.  I'd like to force them into making the extra effort, since it might as well cost them more work and I can monitor the activity better.

        I think standardizing CSID (from the old non-standard CLNT) is a good thing though.  It should be left up to the implementor to support it.

        I've also read he rest of that I-D and have more thoughts on it, but that's for another email.


> Mark P. Peterson - President
> http://www.RhinoSoft.com
> Voice: [phone]
> FAX: [phone]
>
>
>
> From: Damin
> Sent: Monday, November 22, 2010 10:17 PM
> To: [e-mail]
> Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions
>
>
> 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
>
>
>
>
>
>
> _______________________________________________
> ftpext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ftpext
>
>
> _______________________________________________
> ftpext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ftpext
>

wfms