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

[Mykyta Yevstifeyev <[e-mail]>]

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

28.07.2011 22:02, [e-mail] wrote:
> 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