Subject: draft-bryan-ftp-hash

From: Robert McMurray <[email-masked]>
Date: Fri, 7 May 2010 22:05:13 +0000

Anthony Bryan and I had been discussing draft-bryan-ftp-hash with Tim Kosse in an offline conversation, but we should consolidate our discussions in a more public forum.

With that in mind, what I had proposed to Anthony was that you might specify the hash type as parameter of the client request and server response, thereby allowing the server and client to continuously know which hashing algorithm is in use. For example:

   C> HASH <hashtype> SP <pathname>
   S> 213 <hashtype> SP <hexdigit>

I had mentioned that <hashtype> might be optional as a HASH request parameter since the draft had already specified using the OPTS command to specify a hash algorithm, but I recommended that the response should return the hash algorithm.

Anthony had expressed some interest in the response containing the <hashtype>, but Tim made an excellent point that it would be impossible to make the <hashtype> optional as a HASH request parameter because there is no standard for <pathname>, therefore the server wouldn't know whether "HASH MD5 foo" meant to hash the file "foo" using "MD5" or to hash the file "MD5 foo" using the current algorithm that was specified with an earlier OPTS command.

If <hashtype> was a mandatory parameter for both the client request and server response that would address Tim's point, but that would dramatically alter Anthony's original design.

Setting aside the discussion for the HASH request parameter for the moment, we could differentiate the <hashtype> from <hexdigit> or even <pathname> by defining the characters that the <hashtype> can contain by using ABNF like the following:

   hashtype = let-dig [ldh-str]
   let-dig  = ALPHA / DIGIT
   ldh-str  = *( let-dig / "-" ) let-dig

This syntax would allow for hashing algorithms like MD5, XCRC, CRC32, SHA-256, etc., but I'll leave it open for debate if that would be too restrictive.

Robert McMurray
US-IIS Product Unit
Email: [email-masked]

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 8 May 2010 22:58:38 +0200 (CEST)

On Fri, 7 May 2010, Robert McMurray wrote:

> If <hashtype> was a mandatory parameter for both the client request and 
> server response that would address Tim's point, but that would dramatically 
> alter Anthony's original design.

It would rather take it back to the original design (seen in 
draft-bryan-ftp-hash-00), as that first draft had <hashtype> in the HASH 
command. The reasoning for the removal of it and putting it into the OPTS 
command was, I believe, that it wasn't "FTPish" to take two different 
arguments like that in a single command.

> Setting aside the discussion for the HASH request parameter for the moment, 
> we could differentiate the <hashtype> from <hexdigit> or even <pathname> by 
> defining the characters that the <hashtype> can contain by using ABNF like 
> the following:

I would rather have it _either_ mandatory in the HASH command as the first 
argument _or_ only set with the OPTS command like draft-bryan-ftp-hash-02 
says.

I favour the -00 style slightly, but I don't feel strongly either way.

-- 

  / daniel.haxx.se

---

From: Anthony Bryan <[email-masked]>
Date: Thu, 13 May 2010 01:02:47 -0400

Robert, thanks for responding publicly...

On Fri, May 7, 2010 at 6:05 PM, Robert McMurray <[email-masked]> wrote:
> Anthony had expressed some interest in the response containing the <hashtype>, ...

I think having the hashtype in the response makes it unambiguous. Not
that I expect it to be common, but the client only knows the hashtype
if it's already issued OPTS HASH/FEAT or the session hasn't been
reinitialized. I wouldn't expect "blind" HASH requests but... :)

> If <hashtype> was a mandatory parameter for both the client request and server response that would address Tim's point, but that would dramatically alter Anthony's original design.

Daniel mentioned the history/reason already (-00 draft did it your
way), and here's some of the previous discussion started by Alfred.

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01387.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01436.html

> This syntax would allow for hashing algorithms like MD5, XCRC, CRC32, SHA-256, etc., but I'll leave it open for debate if that would be too restrictive.

The current draft defines allowed algorithms from the IANA registry
"Hash Function Textual Names" at
http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml

The current values: md2, md5, sha-1, sha-224, sha-256, sha-384, sha-512.

As you can see, CRC32 isn't listed.
The non-standard XCRC command is one of the most implemented, as far
as I can tell. (Note, there are algorithm specific non-standard
commands for others: MD5, XMD5, XSHA, XSHA1, XSHA256, XSHA512).

Should CRC32 be an option for the HASH command?

Another question, should HASH optionally support requesting partial
file hashes? Some of the non-standard commands (at least XCRC & XMD5
allow for this).

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