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

[Mykyta Yevstifeyev <[e-mail]>]

Hi John, Daniel, all,

Thanks for your responses once more.  See my comments in-line.

24.05.2011 6:03, John C Klensin wrote:
>
> --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.
Yes, I've said this.
> -- 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."
See below.
> -- 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.)
Agreed with this as well.
> -- 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.
Also see below.
> -- 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.
I didn't want to say that no one would care attention to an updated 
specification if it was published.  Some would probably do; and the new 
'ftp' URI scheme might be Ok enough to abandon the old one.  However I 
do think it makes sense to document the 'ftp' URI *as it is currently 
used* on the Standards Track.  What I really deem fine to clean up the 
mess, as you say, is:

(1) specifying the scheme borrowing the 1738 basis on Standards Track as 
it is currently used correcting major and minor flaws/uncertainties and 
allowing 1738 to approach its "obsolete" status;

(2) making up the Experimental document proposing a new, experimental 
form of the 'ftp' URI scheme, cleaning up most of the mess in existing 
specification;

(3) observing whether people are satisfied by new proposed syntax or are 
Ok with the old one;

(4) deciding whether to change the official spec using the new form or 
leaving the old one.

This, I think, will allow to propose a new form without having made 
radical changes to Standards Track, but see if it is really fine.  So I 
should agree that updating (in fact, re-specifying) 'ftp' URI scheme is 
certainly necessary, but it should be done in other way, as I proposed 
above.

Now for Daniel's comments.
> 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.
I agree as well.
>> 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.
My personal opinion is that this way is the most satisfactory, following 
the golden mean principle.  And I think it will be possible to reach an 
agreement on the necessary changes to 1738 specification.
>> 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,
I'm really glad to hear this :-)  That's what my draft tries to do.  As 
for the expectations for more radical changes, I think they will really 
appear soon (see my comment #1).
>   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.
By the way, another requirement for PS is (citing 2026):

>     A Proposed Standard specification is generally stable, has resolved
>     known design choices, [ . . . ]
and, thus, changing the spec radically will certainly fail to suit this 
rule.  But, the way I proposed at the beginning of the message is 
certainly fine to allow the new ftp URI scheme syntax receive these 
"design choices".

So, as far as I can see, we all have reached the following consensus:

(1) repeating 1738 is certainly a bad idea;

(2) repeating 1738 and correcting all known major and minor issues 
should be fine;

(3a) 'ftp' URI scheme really needs more fundamental work; but

(3b) /am not sure if all agree/ it should be done in other way.

Mykyta Yevstifeyev

>      john
>
>