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

Daniel Stenberg <> Sun, 22 May 2011 17:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFD73E06CF; Sun, 22 May 2011 10:58:38 -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 k0K5ZiJeXvOE; Sun, 22 May 2011 10:58:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CA5DBE06A0; Sun, 22 May 2011 10:58:35 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-2) with ESMTP id p4MHjib2003426; Sun, 22 May 2011 19:45:44 +0200
Date: Sun, 22 May 2011 19:45:44 +0200
From: Daniel Stenberg <>
To: Mykyta Yevstifeyev <>
In-Reply-To: <>
Message-ID: <>
References: <>
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 ( []); Sun, 22 May 2011 19:45:44 +0200 (CEST)
Cc: "" <>,
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: Sun, 22 May 2011 17:58:39 -0000

On Sun, 22 May 2011, Mykyta Yevstifeyev wrote:

> I'm writing to ask people to comment my draft 
> draft-yevstifeyev-ftp-uri-scheme, that may be found here:


I think the document looks fine and basically repeats what RFC1738 says. It 
would be really helpful if it would mention where or how it differs from 

My concern is "The <ftp-path> Part", section 2.2.3, and the problems aren't 
really introduced by you but repeating existing problems in a brand new 
document seems a bit unnecessary.

The original problem I have with this exists already in RFC1738 as it mandates 
a CWD command for each <cwd> part of the path. There are lots of servers out 
in the wild who are configured to not allow this, but yet allows the client to 
do a single CWD to the entire path. That means "CWD dir1/dir2" works while 
"CWD dir1" fails. We can of course just consider such servers as non-compliant 
but clients may still need to consider this (and I know lots of clients only 
do the CWD <full path> approach).

The next problem in the same section is what to do with empty <cwd> parts. As 
in "". RFC1738 acknowledges that the <cwd> parts 
may be empty. It continues to say that each <cwd> should result as an argument 
to CWD. But lots of FTP servers will treat "CWD" with a blank argument similar 
to what unix machines does with 'cd' without a directory: it changes directory 
to a pre-determined location (home directory) that certainly is not at all 
what the client wants for this. A "normal" FTP client will therefore not issue 
a separate CWD for empty parts.

In draft-yevstifeyev-ftp-uri-scheme there's no mention of the fact that <cwd> 
can be empty (which isn't really solving how to deal with them) but there's a 
similar mention that each <cwd> should be passed on to CWD.