Re: [ftpext] Posted Update to "draft-peterson-streamlined-ftp-command-extensions"

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

Hi Anthony,

I submitted a new revision which I believe addresses your comments below.
It appears I still have some "idnets" issues even though I attempted to make
the corrections you mention below.  Thank you for your assistance with this
draft.

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


--------------------------------------------------
From: "Anthony Bryan" <[e-mail]>
Sent: Saturday, September 18, 2010 3:13 AM
To: "Mark P. Peterson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: [ftpext] Posted Update to "draft-peterson-streamlined-ftp-command-extensions"

idnits gives you some issues to work on (keep in mind, you don't need
to submit new versions as soon as you make changes, you can wait until
a small amount of changes pile up):

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-peterson-streamlined-ftp-command-extensions-09.txt

  == Unrecognized Status in 'Intended status: Streamlined FTP Command
     Extensions  September 17, 2010', assuming Proposed Standard

     (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard',
     'Proposed Standard', 'Best Current Practice', 'Informational',
     'Experimental', 'Informational', 'Historic'.)

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.) -- however,
     there's a paragraph with a matching beginning. Boilerplate error?


  == Unused Reference: 'RFC1035' is defined on line 818, but no explicit
     reference was found in the text

some other issues...

1) I also think RFC 5797 is an informative ref rather than normative.

2) what does this mean?

   The 213 reply is formatted in such a way that the returned size value
   can be machine parsed.

from the example

         C> DSIZ A
         S> 213 123456

it looks like a straight up integer w/ no commas or other characters
delimiting it.

3) would it be useful to have more exact error responses like we are
talking about for HASH? (same for section 4.2).

3.2. DSIZ Error Responses


   In the event that the pathname is not a directory, the server MUST
   return a permanent 550 error reply.  Where the command cannot be
   parsed, a 500 or 501 reply SHOULD be sent.  The client MUST NOT
   assume that the presence of a 550 reply indicates that it cannot
   access the directory or its contents.  The server may generate this
   error for other reasons, for example the overhead required for the
   operation is too great.

4a) I have questions for each sentence of the AVBL intro:


4. Available Octets (AVBL)

   The FTP command AVAILABLE OCTETS (AVBL) can be used to retrieve the
   number of octets available to receive uploads in a specified remote
   directory.

to the currently logged in user? on a drive as a whole?

4b)

   Many server-FTP processes have implemented proprietary
   methods for restricting the amount of space available, either to the
   user as a whole or within a specified remote location.

I don't understand. does AVBL restrict the amount of space available
(above sentence) or show how much space is available (first sentence)?

4c)

   The AVBL
   command offers an interface for retrieving this value in a way that
   can be machine parsed.

also mentioned a few lines later in 4.1 (I think once in 4.1 is enough):

   The 213 reply is formatted in such a way that the returned size can
   be machine parsed.

5) see 4a. don't you want some consistency here?

   A successful response includes a numeric value that may be the number
   of octets available as dictated by the physical limitations of the
   underlying storage mechanism.  It may also be a limit imposed upon
   <pathname> or even the user that issued the command.  The exact
   method for calculating this numeric value is up to the specific
   server-FTP process implementation.

6) THMB FEAT response is in 5.3

   Image formats supported by the server are listed in the THMB FEAT
Response [6.3].

7) for this sentence, I think you should mention media subtype name
like you do later.

Its value corresponds to the commonly accepted file extension
   used for the requested image format.

8) you might want to mention this earlier:

5.4. THMB Examples

   Assuming the existence of image file "widget.png" on the server and
   that the client has all necessary permissions to access and transfer
   the "widget.png" file, a request for a "widget.png" thumbnail might
   look like this:


9) for the last sentence, you may want to make it clear that "Bytes"
is the descriptive text.

   The syntax of a positive response is:

      thmb-response  = "150" SP *TCHAR "(" 1*DIGIT 1*TCHAR ")" CRLF /
                        error-response

   '1*DIGIT' represents the size in octets of the forthcoming file
   transfer.  The value within the parentheses MAY include descriptive
   text, for example (123456 Bytes)

10) maybe use the IANA registry Operating System Names?
http://www.iana.org/assignments/operating-system-names/operating-system-names.xhtml

Windows XP includes the version and is listed in this registry as
"WINDOWS-NT-5.1" but not all are.

   "OS" is an optional argument identifying the operating system name,
   i.e., "Windows XP", "BSD UNIX", etc.

   "OSVer" is an optional argument identifying the operating system
   version number.



On Fri, Sep 17, 2010 at 5:44 PM, Mark P. Peterson <[e-mail]> wrote:
> Hi Anthony,
>
> Thank you.  I have updated the draft.  It can be found here:
>
> https://datatracker.ietf.org/doc/draft-peterson-streamlined-ftp-command-extensions/
>
> Mark P. Peterson - President
> http://www.RhinoSoft.com
> Voice: [phone]
> FAX: [phone]
>
>
> --------------------------------------------------
> From: "Anthony Bryan" <[e-mail]>
> Sent: Friday, September 17, 2010 3:08 AM
> To: "Mark P. Peterson" <[e-mail]>
> Cc: <[e-mail]>
> Subject: Re: [ftpext] Posted Update to "draft-peterson-streamlined-ftp-command-extensions"
>
> On Wed, Sep 15, 2010 at 8:20 AM, Mark P. Peterson <[e-mail]> wrote:
>> Hello,
>>
>> I have updated "draft-peterson-streamlined-ftp-command-extensions"
>> as per some suggestions from Anthony Bryan.  The IANA Considerations
>> section has been updated to reflect his suggestions.  The draft is
>> located here:
>>
>> https://datatracker.ietf.org/doc/draft-peterson-streamlined-ftp-command-extensions/
>
> thanks, Mark! I plan to give this a more thorough review soon, & I
> hope others will too.
>
>
> looking at the last example in each of these, should the last line of each be
>
>         S> 550 file.fid: Is a file.
>
> ?
>
> 3.4. DSIZ Examples
>
>   Assuming the presence of directory "A" on the server and that the
>   client has the necessary permissions to access and list it, a typical
>   DSIZ client-server exchange would be:
>
>         C> DSIZ A
>         S> 213 123456
>
>   Where 123456 is the number of octets on the server's file system
>   occupied by the directory "A" and its contents.
>
>   Assuming directory "A" cannot be listed due to client permissions,
>   the client-server exchange would be:
>
>         C> DSIZ A
>         S> 550 A: Permission denied.
>
>   Assuming the client provides the argument "file.fid" where "file.fid"
>   is an existing file, the client-server exchange would be:
>
>         C> DSIZ file.fid
>         S> 550 A: Is a file.
>
>
> 4.4. AVBL Examples
>
>   Assuming the client provides the argument "file.fid" where "file.fid"
>   is an existing file, the client-server exchange would be:
>
>         C> AVBL file.fid
>         S> 550 A: Is a file.
>
>
> --
> (( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
>  )) Easier, More Reliable, Self Healing Downloads
>
>



-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads