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

Mykyta Yevstifeyev <> Mon, 23 May 2011 16:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DE4FE07AC; Mon, 23 May 2011 09:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.527
X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PHrlBm7orWyr; Mon, 23 May 2011 09:05:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 26FB8E06D4; Mon, 23 May 2011 09:05:30 -0700 (PDT)
Received: by bwz13 with SMTP id 13so5632162bwz.31 for <multiple recipients>; Mon, 23 May 2011 09:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=n+j7/A9HrhtnuYc5WiOhuxKFrL9Fc0npdT/1mMcmqHE=; b=ayCbIKnrm0lftohUX17zaXt32LwjKlqskvygXQTw8KkjC9Ncgu7D7KsvWnr+mhRH8d o0rJk79jRudEMd/hS+2D/Lssqrkr0nmOwE5BcvZ6VZxnhekydrJ/mq8sAAdxO2Fc19FK /GacRHYcRCaSM3oFW7lvrGsX8QiMtM7s/ZkYc=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cJ076xdSV7PtpUcamj1wn5NuWlRvfC/xHRmo5c7XX59D09ippos67IctAAlheR5JzC 4hKU2A2SvOajy+CAezeWXD4K77Zx2EfiROsNSmTCJp3mxFFKUflcHetI6sb6kc3eqHix O4oL+knOBmaTwVa/31n6xR0fEnLI0bGPh0AZY=
Received: by with SMTP id ad5mr2162011bkc.80.1306156718734; Mon, 23 May 2011 06:18:38 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id u15sm3902861bkf.16.2011. (version=SSLv3 cipher=OTHER); Mon, 23 May 2011 06:18:37 -0700 (PDT)
Message-ID: <>
Date: Mon, 23 May 2011 16:19:22 +0300
From: Mykyta Yevstifeyev <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Daniel Stenberg <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 23 May 2011 16:05:32 -0000

Hello Daniel, and thanks for comments.

See my responses in-line.

22.05.2011 20:45, Daniel Stenberg wrote:
> 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:
> Hi
> 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 RFC1738.
OK, I'll add some words on it (probably in a separate Appendix).
> 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).
I think the following text would be OK:

(the algorithm of handling <ftp-path>):
>  (1a) each of <cwd> parts are consistently supplied as arguments
>       to the CWD (change working directory) FTP command after
>       establishing the FTP connection to the server identified
>       by the <host-port> part of the URI; or
>  (1b) the whole path (the <cwd> parts together) is supplied
>       as an argument to the aforementioned command;
>       [ . . . ]
It addresses your concern, I believe.  Does it look fine?
> 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.
I'll correct this issue as well, mentioning the ability of null <cwd>s 
as well as rules for their handling, proposed by you.

Mykyta Yevstifeyev