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

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

--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".  

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.

(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.

(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.

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, 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.

> 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".

regards,
    john