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

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

Hi Anthony,

> in 3.1 you have:
> 
>    The 213 reply is formatted in such a way that the returned size value
>    can be machine parsed; the response MUST simply be the command
>    response followed by an integer value with no delimiters.
> 
> don't you want the same in 4.1?

Yes, I modified the document (version 11).

> this seems pretty vague and open ended. is it intended to be?
> 
> maybe something like this?
> 
>    A successful response includes a numeric value that is the number
>    of octets available as dictated by the physical limitations of the
>    underlying storage mechanism, or a limit imposed upon
>    <pathname> or a limit imposed upon the user that issued the command.

I changed it to use your text (version 11).

> still unfixed.

Yes, I was hoping to get a little help here, a suggestion on what the FEAT response
would look like, references, and changes to the samples.

> 11) as mentioned before, CSID is not in the IANA considerations section.

I have added it to the document (version 11).

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

--------------------------------------------------
From: "Anthony Bryan" <[e-mail]>
Sent: Wednesday, December 01, 2010 12:00 AM
To: "Mark P. Peterson" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: [ftpext] Posted Update to "draft-peterson-streamlined-ftp-command-extensions"

looking good! the new version is up...

On Sat, Sep 18, 2010 at 5:13 AM, Anthony Bryan <[e-mail]> wrote:
>
> some other issues...
>
> 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.
>
> 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.


in 3.1 you have:

   The 213 reply is formatted in such a way that the returned size value
   can be machine parsed; the response MUST simply be the command
   response followed by an integer value with no delimiters.

don't you want the same in 4.1?

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

this seems pretty vague and open ended. is it intended to be?

maybe something like this?

   A successful response includes a numeric value that is the number
   of octets available as dictated by the physical limitations of the
   underlying storage mechanism, or a limit imposed upon
   <pathname> or a limit imposed upon the user that issued the command.

> 6) THMB FEAT response is in 5.3
>
>   Image formats supported by the server are listed in the THMB FEAT
> Response [6.3].

still unfixed.

11) as mentioned before, CSID is not in the IANA considerations section.

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



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