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

From: "Mark P. Peterson" <[email-masked]>
Date: Wed, 1 Dec 2010 13:03:32 -0600

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: +1(262) 560-9627
FAX: +1(262) 560-9628  

--------------------------------------------------
From: "Anthony Bryan" <[email-masked]>
Sent: Wednesday, December 01, 2010 12:00 AM
To: "Mark P. Peterson" <[email-masked]>
Cc: <[email-masked]>
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 <[email-masked]> 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 <[email-masked]> 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: +1(262) 560-9627
>> FAX: +1(262) 560-9628
>>
>>
>> --------------------------------------------------
>> From: "Anthony Bryan" <[email-masked]>
>> Sent: Friday, September 17, 2010 3:08 AM
>> To: "Mark P. Peterson" <[email-masked]>
>> Cc: <[email-masked]>
>> Subject: Re: [ftpext] Posted Update to "draft-peterson-streamlined-ftp-command-extensions"
>>
>> On Wed, Sep 15, 2010 at 8:20 AM, Mark P. Peterson <[email-masked]> 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

---

From: "Alun Jones" <[email-masked]>
Date: Fri, 10 Dec 2010 09:37:18 -0800

> From: [email-masked] [mailto:[email-masked]] On
> 
> <chair hat="off">
> I feel strongest about CSID (similar to Robert's AGNT or CLNT) & AVBL
> (which is similar to
> http://tools.ietf.org/html/draft-dilip-ftpext-safe-transfer-00#section-
> 5.1
> ). like HASH, apparently, these issues keep popping up & people keep
> solving them, so maybe it is best to finally offer a standardized
> command. RMDA, DSIZ, and THMB also sound useful in some cases, I look
> forward to seeing their evolution.

I see AVBL as being very similar to the ALLO command - in fact, for many of
the suggested uses of AVBL (checking that space is sufficient before
starting a long upload), it would seem that ALLO is better. Using AVBL to
check if there's room for a 10GB file suffers from the possibility that
there are two users uploading a 10GB file, and each gets to put 5.1GB up
before failing. Using ALLO means that whoever requests the space first, gets
that space (subject to quota requirements), the other guy gets told he can't
upload right now.

ALLO is defined in RFC 959 (and probably earlier).

Alun.
~~~~