Subject: [ftpext] I-D Action: draft-ietf-ftpext2-hash-02.txt

From: [email-masked]
Date: Thu, 28 Jul 2011 12:02:06 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FTP Extensions, 2nd edition Working Group of the IETF.

	Title           : File Transfer Protocol HASH Command for Cryptographic Hashes
	Author(s)       : Anthony Bryan
                          Tim Kosse
                          Daniel Stenberg
	Filename        : draft-ietf-ftpext2-hash-02.txt
	Pages           : 16
	Date            : 2011-07-28

   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ftpext2-hash-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ftpext2-hash-02.txt

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 29 Jul 2011 13:18:35 +0300

Hello,

I'd like to provide some comments on draft-ietf-ftpext2-hash-02, which 
was uploaded on 28 July.

Section 2:

>     The term "pathname" is used as defined in Section 2.2 of
>     [RFC3659].

This statement and the "<pathname>" used in ABNF productions need to be 
clarified.  Explicitly, your document should be clear regarding the fact 
that <pathname> ABNF production is defined in RFC 3659 and is imported 
from there.  Moreover, as <pathname> is a valid ABNF production, and 
it's imported from RFC 3659, there is no reason to enclose it in the 
angle brackets when defining other ABNF productions.

In section 3:

>     hash-ok       = "213" SP hashname SP start-point "-" end-point SP filehash SP<pathname>  CRLF

RFC 5234 allows line breaks in ABNF definitions.  Ibid (and in Section 3.1):

>     hashname      = 1*( hchar )

It's OK to change this to:

>     hashname      = 1*hchar

here.  Ibid:

>     All hash values MUST be encoded in lowercase hexadecimal format.

This confuses with:

>     Note that in ABNF, string literals are case insensitive.

in Section 2.1.  RFC 5234 <HEXDIG> is:

>           HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

and therefore allows uppercase as well as lowercase a-f letters.  If you 
want to mandate use of lowercase only, please use "DIGIT / %x61-66"; but 
I don't think it makes sense.

In Section 3.5 you use the SHOULD RFC 2119 keyword.  From RFC 2119:

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>     may exist valid reasons in particular circumstances to ignore a
>     particular item, but the full implications must be understood and
>     carefully weighed before choosing a different course.

What may be such "valid reasons in particular circumstances" not to send 
the error response?  I'd recommend to use non-normative "should" here.

I've noted that Section 3.2 says:

>     The pathname argument MUST represent a file path, not a
>     directory path.

while Section 3.5 mentions:

>     The server-PI SHOULD reply with a 553 reply if the user requests the
>     HASH of a directory, which is not allowed.

Maybe you meant "a file which is placed in a directory, that is not 
allowed" here?

As an editorial issue.  RFC 5234 recommends to enclose ABNF productions 
in the text in < and > rather than ' and ', as you currently do.

Mykyta Yevstifeyev