Re: [ftpext] Soliciting comments/reviews on draft-yevstifeyev-ftp-uri-scheme

[Mykyta Yevstifeyev <[e-mail]>]

Hello Daniel, and thanks for comments.

See my responses in-line.

22.05.2011 20:45, Daniel Stenberg wrote:
> On Sun, 22 May 2011, Mykyta Yevstifeyev wrote:
>
>> I'm writing to ask people to comment my draft 
>> draft-yevstifeyev-ftp-uri-scheme, that may be found here:
>
> Hi
>
> I think the document looks fine and basically repeats what RFC1738 
> says. It would be really helpful if it would mention where or how it 
> differs from RFC1738.
OK, I'll add some words on it (probably in a separate Appendix).
>
> My concern is "The <ftp-path> Part", section 2.2.3, and the problems 
> aren't really introduced by you but repeating existing problems in a 
> brand new document seems a bit unnecessary.
>
> The original problem I have with this exists already in RFC1738 as it 
> mandates a CWD command for each <cwd> part of the path. There are lots 
> of servers out in the wild who are configured to not allow this, but 
> yet allows the client to do a single CWD to the entire path. That 
> means "CWD dir1/dir2" works while "CWD dir1" fails. We can of course 
> just consider such servers as non-compliant but clients may still need 
> to consider this (and I know lots of clients only do the CWD <full 
> path> approach).
I think the following text would be OK:

(the algorithm of handling <ftp-path>):
>  (1a) each of <cwd> parts are consistently supplied as arguments
>       to the CWD (change working directory) FTP command after
>       establishing the FTP connection to the server identified
>       by the <host-port> part of the URI; or
>
>  (1b) the whole path (the <cwd> parts together) is supplied
>       as an argument to the aforementioned command;
>
>       [ . . . ]
It addresses your concern, I believe.  Does it look fine?
> The next problem in the same section is what to do with empty <cwd> 
> parts. As in "ftp://example.com/path1//path2". RFC1738 acknowledges 
> that the <cwd> parts may be empty. It continues to say that each <cwd> 
> should result as an argument to CWD. But lots of FTP servers will 
> treat "CWD" with a blank argument similar to what unix machines does 
> with 'cd' without a directory: it changes directory to a 
> pre-determined location (home directory) that certainly is not at all 
> what the client wants for this. A "normal" FTP client will therefore 
> not issue a separate CWD for empty parts.
>
> In draft-yevstifeyev-ftp-uri-scheme there's no mention of the fact 
> that <cwd> can be empty (which isn't really solving how to deal with 
> them) but there's a similar mention that each <cwd> should be passed 
> on to CWD.
I'll correct this issue as well, mentioning the ability of null <cwd>s 
as well as rules for their handling, proposed by you.

Mykyta Yevstifeyev