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

Daniel Stenberg <> Mon, 23 May 2011 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4F26E0808; Mon, 23 May 2011 13:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GSMFhAHh+OUn; Mon, 23 May 2011 13:51:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9EE04E085E; Mon, 23 May 2011 13:51:47 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-2) with ESMTP id p4NKpNnN007044; Mon, 23 May 2011 22:51:23 +0200
Date: Mon, 23 May 2011 22:51:23 +0200
From: Daniel Stenberg <>
To: John C Klensin <>
In-Reply-To: <99F2C6CA27936593F2C4F5C5@PST.JCK.COM>
Message-ID: <>
References: <> <> <99F2C6CA27936593F2C4F5C5@PST.JCK.COM>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.8 ( []); Mon, 23 May 2011 22:51:24 +0200 (CEST)
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: Mon, 23 May 2011 20:51:48 -0000

On Mon, 23 May 2011, John C Klensin wrote:

> I think we really need to be careful about your line of reasoning here 
> (whether 1738 is correct or not).

I said it was incomplete or possibly most servers are non-compliant. I tried 
to state facts. Please tell me/us where I'm wrong.

> And, while some systems (as you point out) construe the equivalent of "CWD" 
> (no arguments) as, e.g., "cd $HOMEDIR$", others construe it as "return name 
> of current directory", e.g., a synonym of "pwd".  Having a URL with elements 
> that have semantics that different, depending on what the implementation 
> does, is just looking for trouble.

I'm just pointing out that the way RFC1738 is laid out and the way 
draft-yevstifeyev-ftp-uri-scheme describes things, it is not working on a not 
insignificant amount of existing servers.

I don't have the answer of how to deal with it in a failsafe way but I'm not 
at all convinced that just adding a "method B" into the spec is a very good 
idea without careful thoughts.

> It seems to me that, if we are doing to do an updated FTP URI scheme, we 
> need to either:

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

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

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