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

Anthony Bryan <anthonybryan@gmail.com> Wed, 01 December 2010 05:59 UTC

Return-Path: <anthonybryan@gmail.com>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F483A6CEC for <ftpext@core3.amsl.com>; Tue, 30 Nov 2010 21:59:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.907
X-Spam-Level:
X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgcEekBDnusv for <ftpext@core3.amsl.com>; Tue, 30 Nov 2010 21:59:19 -0800 (PST)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id E49F53A6CEA for <ftpext@ietf.org>; Tue, 30 Nov 2010 21:59:18 -0800 (PST)
Received: by ewy8 with SMTP id 8so3454056ewy.31 for <ftpext@ietf.org>; Tue, 30 Nov 2010 22:00:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qmwyZRzwD3HEJCmmBPENHnwTyoXNZcu8+tgze1YxrX0=; b=XBBweoH5TvMmXoWvMhf2go3PZ0dvWwLbEVrhWYFqsb4GHHmF+9T/uuUdpiV7owWrvE gvLk1Y9vb/WoYUKWt/h2/WrLuRiyizJ37e5oYhhhqp6GLi9oxjCg/x/Twgx+f/QCOz3N 7vF3LGu+YtkhitBW06SDmvQnYzpl9HOyCoJvA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jz6m2Uh5ik1Z5/9cyxHXwmiJVpLsd0Eg+G28BW7eyHSwDs2XAMXr+CSesSONxc3Ivq 0bQvLjZXNhYzfLvC0IczIYDV3Zgk+tXAizMtuOwhq0u28sV1z3dRWcqMBE5EKQGAasVl lgjuJ10bTPQnLo7kNa43gGGGgADCcTqJxFsnU=
MIME-Version: 1.0
Received: by 10.213.104.138 with SMTP id p10mr3724071ebo.63.1291183231044; Tue, 30 Nov 2010 22:00:31 -0800 (PST)
Received: by 10.213.28.2 with HTTP; Tue, 30 Nov 2010 22:00:31 -0800 (PST)
In-Reply-To: <AANLkTinriyMy5_thOnx29HbGQ41NcYW+MS27YGDAjoNT@mail.gmail.com>
References: <1791E3B42BE242848B7FFFC7015B4563@rhinooffice.net> <AANLkTimeH+O4E4XEq6cdw0UaM4UpDTo6EKB9kB1x4PJh@mail.gmail.com> <139EAF2195BC496AA3F25288D56BFB43@rhinooffice.net> <AANLkTinriyMy5_thOnx29HbGQ41NcYW+MS27YGDAjoNT@mail.gmail.com>
Date: Wed, 01 Dec 2010 01:00:31 -0500
Message-ID: <AANLkTik9qaJgeVR4j-K+G-VErCCjHA2SL0cnkYq_+_J4@mail.gmail.com>
From: Anthony Bryan <anthonybryan@gmail.com>
To: "Mark P. Peterson" <mpp@rhinosoft.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ftpext@ietf.org
Subject: Re: [ftpext] Posted Update to "draft-peterson-streamlined-ftp-command-extensions"
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Dec 2010 05:59:20 -0000

looking good! the new version is up...

On Sat, Sep 18, 2010 at 5:13 AM, Anthony Bryan <anthonybryan@gmail.com> 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 <mpp@rhinosoft.com> 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" <anthonybryan@gmail.com>
>> Sent: Friday, September 17, 2010 3:08 AM
>> To: "Mark P. Peterson" <mpp@rhinosoft.com>
>> Cc: <ftpext@ietf.org>
>> Subject: Re: [ftpext] Posted Update to "draft-peterson-streamlined-ftp-command-extensions"
>>
>> On Wed, Sep 15, 2010 at 8:20 AM, Mark P. Peterson <mpp@rhinosoft.com> 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