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

From: Anthony Bryan <[email-masked]>
Date: Fri, 6 Apr 2012 19:02:14 -0400

we've updated the HASH & RANGe drafts.

any comments?

http://tools.ietf.org/html/draft-bryan-ftpext-hash
http://tools.ietf.org/html/draft-bryan-ftp-range

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Fri, Apr 6, 2012 at 4:47 PM
Subject: New Version Notification for draft-bryan-ftpext-hash-00.txt
To: [email-masked]
Cc: [email-masked], [email-masked]

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

Filename:        draft-bryan-ftpext-hash
Revision:        00
Title:           File Transfer Protocol HASH Command for Cryptographic Hashes
Creation date:   2012-04-06
WG ID:           Individual Submission
Number of pages: 16

Abstract:
  The File Transfer Protocol does not offer any method to verify the
  integrity of a transferred file, nor can two files be compared
  against each other without actually transferring them first.
  Cryptographic hashes are a possible solution to this problem.  In the
  past, several attempts have been made to add commands to obtain
  checksums and hashes, however none have been formally specified,
  leading to non-interoperability and confusion.  To solve these
  issues, this document specifies a new FTP command to be used by
  clients to request cryptographic hashes of files.

The IETF Secretariat

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

---

From: Mat Berchtold <[email-masked]>
Date: Fri, 6 Apr 2012 23:35:29 +0000

>draft-bryan-ftpext-hash
>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?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anthony Bryan
Sent: Saturday, 07 April, 2012 01:02
To: [email-masked]
Subject: [ftpext] Fwd: New Version Notification for draft-bryan-ftpext-hash-00.txt

any comments?

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Fri, Apr 6, 2012 at 4:47 PM
Subject: New Version Notification for draft-bryan-ftpext-hash-00.txt
To: [email-masked]
Cc: [email-masked], [email-masked]

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

Filename:        draft-bryan-ftpext-hash
Revision:        00
Title:           File Transfer Protocol HASH Command for Cryptographic Hashes Creation date:   2012-04-06 WG ID:           Individual Submission Number of pages: 16

Abstract:

The IETF Secretariat

--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads _______________________________________________
ftpext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ftpext

---

From: Bruce Blackshaw <[email-masked]>
Date: Sat, 07 Apr 2012 09:37:53 +1000

Given that XCRC is quite widely implemented, it is worth considering 
adding support for CRCs so that clients and servers that implement XCRC 
could easily be modified to comply with this new command.  That would 
certainly encourage acceptance.

If this was done then SHA-1 support wouldn't be mandatory. Of course 
CRCs aren't hashes so the name of the command might need to be modified 
to CHCK or something like that.

Also, in the reply, I would prefer the order to be altered so that the 
hash comes first, and also make the other fields optional, e.g.

213 f0ad929cd259957e160ea442eb8098... [filename.txt SHA-256 0-99]

Actually 99% of the time you aren't going to care about the range, and 
as you've just requested the file by name there's probably no need to 
return the filename at all.

I would consider just returning this:

213 f0ad929cd259957e160ea442eb8098 [0-99]

where the range is only returned if RANG has been used.

regards

Bruce Blackshaw
Enterprise Distributed Technologies
http://www.enterprisedt.com

On 7/04/2012 9:02 AM, Anthony Bryan wrote:
> we've updated the HASH&  RANGe drafts.
>
> any comments?
>
> From:<[email-masked]>

-- 
---------------------------------
Want some help around the house?
http://www.helparoundthehouse.com.au

---

From: Anthony Bryan <[email-masked]>
Date: Fri, 6 Apr 2012 20:35:43 -0400

> 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."

---

From: Mat Berchtold <[email-masked]>
Date: Sat, 7 Apr 2012 01:10:14 +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 [mailto:[email-masked]] 
Sent: Saturday, 07 April, 2012 02:36
To: Mat Berchtold
Cc: [email-masked]
Subject: Re: [ftpext] Fwd: New Version Notification for draft-bryan-ftpext-hash-00.txt

> 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:

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

---

From: Sob <[email-masked]>
Date: Sat, 07 Apr 2012 04:32:47 +0200

At 03:10 7.4.2012, Mat Berchtold wrote:
>The range can be passed directly to the command as optional arguments:

It can't, at least not like this, simply because if the server gets, e.g.:

HASH somepath 10 20

.. it can mean any of the following and it's impossible to tell which one:

a) pathname = "somepath", start-point = 10, end-point = 20
b) pathname = "somepath 10", start-point = 20
c) pathname = "somepath 10 20"

It would work with reversed order, with mandatory start and end 
points before pathname, but if RANG catches up (and it should, 
because it has big potential), wouldn't it be a little weird to have 
separate way for using ranges with HASH?

--

---

From: Mat Berchtold <[email-masked]>
Date: Sat, 7 Apr 2012 03:14:16 +0000

It depends how pathname is defined. If it's imported from Section 2.2 of [RFC3659] as currently proposed I agree with you. But I'm also okay with the mandatory start/stop points:
>hash-command = "HASH" SP start-point SP end-point SP pathname

The main concern I have is with the dependency on RANG in HASH. 

-----Original Message-----
From: Sob [mailto:[email-masked]] 
Sent: Saturday, 07 April, 2012 04:33
To: Mat Berchtold; Anthony Bryan
Cc: [email-masked]
Subject: Re: [ftpext] Fwd: New Version Notification for draft-bryan-ftpext-hash-00.txt

HASH somepath 10 20

It would work with reversed order, with mandatory start and end points before pathname, but if RANG catches up (and it should, because it has big potential), wouldn't it be a little weird to have separate way for using ranges with HASH?

--

---

From: Tim Kosse <[email-masked]>
Date: Sun, 08 Apr 2012 18:53:56 +0200

On 2012-04-07 05:14, Mat Berchtold wrote:
> But I'm also okay with the mandatory start/stop points:

Then we need a special designator to indicate that the whole file should
be hashed if its size is unknown, e.g. both start-point and end-point
set to 0.

Regards,
Tim Kosse

---

From: TJ Saunders <[email-masked]>
Date: Mon, 9 Apr 2012 12:03:05 -0700 (PDT)

> be hashed if its size is unknown, e.g. both start-point and end-point

I think that using 0 (zero) for both start and end offsets to indicate the 
entire file is acceptable, even encouragable: it is similar to the 
fcntl(2) locking API on Unix.

TJ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   I wanted only to try to live in accord with the promptings
   which came from my true self.  Why was that so very difficult?

     -Herman Hesse

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~