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

Mykyta Yevstifeyev <evnikita2@gmail.com> Tue, 24 May 2011 14:29 UTC

Return-Path: <evnikita2@gmail.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C06E074C; Tue, 24 May 2011 07:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.506
X-Spam-Level:
X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ANDzqAq59cd; Tue, 24 May 2011 07:29:19 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5285DE06AF; Tue, 24 May 2011 07:29:18 -0700 (PDT)
Received: by bwz13 with SMTP id 13so6577186bwz.31 for <multiple recipients>; Tue, 24 May 2011 07:29:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fGpTY7aiPt+FHdSz1g/NHy9Q5Af9501UxYZoYHqlMq0=; b=bULnDzhEmvhqlOIi56o4J5ME7wplz2zLnU0pb3y+FrR6j9rsHDDMfkHxi83JMJ0IBI eMxMrQLzfmCFMKEuNGMmECd0AOL7/vdBQIKSwTObPVp948/MuvvhOE3U/Uvfa8ePSaZU RF5XK69Rkxfak2TTz/AMefNBuJ6q8u6bG+BRc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PUlT7ZrDqZ4dE6Y43W+uqowuLuRS1a92vBemRdGYWwDrNz1+GVdn8gL++Z4T1QdfIE n8PRxqU0MkDSpgxGv9kxt0kea5q2HY27Bwdr8o3nN7OXKVlIdnkCiRO5vLmhGgBrcCyw /PS0HzAezq1qtzU7SZa1U+oieh6Wi1nDOTU28=
Received: by 10.204.80.28 with SMTP id r28mr3342095bkk.46.1306247357142; Tue, 24 May 2011 07:29:17 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id l1sm4597378bkl.13.2011.05.24.07.29.14 (version=SSLv3 cipher=OTHER); Tue, 24 May 2011 07:29:15 -0700 (PDT)
Message-ID: <4DDBC0E9.2010702@gmail.com>
Date: Tue, 24 May 2011 17:30:01 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
References: <4DD89A18.3090105@gmail.com> <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr> <99F2C6CA27936593F2C4F5C5@PST.JCK.COM> <4DDAB342.8080205@gmail.com> <3DA670729719DD82A5233DAE@PST.JCK.COM>
In-Reply-To: <3DA670729719DD82A5233DAE@PST.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, ftpext@ietf.org, Daniel Stenberg <daniel@haxx.se>
Subject: Re: [ftpext] Soliciting comments/reviews on draft-yevstifeyev-ftp-uri-scheme
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2011 14:29:20 -0000

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
> <evnikita2@gmail.com>  wrote:
>
>> 23.05.2011 20:53, John C Klensin wrote:
>>> --On Sunday, May 22, 2011 19:45 +0200 Daniel Stenberg
>>> <daniel@haxx.se>   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
>
>