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

[John C Klensin <[e-mail]>]

--On Sunday, May 22, 2011 19:45 +0200 Daniel Stenberg
<[e-mail]> 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.
> 
> 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).
> 
> 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.

Daniel,

I think we really need to be careful about your line of
reasoning here (whether 1738 is correct or not).  CWD was
defined for environments in which not only was the path
separation identifier unknown (take your pick among "/", "\",
".", and ">" at least) but in which there was a real possibility
that 
   CWD a
   CWD b
would have different semantics and lead to a different place
than 
   CWD a<delim>b (e.g., "CWD a/b").

I vaguely recall a discussion about a possible "set path
hierarchy delimiter" command a long time ago; nothing came of it.

And, while some systems (as you point out) construe the
equivalent of "CWD" (no arguments) as, e.g., "cd $HOMEDIR$",
others construe it as "return name of current directory", e.g.,
a synonym of "pwd".  Having a URL with elements that have
semantics that different, depending on what the implementation
does, is just looking for trouble.

By contrast, the semantics of the FTP protocol when no CWD
commands are transmitted (presumably what happens when no
<ftp-path> appears in the URL as specified in 1738) are
perfectly well defined: an FTP server implementation must have a
way to bind a default (or "home" or "startup") directory to the
user/pass [/acct] triple and that is where one ends up and stays.

It seems to me that, if we are doing to do an updated FTP URI
scheme, we need to either:


(1) Clean this mess up and generate a scheme that really
reflects the protocol.   That might well mean deprecating
(although probably retaining for backward-compatibility)
ftp-path in ftp://host/path-element1/path-element2/.../filename
form and moving toward something more like

ftp://host/filename;cwd=path-element1;cwd=path-element2;...;typecode=type;...
(or using query syntax for some or all of those elements).

Cleaning up the mess almost certainly also requires permitting
additional parameters or other mechanisms for ACCT, PASV, and
the sundry extensions that have come along, including those
under consideration by the FTPEXT WG.  Having a WG to extend FTP
(the second one, with several extensions accepted by the earlier
WG) and then approving a URL whose syntax covers only a small
subset of the required commands (and one optional one) from RFC
959 makes no sense to me at all.

As one of many example, this community is on record as not
considering protocols that need authentication mechanisms and
whose only mechanism is cleartext names and passwords acceptable
any more.  We not only have a few mechanisms available for
better FTP authentication, but this draft mentions them in its
Security Considerations section.  But neither of those
mechanisms are accessible via the proposed revised URI.

The spec probably also has to have a serious discussion of what
happens when something is specified that the server rejects.  If
one's model is a URI processor that calls on an FTP client, it
would be useful to figure out and specify what the URI processor
should tell the user when the FTP client gets a 5xx (or worse)
reply back from the FTP server.  I suppose "you lose" could be
an answer but, if we don't think that is acceptable, some
discussion of how one maps from the vocabulary of FTP to the
vocabulary of URIs seems necessary.

I note that this document not only does not contain any
provision for extensions to accommodate additional
commands/parameters (those that have been approved already and
those that might be approved by the FTP WG) either.  That, to
me, is just broken.


(2) Deprecate the FTP URI entirely, name what this document
covers something that conveys
"Restricted-FTP-for-Unix-like-systems:", and move on, hoping
that someone will do a real FTP and FEAT-compatible URI at some
future data.

There is obviously a high-level issue in all of this, which is
whether it either acceptable to the community or a good use of
IETF time to take an old spec and update it in some minor ways,
ignoring known issues because the new spec doesn't make things
any worse.  My position is that it is not a good use of time and
may be irresponsible.   Mykyta and I have discussed that issue
in other contexts and may ultimately need to agree to disagree,
but I worry about the marginal opportunity costs for the
community of trying to review specs like this one.

regards,
     john