Re: [ftpext] Fwd: New Version Notification for draft-bryan-ftpext-hash-00.txt

Mat Berchtold <> Sat, 07 April 2012 01:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C88911E8086 for <>; Fri, 6 Apr 2012 18:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QudYjoVoqmr2 for <>; Fri, 6 Apr 2012 18:10:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C905911E8074 for <>; Fri, 6 Apr 2012 18:10:11 -0700 (PDT)
Received: from M.smartsoft.local ([fe80::fd57:1201:8518:71bc]) by m.smartsoft.local ([fe80::fd57:1201:8518:71bc%12]) with mapi id 14.02.0283.003; Fri, 6 Apr 2012 18:10:15 -0700
From: Mat Berchtold <>
To: Anthony Bryan <>
Thread-Topic: [ftpext] Fwd: New Version Notification for draft-bryan-ftpext-hash-00.txt
Thread-Index: AQHNFFZg8N/9bftxY0ett47c6YlCdJaOhFrw
Date: Sat, 7 Apr 2012 01:10:14 +0000
Message-ID: <36F3A30DD743D74C9BE4FF935AB5B5F30E2599A5@m.smartsoft.local>
References: <> <> <36F3A30DD743D74C9BE4FF935AB5B5F30E259865@m.smartsoft.local> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [ftpext] Fwd: New Version Notification for draft-bryan-ftpext-hash-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Apr 2012 01:10:12 -0000

>any suggestions?
In my opinion the dependency on RANG for partial hashes adds unnecessary complexity and hinders adoption. The range can be passed directly to the command as optional arguments:
hash-command = "HASH" SP pathname [ SP start-point [ SP end-point ] ]
start-point   = 1*DIGIT
end-point     = 1*DIGIT

I would like to see support for partial hashes as mandatory (MUST) for HASH. This way no special announcement in FEAT is required. If the server cannot calculate the hash over a range it still can return an error like 504. The important part is that the server won't return the hash value for the full range if a range is specified.

-----Original Message-----
From: Anthony Bryan [] 
Sent: Saturday, 07 April, 2012 02:36
To: Mat Berchtold
Subject: Re: [ftpext] Fwd: New Version Notification for draft-bryan-ftpext-hash-00.txt

On Fri, Apr 6, 2012 at 7:35 PM, Mat Berchtold <> wrote:
>>3.3.  Partial File Hashes with RANG
> I have some concerns or better a lack of understanding regarding the partial hashes specification.
> How does the client know if partial hashes are supported without trial&error?
> Let's assume the following:
> 1. Server supports partial transfers (draft-bryan-ftp-range) and announces it in the FEAT as: RANG STREAM.
> 2. Server announces the HASH command in the FEAT reply as HASH 
> SHA-256*
> Does this now automatically imply that partial hashes (RANG followed by HASH) are supported as well?

my quick Friday night answer, we should announce partial hashes in HASH's FEAT and maybe a specific error code for when partial hashes aren't supported?

any suggestions?

from RFC 959:

         503 Bad sequence of commands.
         504 Command not implemented for that parameter.

"A refinement of that is the 504 reply for a command that is implemented, but that requests an unimplemented parameter."

(( Anthony Bryan ... Metalink [ ]
  )) Easier, More Reliable, Self Healing Downloads