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

[Mykyta Yevstifeyev <[e-mail]>]

23.05.2011 20:53, John C Klensin wrote:
> --On Sunday, May 22, 2011 19:45 +0200 Daniel Stenberg
> <[e-mail]>  wrote:
> [ . . . ]
>
> 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.
With respect to this issue, I think mentioning that null <cwd>s must 
cause no commands generated and dent out is OK and suits to the common 
sense.  Defining such parts causing sending "CWD" with no arguments 
really looks wrong; so I think specifying "noting to do if <cwd> is 
null" should be fine.
> 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.
Complete re-specifying of 'ftp' URI scheme seems quite interesting; yet, 
it's too radical.  The scheme in its existing view has been used in the 
Internet for years.  I don't think folks will be encouraged to change 
their apps to suit new syntax/semantics and will continue using the old 
one, even if it is formally deprecated.  RFC 1738 was written at the end 
of 1994, RFC 1630 - in the middle.  Paul's draft, as I remember, was 
written at the end of 2005; these three documents make no change to the 
'ftp' scheme (maybe 1630 isn't a good example of this, but...).  So, I 
should repeat that even though making up a completely new spec of 'ftp' 
URI is a good deed, it isn't really worth the energy which would be put 
in it since it is very likely to get ignored.
> 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.
Indeed.  But the current situation is left "as is" is for historical 
purposes as well.  If we mention, eg. user-pass part of 'ftp' URI should 
have an optional "auth-part" of ";AUTH=<auth-type>" (as in many URI 
schemes, such as 'pop' or 'imap'), define a set of initial tokens for 
<auth-types>, establish a registry for them, describe everything related 
to this and then pass the specification to implementators, they will 
probably ignore this new possibility and will continue to make the FTP 
clients compatible with "user:pass" userinfo part, not the new one.  So 
my opinion is just the same as above.
> 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.
On this I can't disagree; so this issue needs wider community discussion.
> 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.
See my response #2, it concerns this as well.
>
> (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.
Considered your first proposal, would be a good idea, but considering it 
separately it's probably a bad one.  The 'ftp' URIs in their curent form 
are widely used; so deprecating it won't reault in anything good, in my 
opinion.  I think such redical actions won't be accepted by the 
community; so "updating old spec. correcting minor mistakes" seems to be 
a good approach for now.

Mykyta Yevstifeyev
> 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
>
>
>