Subject: Re: [ftpext] New Version Notification for draft-bryan-ftp-hash-05

From: Daniel Stenberg <[email-masked]>
Date: Wed, 30 Jun 2010 00:10:35 +0200 (CEST)

On Mon, 28 Jun 2010, IETF I-D Submission Tool wrote:

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

I think this is in a pretty good shape now.

First a little mistake:

The second paragraph in section 6, the first line says:

  "For performance reasons, a server SHOULD a avoid hashing multiple"
                                           ^^^

But I'm a bit skeptic regarding that entire sentense. It advices server 
implementors to care about if files are on the "same physical media" or not, 
and I don't think A) it is a "Security Consideration" in the first place and 
B) it is probably not a factor in many or most cases such as when you have SSD 
media, simply have the files in the cache or if you only allow 2 simultaneous 
users on the server.

My suggestion: remove that senstense and merge the rest of the paragraph 2 
with the previous paragraph.

(But yes, this is nitpicking.)

-- 

  / daniel.haxx.se

---

From: Anthony Bryan <[email-masked]>
Date: Tue, 29 Jun 2010 19:34:32 -0400

> I think this is in a pretty good shape now.

I think we're making progress! there may be some sentences or sections
out of order tho.

>  "For performance reasons, a server SHOULD a avoid hashing multiple"

good catch, writing late at night :)

> B) it is probably not a factor in many or most cases such as when you have
> SSD media, simply have the files in the cache or if you only allow 2
> simultaneous users on the server.
>

agreed, removed that sentence. I don't think I've seen mention of
related hardware concerns in similar specs.

another thing I wanted to bring up, in the HASH draft we import terms
from RFC 959 like pathname and other things like the Basic Tokens,
Server Replies, and Interpreting Examples from RFC 3659.

after reading draft-somers-ftp-mfxx-04, maybe we should import
pathname from section 2.2 of RFC 3659?

another thing, should we include the hash algorithm in the server
reply like Robert suggested earlier?

current, without alg:

   C> HASH filename.ext
   S> 213 80bc95fd391772fa61c91ed68567f0980bb45fd9

with alg (MD5) included:

   C> HASH filename.ext
   S> 213 MD5 80bc95fd391772fa61c91ed68567f0980bb45fd9

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

---

From: TJ Saunders <[email-masked]>
Date: Tue, 29 Jun 2010 16:41:06 -0700 (PDT)

>    S> 213 MD5 80bc95fd391772fa61c91ed68567f0980bb45fd9

I'm favor to the latter, i.e. including the hash algorithm name in the 
response.  It provides more information for humans who casually glance at 
the client output, and for server administrators reading logs which 
capture the entire response lines.

Cheers,
TJ

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

   Music, the greatest good that mortals know,
    And all of heaven we have below.

   	-Joseph Addison

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