Re: [ftpext] A few comments on draft-bryan-ftp-hash-05

[Anthony Bryan <[e-mail]>]

On Tue, Jul 27, 2010 at 6:37 AM, Paul Ford-Hutchinson
<[e-mail]> wrote:
>
>
> Anthony Bryan <[e-mail]> wrote on 26/07/2010 19:30:33:
>
>> On Sun, Jul 25, 2010 at 4:41 PM, Tim Kosse
>> <[e-mail]> wrote:
>> > On 2010-07-15 08:56, Paul Ford-Hutchinson wrote:
>> >
>> >> I propose that this draft specifically excludes HASH over a directory
>> >> (i.e. returns a 4xy error)
>> >
>> > Yes. Intuitively I would have implemented HASH without directory
>> > support, but I concur that it needs to be explicitly mentioned in the
>> > draft.
>>
>> the draft says this already:
>>
>> "The pathname argument MUST represent a file path, not a directory path."
>>
>> what should we add?
>
> Oops, must have missed that (even though I was looking for it).  Maybe
> resurrect the <blink> tag :-)

hehe :)

> In my defence I would expect to see this restriction on the server behaviour
> and not on the content of a client created value (the client may have no
> idea that /x/y/z is a directory and not a file).  i.e. I would expect to see
> it in section 3.4 (where I don't spot 553)

we'll add this in the next draft in 3.4:

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

do you think we should have more clarifications elsewhere? I guess
it's implicit, but the draft mentions file, file, and doesn't mention
directory except to say that it's not for that. if it doesn't
communicate that well, maybe we should make it more explicit.

>> further, Tim adds that this would be a permanent negative completion
>> (5yz) instead of transient negative completion (4yz) and suggests 553.
>
> The reason I put a 4xy was that path /x/y/z might be a directory one day and
> a file the next.  Revisiting the discussion on RFC959, I agree that it
> should be 5xy.  (55y to be more precise)

great.

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