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

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

--On Monday, May 23, 2011 22:19 +0300 Mykyta Yevstifeyev
<[e-mail]> wrote:

> 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 "/", "\",
>...

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

Actually, modulo some very small differences in syntax and
semantics, the concept of a one-line FTP invocation goes back at
least to TENEX.  That one-line approach has been more or less
   ftp <host> <path>
and, modulo syntactic sugar and the user and password
identifiers (which, as you point out, aren't used very often
with the URI form), the URI just reflects that model.

But this is exactly where we have a philosophical difference.  I
hope I've got this right, but it seems to me:

-- You say that if we make any substantive changes, then no one
will pay any attention to what we say and will keep using what
was specified in 1738.

-- I respond by saying, "Ok, if that is the case, then updating/
replacing the definition in 1738 has no value other than dealing
with the half-obsolete status of 1738 itself.  And dealing with
that doesn't have nearly enough value to justify the effort of
producing a new document and getting it right."

-- Daniel says that a lot of implementations don't do what 1738
says anyway, so repeating what it says is silly.  (I hope that
interpretation isn't too far off the mark.)

-- I respond by saying "Ok, if that is the case, we have a mess
on our hands and it is irresponsible to produce a new spec that
does not clean up the mess.    So, either no new spec or a
cleanup.

-- If you respond to that by saying that you are convinced that
no one would pay any attention to a cleaned up and complete
specification either, then my answer would be that we are
finished: there is no value in spending any time on a new
specification that we are convinced, a priori, that no one is
going to pay any attention to.

And that is where we probably agree to disagree, since neither
of us is likely to convince the other.

Daniel wrote...

> Yes, perhaps. The question is then: are we doing an updated
> FTP URI scheme?
> 
> If we're not, what's the point of just repeating RFC1738 with
> its flaws once again?

Up to this point at least, I think we are 100% in agreement.

> Isn't there a middle-ground that at
> least maintains most of what RFC1738 says but that
> clarifies/corrects the biggest mistakes?

Probably.  But then we need to get consensus about what is a
"biggest mistake" and, in particular, whether some of the
interpretations of 1738 which you describe are the desired
behavior or just broken.  As one trivial example, Mykyta and I
seem to think that interpreting "ftp://servername.example.com/"
as an instruction to send "CWD" without an argument is broken;
the implementations you cite seem to differ.   So there isn't
100% agreement on that point.

So, even if we are trying to just "maintain[s] most of what
RFC1738 says but that clarifies/corrects the biggest mistakes",
we have issues with getting agreement, not just copying out and
editing some text.   That, in turn, makes the "clarify and
correct" job less different from "updating" than might be
assumed.

> If we *are* updating the FTP URI scheme, then surely we have
> more work to do...

Indeed.   And, despite my comments above, I'm painfully aware
that figuring out how to accommodate required commands that are
not in the 1738 definition, to think about paths and parameters,
and to allow to extension for new commands without having to
write a new definition of the URI each time is much more work
than trying to copy and clarify the 1738 material.    While I'd
be opposed to it, I can see the sense in a "copy and clarify but
don't specify anything new or different" model, especially if we
hope that an update and revision would come along in the future.

>> 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.
> 
> I agree with you John.
> 
> I think repeating old known mistakes in a new spec is a very
> bad idea and I would be very much opposed to that. Even if it
> doesn't "make things worse" in the spec, a fresh spec kind of
> makes the old mistakes more wrong in my view.

Concur.  And, fwiw, it is procedurally almost impossible because
the requirements for Proposed Standard include the "no known
technical omissions" rule.  An "old known mistake" is certainly
a known technical omission with regard to that rule.  While the
IESG can waive the rule, concluding that a new spec is useful
and necessary enough to justify doing so when there is an
existing published spec would seem to me to require a trip
beyond the plausible.

    john