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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.