Re: [ftpext] [Uri-review] draft-yevstifeyev-ftp-uri-scheme-02 posted

[Mykyta Yevstifeyev <[e-mail]>]

Hello all,

20.06.2011 15:13, John C Klensin wrote:
>
> --On Monday, June 20, 2011 17:39 +0900 "\"Martin J. Dürst\""
> <[e-mail]>  wrote:
>
>> Hello John,
>>
>> I'm not at all an expert in FTP, nor in the details of the
>> current ftp: URI implementations. But the overall direction of
>> your mail seems to be
>> "if it's in the FTP protocol, then it has to be in the ftp URI
>> scheme".
> Not really what I'm saying.  I just think that an FTP URI has to
> be sensitive to FTP usage and the way the protocol actually
> works.  At least IMO, a poor job was done of that in 1738; if
> one proposes a standalone, standards-track FTP URI today, I'm
> going to do parts of that analysis and then keep repeating
> "known technical omission".  As far as the extensions are
> concerned, I imagine that some of them are important and some
> are not.  Since both the URI review and FTPEXT2 mailing lists
> are being copied on this, I suggest that the latter ought to be
> considering whether, if a given extension is not important
> enough to be included in the URI, it is really worth the trouble
> as an extension.  I can well imagine the answer for some
> extensions being "not important enough for the URI but still
> worth doing", but I think that is a discussion the WG needs to
> have".
I agree here, so let's have a discussion.
> Three examples of the "known technical omission" problem:
>
> (i) At least historically, the most-used command in the FTP
> protocol, other than the basic authentication ones (USER, PASS),
> CWD and PWD and the basic ones actually involved in transferring
> files (RETR, STOR, and probably PASV) has been TYPE.  It is not
> like, e.g., STRU or the file structuring commands, which many
> people and servers can go for many years without ever seeing.
> TYPE was really important in the early days of the net when we
> not only had EBCDIC floating around, but had at least three
> different ways to encode ASCII.  A decade and a half ago, only
> the CRLF issue remained and, if examined from a narrow web
> perspective (see below), it doesn't make much difference (the
> number of problems it causes every year, with lusers not
> understanding the symptoms and a distinct shortage of standard,
> user-accessible, conversion utilities on most systems, remains
> non-trivial).   It gets more important again as we see more and
> more files in non-ASCII character sets, both Unicode and
> non-Unicode.  Even with the former alone, an IMAGE transfer may
> yield any of more than a half-dozen forms (see
> draft-ietf-appsawg-3536bis for a list that still does not
> include the obscure ones).  So, to me, saying "TYPE" is not
> needed or should be treated like any other extension indicates a
> lack of understanding of the underlying protocol.
Probably.  However, if we agree on leaving this part, we will need to 
have a discussion on the handling of this part in the URI, since RFC 
1738 isn't clear with this regard.
> (2) There is currently a proposal in the FTPEXT2 WG to add a
> HOST command to FTP (draft-ietf-ftpext2-hosts) for exactly the
> same reason we needed to add one to HTTP.  I'm personally not a
> fan of that particular way of doing the job, but one of the
> strong arguments for it is that it could potentially be
> automated in a shim or API that connects an FTP URI processor to
> the FTP protocol as "always send HOST, if it is rejected as not
> recognized, ignore and pretend it wasn't sent".  But, if we
> think HOST is important, that needs to be considered and
> explicitly discussed in any FTP URI document.  If it isn't
> important enough to be considered and discussed, then the
> extension probably isn't important enough to adopt and use.
> Since the WG hasn't acted on the proposal, the issue is somewhat
> forward-looking, but that puts the current FTP URI proposal in
> the same boat as MAILTO -- it is hard to define a URI for a
> protocol to which it is not integral and has to be retrofitted
> when the protocol itself is being changed/extended in ways that
> should rationally affect the URI.
I've carefully read the FTPEXT2's draft on the proposed HOST command.  
HOST is surely a good proposal to use at all and I currently think 
including it in the URI specification for FTP is probably a good idea.  
So, with this respect I can agree with you and, therefore, agree to 
include this proposal in the 'ftp' URI specification.
> (3) For obvious security reasons, username-password pairs ceased
> being popular around the IETF many years ago.  Username-password
> pairs embedded in URIs in clear text are much worse.  Some of
> the extensions you (and Mykyta) dismiss provide ways around that
> problem.  In addition, for the very popular 'anonymous' use of
> FTP, we know what the password patterns are: a reserved/known
> keyword, such as "guest"; an email address; or "server simply
> doesn't care what is sent".   That could be built into the
> URI-interpreting protocol interface mechanism as well, but the
> current document circles around it with a lot of handwaving.
In the current draft we have the following situation: if there are no 
user credentials in the URI at all, anonymous FTP is used; however, if 
there are a user name and password (or just a user name), they are first 
used.  IMO, denoting user credentials in the URI isn't bad enough to 
abandon such capability.  Those people who care about security much will 
be free not to include the user information in the URIs.  Yet, if, for 
instance, some person wants to share their FTP account with the other 
one, including the user-info in the URI is the best option among all 
possibilities to do this.  So I don't think removing the user-info part 
from the URI and making use of anonymous FTP mandatory is a good idea.  
I'd better care about denoting the account information in the URI, which 
is one of the "technical omissions" too.
> Note that neither (2) nor (3) would require any changes to the
> URI or its syntax, only a specification that understood the FTP
> protocol and its use much better.
>
>> In my eyes, that's just a non sequitur. If you look at HTTP,
>> there are a lot of bits and pieces that are in the protocol
>> but are not in the URI scheme, for good reasons.
> Sure.  I trust I don't need to point out to you either that URLs
> and HTTP were designed together for use with each other and that
> most of the decisions as to what was left out were made after
> careful consideration, not by accident and in haste (and, for
> the record, I'm criticizing 1739
Maybe you meant 1738 here.
> , not Mykyta's proposal).
>
>> If you look
>> at the mailto: URI scheme, then there are also a lot of
>> features in SMTP and in the message format that are not
>> available in the scheme. In fact for the mailto: scheme, in my
>> understanding, the header part of the message format is now
>> covered, but it was the spec that caught up with
>> implementations, not the other way round.
> And the mailto: spec is also an example of the difficulties one
> can get into when one naively retrofits a URI on top of an
> established and widely-deployed protocol.
>> Also, to claim that a spec that describes what's currently
>> implemented (let's assume it does) can only go to
>> informational, and that for standards track, it's necessary to
>> cover all the features in the base protocol is totally new to
>> me. As far as I understand it, the IETF is first and foremost
>> about "rough consensus and running code" and only later about
>> "known technical omissions".
> Informational documents that describe something as already
> deployed and unlikely to change are actually common and are
> written with the understanding that the IETF has little to offer
> in terms of adding value to the protocol other than to document
> it.  For standards track, I invite you to read 2026, where
> "known technical omissions" is one of the few clear bars to
> adopting a Proposed Standard.
This is mostly a question to discuss.  My personal opinion is a bit 
double.  From the one side, Standards Track document should describe 
what is widely-accepted.  From the other side, it must not have 
different technical issues which aren't clear enough.  I think something 
like this is appropriate for our case: taking the existing URI 
specification and appending any necessary features to it.
>> With that, I don't want to necessarily say that I would
>> disagree with what you wrote e.g. specifically about the TYPE
>> parameter. But I very strongly think that this and other
>> details have to be argued on their merits, rather than on a on
>> the base of a non-existing principle of "if it's in the
>> protocol, it has to be in the URI scheme".
> See above.  I'm not arguing  "if it's in the protocol, it has to
> be in the URI scheme".  I'm arguing precisely for some careful
> consideration on a case-by-case basis and against a different
> non-existent principle of "if it was omitted from RFF 1738, we
> don't need it".

All the best,
Mykyta Yevstifeyev
> regards,
>      john
>
>