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

Daniel Stenberg <daniel@haxx.se> Mon, 23 May 2011 20:51 UTC

Return-Path: <daniel@haxx.se>
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 C4F26E0808; Mon, 23 May 2011 13:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 GSMFhAHh+OUn; Mon, 23 May 2011 13:51:48 -0700 (PDT)
Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE04E085E; Mon, 23 May 2011 13:51:47 -0700 (PDT)
Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (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 (CEST)
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: John C Klensin <john-ietf@jck.com>
In-Reply-To: <99F2C6CA27936593F2C4F5C5@PST.JCK.COM>
Message-ID: <alpine.DEB.2.00.1105232223270.14151@tvnag.unkk.fr>
References: <4DD89A18.3090105@gmail.com> <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr> <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 (giant.haxx.se [80.67.6.50]); Mon, 23 May 2011 22:51:24 +0200 (CEST)
Cc: uri-review@ietf.org, ftpext@ietf.org
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: 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 
do...

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

-- 

  / daniel.haxx.se