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

Mykyta Yevstifeyev <> Tue, 24 May 2011 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2C06E074C; Tue, 24 May 2011 07:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.506
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0ANDzqAq59cd; Tue, 24 May 2011 07:29:19 -0700 (PDT)
Received: from ( []) by (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;; 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;; 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 with SMTP id r28mr3342095bkk.46.1306247357142; Tue, 24 May 2011 07:29:17 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id l1sm4597378bkl.13.2011. (version=SSLv3 cipher=OTHER); Tue, 24 May 2011 07:29:15 -0700 (PDT)
Message-ID: <>
Date: Tue, 24 May 2011 17:30:01 +0300
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: John C Klensin <>
References: <> <> <99F2C6CA27936593F2C4F5C5@PST.JCK.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:,, Daniel Stenberg <>
Subject: Re: [ftpext] Soliciting comments/reviews on draft-yevstifeyev-ftp-uri-scheme
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
> <>  wrote:
>> 23.05.2011 20:53, John C Klensin wrote:
>>> --On Sunday, May 22, 2011 19:45 +0200 Daniel Stenberg
>>> <>   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 

(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 

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