Subject: FTP Extensions for Cryptographic Hashes (draft-bryan-ftp-hash)

From: Anthony Bryan <[email-masked]>
Date: Wed, 24 Mar 2010 17:30:12 -0400

Hi,

This ID proposes a feature where FTP clients can request the hash of a
file. A number of FTP clients and servers have implemented multiple
commands (XMD5, XSHA1, SITE SHOHASH, etc) that are not formally
specified, leading to non-interoperability and confusion.

We have talked to FTP application authors that are interested in this
feature. Others have previously resisted implementing this feature
because it isn't formally specified.

We already have some issues from Alfred Hoenes and John Klensin to
address. If you are interested, please review & reply.

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

A new version of I-D, draft-bryan-ftp-hash-00.txt has been
successfully submitted by Anthony Bryan and posted to the IETF
repository.

Filename:        draft-bryan-ftp-hash
Revision:        00
Title:           FTP Extensions for Cryptographic Hashes
Creation_date:   2010-03-23
WG ID:           Independent Submission
Number_of_pages: 7

Abstract:
The specification for the File Transfer Protocol does not include
methods to obtain cryptographic hashes of files.  Cryptographic
hashes can be used to identify files and verify integrity.
Unfortunately, because of the desire for this feature, multiple
commands that are not formally specified have been implemented in FTP
applications leading to non-interoperability and confusion.  This
specification documents an optional command where FTP clients can
request the cryptographic hash of a file from a FTP server.

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 24 Mar 2010 22:59:51 +0100 (CET)

On Wed, 24 Mar 2010, Anthony Bryan wrote:

> This ID proposes a feature where FTP clients can request the hash of a file. 
> A number of FTP clients and servers have implemented multiple commands 
> (XMD5, XSHA1, SITE SHOHASH, etc) that are not formally specified, leading to 
> non-interoperability and confusion.

Nice draft!

Here's one remark:

You use 550 as response code when the user isn't allowed to use the HASH 
command, but I find that 550 is otherwise often used for file-not-found in 
both SIZE, RETR and other responses.

Wouldn't it make sense to have a "file not found" response for when you try to 
HASH a non-existing file? Wouldn't it make sense to re-use the same error code 
(550) for that as other command use?

Maybe the "HASH not allowed" case can use 552 or 553?

-- 

  / daniel.haxx.se