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

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

Date: Mon, 23 May 2011 22:51:23 +0200
From: Daniel Stenberg <daniel@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)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Cc: uri-review@ietf.org, ftpext@ietf.org
Subject: Re: [ftpext] Soliciting comments/reviews on draft-yevstifeyev-ftp-uri-scheme
Precedence: list

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

[ftpext] Soliciting comments/reviews on draft-yev… Mykyta Yevstifeyev
Re: [ftpext] Soliciting comments/reviews on draft… Daniel Stenberg
Re: [ftpext] Soliciting comments/reviews on draft… Mykyta Yevstifeyev
Re: [ftpext] Soliciting comments/reviews on draft… John C Klensin
Re: [ftpext] Soliciting comments/reviews on draft… Mykyta Yevstifeyev
Re: [ftpext] Soliciting comments/reviews on draft… Daniel Stenberg
Re: [ftpext] Soliciting comments/reviews on draft… John C Klensin
Re: [ftpext] Soliciting comments/reviews on draft… Mykyta Yevstifeyev
Re: [ftpext] Soliciting comments/reviews on draft… Peter Saint-Andre
Re: [ftpext] Soliciting comments/reviews on draft… Mykyta Yevstifeyev