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

Mykyta Yevstifeyev <evnikita2@gmail.com> Mon, 23 May 2011 16:05 UTC

Return-Path: <evnikita2@gmail.com>
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 4DE4FE07AC; Mon, 23 May 2011 09:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.527
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHrlBm7orWyr; Mon, 23 May 2011 09:05:31 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (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; d=gmail.com; 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; d=gmail.com; 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 10.205.82.197 with SMTP id ad5mr2162011bkc.80.1306156718734; Mon, 23 May 2011 06:18:38 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id u15sm3902861bkf.16.2011.05.23.06.18.36 (version=SSLv3 cipher=OTHER); Mon, 23 May 2011 06:18:37 -0700 (PDT)
Message-ID: <4DDA5EDA.80904@gmail.com>
Date: Mon, 23 May 2011 16:19:22 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Daniel Stenberg <daniel@haxx.se>
References: <4DD89A18.3090105@gmail.com> <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr>
In-Reply-To: <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "uri-review@ietf.org" <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 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 "ftp://example.com/path1//path2". 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