From evnikita2@gmail.com  Sat May 21 22:06:56 2011
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 5549BE072F; Sat, 21 May 2011 22:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.522
X-Spam-Level: 
X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IaAOwkfowD-h; Sat, 21 May 2011 22:06:55 -0700 (PDT)
Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by ietfa.amsl.com (Postfix) with ESMTP id D54F5E0618; Sat, 21 May 2011 22:06:54 -0700 (PDT)
Received: by bwz12 with SMTP id 12so7662985bwz.27 for <multiple recipients>; Sat, 21 May 2011 22:06:53 -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 :subject:content-type; bh=HNzONX2Zy+8xhso6DTBRVKCw5An2i0Fxv+CjMW3C/W4=; b=FFLvJKW1dissHx/+XyW9SgeDQufdZOjjPfee6z0INGq75jN6mzxoQmlVdlallhiFcn /ob38ImvBhzWxjBX4zklclqvj36TMpydFAmothh1Gaw08ijYf252oZdf93Qbnso+bUSH 84mdqBnDqe7sm/1bQs9vrl4URqxWzNVFDUcXM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=agwm2/iBed9QeiS4FZN2+OWR3jeIM4Dark4X9Sx2pylVVzNEDLWIyx4ZmF2BX9gnYE HcllnJnVhpbCdLGVZZKSk9Bw/DbkLYCH2Afy783AEJ/S2pN2gEbRV3msjFGIz03v1o3C D26Lwg++BoiFPIPzRCfTbwtfpnakhiMS49EZk=
Received: by 10.205.32.65 with SMTP id sj1mr996514bkb.36.1306040811409; Sat, 21 May 2011 22:06:51 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q25sm3080074bkk.10.2011.05.21.22.06.49 (version=SSLv3 cipher=OTHER); Sat, 21 May 2011 22:06:50 -0700 (PDT)
Message-ID: <4DD89A18.3090105@gmail.com>
Date: Sun, 22 May 2011 08:07:36 +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: "uri-review@ietf.org" <uri-review@ietf.org>, ftpext@ietf.org
Content-Type: multipart/alternative; boundary="------------050606090507070500050804"
Subject: [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: Sun, 22 May 2011 05:06:56 -0000

This is a multi-part message in MIME format.
--------------050606090507070500050804
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello all,

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

http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-00

This document removes uncertainty with the 'ftp' URI scheme, currently 
specified by obsolete RFC 1738 (see my message: 
http://www.ietf.org/mail-archive/web/uri-review/current/msg01442.html).  
RFC 4395 says that 4 weeks review-and-comment period is fine for 
permanent registration, so please feel free to provide your comments on 
my document during these 4 weeks.

{I understand that ftpext list isn't the most appropriate list, but I 
think posting this message there will allow FTP experts read and express 
their thoughts on this document.}

Please, when responding, keep all "To:" and "Cc:" addresses in the message.

Thanks,
Mykyta Yevstifeyev

--------------050606090507070500050804
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <font size="-1"><big>Hello all,<br>
        <br>
        I'm writing to ask people to comment my draft
        draft-yevstifeyev-ftp-uri-scheme, that may be found here:<br>
        <br>
        <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-00">http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-00</a><br>
        <br>
        This document removes uncertainty with the 'ftp' URI scheme,
        currently specified by obsolete RFC 1738 (see my message:
        <a class="moz-txt-link-freetext" href="http://www.ietf.org/mail-archive/web/uri-review/current/msg01442.html">http://www.ietf.org/mail-archive/web/uri-review/current/msg01442.html</a>). 
        RFC 4395 says that 4 weeks review-and-comment period is fine for
        permanent registration, so please feel free to provide your
        comments on my document during these 4 weeks.<br>
        <br>
        {I understand that ftpext list isn't the most appropriate list,
        but I think posting this message there will allow FTP experts
        read and express their thoughts on this document.}<br>
        <br>
        Please, when responding, keep all "To:" and "Cc:" addresses in
        the message.<br>
        <br>
        Thanks,<br>
        Mykyta Yevstifeyev<br>
      </big></font>
  </body>
</html>

--------------050606090507070500050804--

From daniel@haxx.se  Sun May 22 10:58:38 2011
Return-Path: <daniel@haxx.se>
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 DFD73E06CF; Sun, 22 May 2011 10:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 k0K5ZiJeXvOE; Sun, 22 May 2011 10:58:38 -0700 (PDT)
Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by ietfa.amsl.com (Postfix) with ESMTP id CA5DBE06A0; Sun, 22 May 2011 10:58:35 -0700 (PDT)
Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (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 (CEST)
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
In-Reply-To: <4DD89A18.3090105@gmail.com>
Message-ID: <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr>
References: <4DD89A18.3090105@gmail.com>
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 (giant.haxx.se [80.67.6.50]); Sun, 22 May 2011 19:45:44 +0200 (CEST)
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: 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:

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.

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 "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.

-- 

  / daniel.haxx.se

From evnikita2@gmail.com  Mon May 23 09:05:32 2011
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

From john-ietf@jck.com  Mon May 23 10:53:30 2011
Return-Path: <john-ietf@jck.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 ED852E0670; Mon, 23 May 2011 10:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.03
X-Spam-Level: 
X-Spam-Status: No, score=-102.03 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, J_BACKHAIR_11=1, USER_IN_WHITELIST=-100]
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 qejXPyeoeEwh; Mon, 23 May 2011 10:53:30 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id ADB61E0658; Mon, 23 May 2011 10:53:29 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QOZJj-0009Ri-UO; Mon, 23 May 2011 13:53:24 -0400
Date: Mon, 23 May 2011 13:53:22 -0400
From: John C Klensin <john-ietf@jck.com>
To: Daniel Stenberg <daniel@haxx.se>, Mykyta Yevstifeyev <evnikita2@gmail.com>
Message-ID: <99F2C6CA27936593F2C4F5C5@PST.JCK.COM>
In-Reply-To: <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr>
References: <4DD89A18.3090105@gmail.com> <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: 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 17:53:31 -0000

--On Sunday, May 22, 2011 19:45 +0200 Daniel Stenberg
<daniel@haxx.se> 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.
> 
> 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 "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.

Daniel,

I think we really need to be careful about your line of
reasoning here (whether 1738 is correct or not).  CWD was
defined for environments in which not only was the path
separation identifier unknown (take your pick among "/", "\",
".", and ">" at least) but in which there was a real possibility
that 
   CWD a
   CWD b
would have different semantics and lead to a different place
than 
   CWD a<delim>b (e.g., "CWD a/b").

I vaguely recall a discussion about a possible "set path
hierarchy delimiter" command a long time ago; nothing came of it.

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.

By contrast, the semantics of the FTP protocol when no CWD
commands are transmitted (presumably what happens when no
<ftp-path> appears in the URL as specified in 1738) are
perfectly well defined: an FTP server implementation must have a
way to bind a default (or "home" or "startup") directory to the
user/pass [/acct] triple and that is where one ends up and stays.

It seems to me that, if we are doing to do an updated FTP URI
scheme, we need to either:


(1) Clean this mess up and generate a scheme that really
reflects the protocol.   That might well mean deprecating
(although probably retaining for backward-compatibility)
ftp-path in ftp://host/path-element1/path-element2/.../filename
form and moving toward something more like

ftp://host/filename;cwd=path-element1;cwd=path-element2;...;typecode=type;...
(or using query syntax for some or all of those elements).

Cleaning up the mess almost certainly also requires permitting
additional parameters or other mechanisms for ACCT, PASV, and
the sundry extensions that have come along, including those
under consideration by the FTPEXT WG.  Having a WG to extend FTP
(the second one, with several extensions accepted by the earlier
WG) and then approving a URL whose syntax covers only a small
subset of the required commands (and one optional one) from RFC
959 makes no sense to me at all.

As one of many example, this community is on record as not
considering protocols that need authentication mechanisms and
whose only mechanism is cleartext names and passwords acceptable
any more.  We not only have a few mechanisms available for
better FTP authentication, but this draft mentions them in its
Security Considerations section.  But neither of those
mechanisms are accessible via the proposed revised URI.

The spec probably also has to have a serious discussion of what
happens when something is specified that the server rejects.  If
one's model is a URI processor that calls on an FTP client, it
would be useful to figure out and specify what the URI processor
should tell the user when the FTP client gets a 5xx (or worse)
reply back from the FTP server.  I suppose "you lose" could be
an answer but, if we don't think that is acceptable, some
discussion of how one maps from the vocabulary of FTP to the
vocabulary of URIs seems necessary.

I note that this document not only does not contain any
provision for extensions to accommodate additional
commands/parameters (those that have been approved already and
those that might be approved by the FTP WG) either.  That, to
me, is just broken.


(2) Deprecate the FTP URI entirely, name what this document
covers something that conveys
"Restricted-FTP-for-Unix-like-systems:", and move on, hoping
that someone will do a real FTP and FEAT-compatible URI at some
future data.

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.   Mykyta and I have discussed that issue
in other contexts and may ultimately need to agree to disagree,
but I worry about the marginal opportunity costs for the
community of trying to review specs like this one.

regards,
     john



From john-ietf@jck.com  Mon May 23 11:50:39 2011
Return-Path: <john-ietf@jck.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 DAB4CE07EB for <ftpext@ietfa.amsl.com>; Mon, 23 May 2011 11:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.487
X-Spam-Level: 
X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 x9GYxGQRvZs5 for <ftpext@ietfa.amsl.com>; Mon, 23 May 2011 11:50:39 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1F593E07E6 for <ftpext@ietf.org>; Mon, 23 May 2011 11:50:39 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QOaD8-000B7f-Ju for ftpext@ietf.org; Mon, 23 May 2011 14:50:38 -0400
Date: Mon, 23 May 2011 14:50:37 -0400
From: John C Klensin <john-ietf@jck.com>
To: ftpext@ietf.org
Message-ID: <70AD2F646D39D0733A704390@PST.JCK.COM>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: [ftpext] draft-ietf-ftpext2-typeu-00
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 18:50:40 -0000

Hi.

I just got a note indicating that this draft is about to expire.
It was accepted as a WG work item, originally with a "Submit
'FTP Extension for Internationalized Text' as working group
item" date last April and a target of WG Last Call of July.

(1) Does the WG intend to take it up?

(2) If no discussion is needed, when should a WG Last Call be
initiated?

(3) I'm ok with submitting a -01 just to keep it active but, if
anyone has anything substantive that they'd like to see changed
in the draft, now would be a good time to post those comments.

    john



From evnikita2@gmail.com  Mon May 23 12:18:48 2011
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 C4AF9E07DD; Mon, 23 May 2011 12:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.032
X-Spam-Level: 
X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, J_BACKHAIR_11=1, 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 lE4jaEwBLO0F; Mon, 23 May 2011 12:18:47 -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 22524E06F1; Mon, 23 May 2011 12:18:46 -0700 (PDT)
Received: by bwz13 with SMTP id 13so5795202bwz.31 for <multiple recipients>; Mon, 23 May 2011 12:18:46 -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=IqV4kzCiOUu2hQyG/cC8uTUHU/hhZZRKr8JLE67QCuY=; b=l9WmL394bBg0roaJ4eQrmNcGbecAw105w0mCs8FrfXjbMOABcyl/OWoCnMm6meghfj FlkgKHwdtCMYsqXR1dZlntMl+iRbt7NPTWmdq5cGIMde2jgGCObxjOs5S8V04MYDPZZr /XVFYIqG8jK1QmqzcBJK6zCUouJZqudEAiXqU=
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=it7EDdIWqNIXqqwcxKUe562qHVlGwVIKD0730fMt7GyrI7ujre3g69woYmZYD81PTm 7AidToEZeCG4OQVJTbDJgHyXg5z2GiEkrDqSEUz/YgFdH16kaQMKh3fm0pGnMUWgIt5L AoWIfwQLpQ78Y7WQgkGDtiSHJKEAhfSRNH3a0=
Received: by 10.204.76.19 with SMTP id a19mr2444598bkk.110.1306178325884; Mon, 23 May 2011 12:18:45 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id d25sm4100114bkd.17.2011.05.23.12.18.43 (version=SSLv3 cipher=OTHER); Mon, 23 May 2011 12:18:44 -0700 (PDT)
Message-ID: <4DDAB342.8080205@gmail.com>
Date: Mon, 23 May 2011 22:19:30 +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: John C Klensin <john-ietf@jck.com>
References: <4DD89A18.3090105@gmail.com> <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr> <99F2C6CA27936593F2C4F5C5@PST.JCK.COM>
In-Reply-To: <99F2C6CA27936593F2C4F5C5@PST.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, ftpext@ietf.org, Daniel Stenberg <daniel@haxx.se>
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 19:18:48 -0000

23.05.2011 20:53, John C Klensin wrote:
> --On Sunday, May 22, 2011 19:45 +0200 Daniel Stenberg
> <daniel@haxx.se>  wrote:
> [ . . . ]
>
> Daniel,
>
> I think we really need to be careful about your line of
> reasoning here (whether 1738 is correct or not).  CWD was
> defined for environments in which not only was the path
> separation identifier unknown (take your pick among "/", "\",
> ".", and">" at least) but in which there was a real possibility
> that
>     CWD a
>     CWD b
> would have different semantics and lead to a different place
> than
>     CWD a<delim>b (e.g., "CWD a/b").
>
> I vaguely recall a discussion about a possible "set path
> hierarchy delimiter" command a long time ago; nothing came of it.
>
> 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.
With respect to this issue, I think mentioning that null <cwd>s must 
cause no commands generated and dent out is OK and suits to the common 
sense.  Defining such parts causing sending "CWD" with no arguments 
really looks wrong; so I think specifying "noting to do if <cwd> is 
null" should be fine.
> By contrast, the semantics of the FTP protocol when no CWD
> commands are transmitted (presumably what happens when no
> <ftp-path>  appears in the URL as specified in 1738) are
> perfectly well defined: an FTP server implementation must have a
> way to bind a default (or "home" or "startup") directory to the
> user/pass [/acct] triple and that is where one ends up and stays.
>
> It seems to me that, if we are doing to do an updated FTP URI
> scheme, we need to either:
>
>
> (1) Clean this mess up and generate a scheme that really
> reflects the protocol.   That might well mean deprecating
> (although probably retaining for backward-compatibility)
> ftp-path in ftp://host/path-element1/path-element2/.../filename
> form and moving toward something more like
>
> ftp://host/filename;cwd=path-element1;cwd=path-element2;...;typecode=type;...
> (or using query syntax for some or all of those elements).
>
> Cleaning up the mess almost certainly also requires permitting
> additional parameters or other mechanisms for ACCT, PASV, and
> the sundry extensions that have come along, including those
> under consideration by the FTPEXT WG.  Having a WG to extend FTP
> (the second one, with several extensions accepted by the earlier
> WG) and then approving a URL whose syntax covers only a small
> subset of the required commands (and one optional one) from RFC
> 959 makes no sense to me at all.
Complete re-specifying of 'ftp' URI scheme seems quite interesting; yet, 
it's too radical.  The scheme in its existing view has been used in the 
Internet for years.  I don't think folks will be encouraged to change 
their apps to suit new syntax/semantics and will continue using the old 
one, even if it is formally deprecated.  RFC 1738 was written at the end 
of 1994, RFC 1630 - in the middle.  Paul's draft, as I remember, was 
written at the end of 2005; these three documents make no change to the 
'ftp' scheme (maybe 1630 isn't a good example of this, but...).  So, I 
should repeat that even though making up a completely new spec of 'ftp' 
URI is a good deed, it isn't really worth the energy which would be put 
in it since it is very likely to get ignored.
> As one of many example, this community is on record as not
> considering protocols that need authentication mechanisms and
> whose only mechanism is cleartext names and passwords acceptable
> any more.  We not only have a few mechanisms available for
> better FTP authentication, but this draft mentions them in its
> Security Considerations section.  But neither of those
> mechanisms are accessible via the proposed revised URI.
Indeed.  But the current situation is left "as is" is for historical 
purposes as well.  If we mention, eg. user-pass part of 'ftp' URI should 
have an optional "auth-part" of ";AUTH=<auth-type>" (as in many URI 
schemes, such as 'pop' or 'imap'), define a set of initial tokens for 
<auth-types>, establish a registry for them, describe everything related 
to this and then pass the specification to implementators, they will 
probably ignore this new possibility and will continue to make the FTP 
clients compatible with "user:pass" userinfo part, not the new one.  So 
my opinion is just the same as above.
> The spec probably also has to have a serious discussion of what
> happens when something is specified that the server rejects.  If
> one's model is a URI processor that calls on an FTP client, it
> would be useful to figure out and specify what the URI processor
> should tell the user when the FTP client gets a 5xx (or worse)
> reply back from the FTP server.  I suppose "you lose" could be
> an answer but, if we don't think that is acceptable, some
> discussion of how one maps from the vocabulary of FTP to the
> vocabulary of URIs seems necessary.
On this I can't disagree; so this issue needs wider community discussion.
> I note that this document not only does not contain any
> provision for extensions to accommodate additional
> commands/parameters (those that have been approved already and
> those that might be approved by the FTP WG) either.  That, to
> me, is just broken.
See my response #2, it concerns this as well.
>
> (2) Deprecate the FTP URI entirely, name what this document
> covers something that conveys
> "Restricted-FTP-for-Unix-like-systems:", and move on, hoping
> that someone will do a real FTP and FEAT-compatible URI at some
> future data.
Considered your first proposal, would be a good idea, but considering it 
separately it's probably a bad one.  The 'ftp' URIs in their curent form 
are widely used; so deprecating it won't reault in anything good, in my 
opinion.  I think such redical actions won't be accepted by the 
community; so "updating old spec. correcting minor mistakes" seems to be 
a good approach for now.

Mykyta Yevstifeyev
> 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.   Mykyta and I have discussed that issue
> in other contexts and may ultimately need to agree to disagree,
> but I worry about the marginal opportunity costs for the
> community of trying to review specs like this one.
>
> regards,
>       john
>
>
>


From daniel@haxx.se  Mon May 23 13:51:48 2011
Return-Path: <daniel@haxx.se>
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 C4F26E0808; Mon, 23 May 2011 13:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 GSMFhAHh+OUn; Mon, 23 May 2011 13:51:48 -0700 (PDT)
Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE04E085E; Mon, 23 May 2011 13:51:47 -0700 (PDT)
Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id p4NKpNnN007044;  Mon, 23 May 2011 22:51:23 +0200
Date: Mon, 23 May 2011 22:51:23 +0200 (CEST)
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.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)
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 (giant.haxx.se [80.67.6.50]); Mon, 23 May 2011 22:51:24 +0200 (CEST)
Cc: 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 20:51:48 -0000

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

From john-ietf@jck.com  Mon May 23 20:04:01 2011
Return-Path: <john-ietf@jck.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 C5AFDE06E9; Mon, 23 May 2011 20:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.506
X-Spam-Level: 
X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 BDkgW6k5bLym; Mon, 23 May 2011 20:04:01 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 99389E06B2; Mon, 23 May 2011 20:04:00 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QOhuS-000Nm1-Nm; Mon, 23 May 2011 23:03:53 -0400
Date: Mon, 23 May 2011 23:03:51 -0400
From: John C Klensin <john-ietf@jck.com>
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
Message-ID: <3DA670729719DD82A5233DAE@PST.JCK.COM>
In-Reply-To: <4DDAB342.8080205@gmail.com>
References: <4DD89A18.3090105@gmail.com> <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr> <99F2C6CA27936593F2C4F5C5@PST.JCK.COM> <4DDAB342.8080205@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: uri-review@ietf.org, ftpext@ietf.org, Daniel Stenberg <daniel@haxx.se>
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: Tue, 24 May 2011 03:04:01 -0000

--On Monday, May 23, 2011 22:19 +0300 Mykyta Yevstifeyev
<evnikita2@gmail.com> wrote:

> 23.05.2011 20:53, John C Klensin wrote:
>> --On Sunday, May 22, 2011 19:45 +0200 Daniel Stenberg
>> <daniel@haxx.se>  wrote:
>> [ . . . ]
>> 
>> Daniel,
>> 
>> I think we really need to be careful about your line of
>> reasoning here (whether 1738 is correct or not).  CWD was
>> defined for environments in which not only was the path
>> separation identifier unknown (take your pick among "/", "\",
>...

> Complete re-specifying of 'ftp' URI scheme seems quite
> interesting; yet, it's too radical.  The scheme in its
> existing view has been used in the Internet for years.  I
> don't think folks will be encouraged to change their apps to
> suit new syntax/semantics and will continue using the old one,
> even if it is formally deprecated.  RFC 1738 was written at
>...

Actually, modulo some very small differences in syntax and
semantics, the concept of a one-line FTP invocation goes back at
least to TENEX.  That one-line approach has been more or less
   ftp <host> <path>
and, modulo syntactic sugar and the user and password
identifiers (which, as you point out, aren't used very often
with the URI form), the URI just reflects that model.

But this is exactly where we have a philosophical difference.  I
hope I've got this right, but it seems to me:

-- You say that if we make any substantive changes, then no one
will pay any attention to what we say and will keep using what
was specified in 1738.

-- I respond by saying, "Ok, if that is the case, then updating/
replacing the definition in 1738 has no value other than dealing
with the half-obsolete status of 1738 itself.  And dealing with
that doesn't have nearly enough value to justify the effort of
producing a new document and getting it right."

-- Daniel says that a lot of implementations don't do what 1738
says anyway, so repeating what it says is silly.  (I hope that
interpretation isn't too far off the mark.)

-- I respond by saying "Ok, if that is the case, we have a mess
on our hands and it is irresponsible to produce a new spec that
does not clean up the mess.    So, either no new spec or a
cleanup.

-- If you respond to that by saying that you are convinced that
no one would pay any attention to a cleaned up and complete
specification either, then my answer would be that we are
finished: there is no value in spending any time on a new
specification that we are convinced, a priori, that no one is
going to pay any attention to.

And that is where we probably agree to disagree, since neither
of us is likely to convince the other.

Daniel wrote...

> 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?

Up to this point at least, I think we are 100% in agreement.

> Isn't there a middle-ground that at
> least maintains most of what RFC1738 says but that
> clarifies/corrects the biggest mistakes?

Probably.  But then we need to get consensus about what is a
"biggest mistake" and, in particular, whether some of the
interpretations of 1738 which you describe are the desired
behavior or just broken.  As one trivial example, Mykyta and I
seem to think that interpreting "ftp://servername.example.com/"
as an instruction to send "CWD" without an argument is broken;
the implementations you cite seem to differ.   So there isn't
100% agreement on that point.

So, even if we are trying to just "maintain[s] most of what
RFC1738 says but that clarifies/corrects the biggest mistakes",
we have issues with getting agreement, not just copying out and
editing some text.   That, in turn, makes the "clarify and
correct" job less different from "updating" than might be
assumed.

> If we *are* updating the FTP URI scheme, then surely we have
> more work to do...

Indeed.   And, despite my comments above, I'm painfully aware
that figuring out how to accommodate required commands that are
not in the 1738 definition, to think about paths and parameters,
and to allow to extension for new commands without having to
write a new definition of the URI each time is much more work
than trying to copy and clarify the 1738 material.    While I'd
be opposed to it, I can see the sense in a "copy and clarify but
don't specify anything new or different" model, especially if we
hope that an update and revision would come along in the future.

>> 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.

Concur.  And, fwiw, it is procedurally almost impossible because
the requirements for Proposed Standard include the "no known
technical omissions" rule.  An "old known mistake" is certainly
a known technical omission with regard to that rule.  While the
IESG can waive the rule, concluding that a new spec is useful
and necessary enough to justify doing so when there is an
existing published spec would seem to me to require a trip
beyond the plausible.

    john


From iljitsch@muada.com  Tue May 24 02:30:56 2011
Return-Path: <iljitsch@muada.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 97C51E06D0 for <ftpext@ietfa.amsl.com>; Tue, 24 May 2011 02:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.193
X-Spam-Level: 
X-Spam-Status: No, score=-102.193 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 AarEtvNGhXaf for <ftpext@ietfa.amsl.com>; Tue, 24 May 2011 02:30:56 -0700 (PDT)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id BC163E0691 for <ftpext@ietf.org>; Tue, 24 May 2011 02:30:55 -0700 (PDT)
Received: from [IPv6:2001:720:410:100f:223:32ff:fec4:ba94] ([IPv6:2001:720:410:100f:223:32ff:fec4:ba94]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p4O9VsHT001703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ftpext@ietf.org>; Tue, 24 May 2011 11:31:55 +0200 (CEST) (envelope-from iljitsch@muada.com)
From: Iljitsch van Beijnum <iljitsch@muada.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 24 May 2011 11:30:51 +0200
References: <20110520224813.2156.61466.idtracker@ietfa.amsl.com>
To: ftpext@ietf.org
Message-Id: <F40CA232-5C1B-4632-8F4C-5AD6C156903C@muada.com>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [ftpext] Fwd: [BEHAVE] Last Call: <draft-ietf-behave-ftp64-10.txt> (An FTP ALG for	IPv6-to-IPv4 translation) to Proposed Standard
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: Tue, 24 May 2011 09:30:56 -0000

FYI: the BEHAVE FTP64 draft is now in IETF last call.

Iljitsch

Begin forwarded message:

> From: The IESG <iesg-secretary@ietf.org>
> Date: 21 mei 2011 0:48:13 GMT+02:00
> To: IETF-Announce <ietf-announce@ietf.org>
> Cc: behave@ietf.org
> Subject: [BEHAVE] Last Call: <draft-ietf-behave-ftp64-10.txt> (An FTP =
ALG for	IPv6-to-IPv4 translation) to Proposed Standard
> Reply-To: ietf@ietf.org
>=20
>=20
> The IESG has received a request from the Behavior Engineering for
> Hindrance Avoidance WG (behave) to consider the following document:
> - 'An FTP ALG for IPv6-to-IPv4 translation'
>  <draft-ietf-behave-ftp64-10.txt> as a Proposed Standard
>=20
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-06-03. Exceptionally, comments may =
be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>=20
> Abstract
>=20
>=20
>   The File Transfer Protocol (FTP) has a very long history, and =
despite
>   the fact that today, other options exist to perform file transfers,
>   FTP is still in common use.  As such, it is important that in the
>   situation where some client computers only have IPv6 connectivity
>   while many servers are still IPv4-only and IPv6-to-IPv4 translators
>   are used to bridge that gap, FTP is made to work through these
>   translators as best it can.
>=20
>   FTP has an active and a passive mode, both as original commands that
>   are IPv4-specific, and as extended, IP version agnostic commands.
>   The only FTP mode that works without changes through an IPv6-to-IPv4
>   translator is extended passive.  However, many existing FTP servers
>   do not support this mode, and some clients do not ask for it.  This
>   document specifies a middlebox that may solve this mismatch.
>=20
>=20
>=20
>=20
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/
>=20
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/
>=20
>=20
> The following IPR Declarations may be related to this I-D:
>=20
>   http://datatracker.ietf.org/ipr/1322/
>=20
> IPR has been disclosed and announced to the mailing list,
> =
https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document=
_sea
> rch=3Ddraft-ietf-behave-ftp64
> and there has been no subsequent WG discussion about this IPR =
disclosure.
>=20
>=20
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave


From evnikita2@gmail.com  Tue May 24 07:29:19 2011
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 E2C06E074C; Tue, 24 May 2011 07:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.506
X-Spam-Level: 
X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093,  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 0ANDzqAq59cd; Tue, 24 May 2011 07:29:19 -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 5285DE06AF; Tue, 24 May 2011 07:29:18 -0700 (PDT)
Received: by bwz13 with SMTP id 13so6577186bwz.31 for <multiple recipients>; Tue, 24 May 2011 07:29:17 -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=fGpTY7aiPt+FHdSz1g/NHy9Q5Af9501UxYZoYHqlMq0=; b=bULnDzhEmvhqlOIi56o4J5ME7wplz2zLnU0pb3y+FrR6j9rsHDDMfkHxi83JMJ0IBI eMxMrQLzfmCFMKEuNGMmECd0AOL7/vdBQIKSwTObPVp948/MuvvhOE3U/Uvfa8ePSaZU RF5XK69Rkxfak2TTz/AMefNBuJ6q8u6bG+BRc=
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=PUlT7ZrDqZ4dE6Y43W+uqowuLuRS1a92vBemRdGYWwDrNz1+GVdn8gL++Z4T1QdfIE n8PRxqU0MkDSpgxGv9kxt0kea5q2HY27Bwdr8o3nN7OXKVlIdnkCiRO5vLmhGgBrcCyw /PS0HzAezq1qtzU7SZa1U+oieh6Wi1nDOTU28=
Received: by 10.204.80.28 with SMTP id r28mr3342095bkk.46.1306247357142; Tue, 24 May 2011 07:29:17 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id l1sm4597378bkl.13.2011.05.24.07.29.14 (version=SSLv3 cipher=OTHER); Tue, 24 May 2011 07:29:15 -0700 (PDT)
Message-ID: <4DDBC0E9.2010702@gmail.com>
Date: Tue, 24 May 2011 17:30:01 +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: John C Klensin <john-ietf@jck.com>
References: <4DD89A18.3090105@gmail.com> <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr> <99F2C6CA27936593F2C4F5C5@PST.JCK.COM> <4DDAB342.8080205@gmail.com> <3DA670729719DD82A5233DAE@PST.JCK.COM>
In-Reply-To: <3DA670729719DD82A5233DAE@PST.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, ftpext@ietf.org, Daniel Stenberg <daniel@haxx.se>
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: Tue, 24 May 2011 14:29:20 -0000

Hi John, Daniel, all,

Thanks for your responses once more.  See my comments in-line.

24.05.2011 6:03, John C Klensin wrote:
>
> --On Monday, May 23, 2011 22:19 +0300 Mykyta Yevstifeyev
> <evnikita2@gmail.com>  wrote:
>
>> 23.05.2011 20:53, John C Klensin wrote:
>>> --On Sunday, May 22, 2011 19:45 +0200 Daniel Stenberg
>>> <daniel@haxx.se>   wrote:
>>> [ . . . ]
>>>
>>> Daniel,
>>>
>>> I think we really need to be careful about your line of
>>> reasoning here (whether 1738 is correct or not).  CWD was
>>> defined for environments in which not only was the path
>>> separation identifier unknown (take your pick among "/", "\",
>> ...
>> Complete re-specifying of 'ftp' URI scheme seems quite
>> interesting; yet, it's too radical.  The scheme in its
>> existing view has been used in the Internet for years.  I
>> don't think folks will be encouraged to change their apps to
>> suit new syntax/semantics and will continue using the old one,
>> even if it is formally deprecated.  RFC 1738 was written at
>> ...
> Actually, modulo some very small differences in syntax and
> semantics, the concept of a one-line FTP invocation goes back at
> least to TENEX.  That one-line approach has been more or less
>     ftp<host>  <path>
> and, modulo syntactic sugar and the user and password
> identifiers (which, as you point out, aren't used very often
> with the URI form), the URI just reflects that model.
>
> But this is exactly where we have a philosophical difference.  I
> hope I've got this right, but it seems to me:
>
> -- You say that if we make any substantive changes, then no one
> will pay any attention to what we say and will keep using what
> was specified in 1738.
Yes, I've said this.
> -- I respond by saying, "Ok, if that is the case, then updating/
> replacing the definition in 1738 has no value other than dealing
> with the half-obsolete status of 1738 itself.  And dealing with
> that doesn't have nearly enough value to justify the effort of
> producing a new document and getting it right."
See below.
> -- Daniel says that a lot of implementations don't do what 1738
> says anyway, so repeating what it says is silly.  (I hope that
> interpretation isn't too far off the mark.)
Agreed with this as well.
> -- I respond by saying "Ok, if that is the case, we have a mess
> on our hands and it is irresponsible to produce a new spec that
> does not clean up the mess.    So, either no new spec or a
> cleanup.
Also see below.
> -- If you respond to that by saying that you are convinced that
> no one would pay any attention to a cleaned up and complete
> specification either, then my answer would be that we are
> finished: there is no value in spending any time on a new
> specification that we are convinced, a priori, that no one is
> going to pay any attention to.
I didn't want to say that no one would care attention to an updated 
specification if it was published.  Some would probably do; and the new 
'ftp' URI scheme might be Ok enough to abandon the old one.  However I 
do think it makes sense to document the 'ftp' URI *as it is currently 
used* on the Standards Track.  What I really deem fine to clean up the 
mess, as you say, is:

(1) specifying the scheme borrowing the 1738 basis on Standards Track as 
it is currently used correcting major and minor flaws/uncertainties and 
allowing 1738 to approach its "obsolete" status;

(2) making up the Experimental document proposing a new, experimental 
form of the 'ftp' URI scheme, cleaning up most of the mess in existing 
specification;

(3) observing whether people are satisfied by new proposed syntax or are 
Ok with the old one;

(4) deciding whether to change the official spec using the new form or 
leaving the old one.

This, I think, will allow to propose a new form without having made 
radical changes to Standards Track, but see if it is really fine.  So I 
should agree that updating (in fact, re-specifying) 'ftp' URI scheme is 
certainly necessary, but it should be done in other way, as I proposed 
above.

Now for Daniel's comments.
> And that is where we probably agree to disagree, since neither
> of us is likely to convince the other.
>
> Daniel wrote...
>
>> 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?
> Up to this point at least, I think we are 100% in agreement.
I agree as well.
>> Isn't there a middle-ground that at
>> least maintains most of what RFC1738 says but that
>> clarifies/corrects the biggest mistakes?
> Probably.  But then we need to get consensus about what is a
> "biggest mistake" and, in particular, whether some of the
> interpretations of 1738 which you describe are the desired
> behavior or just broken.  As one trivial example, Mykyta and I
> seem to think that interpreting "ftp://servername.example.com/"
> as an instruction to send "CWD" without an argument is broken;
> the implementations you cite seem to differ.   So there isn't
> 100% agreement on that point.
>
> So, even if we are trying to just "maintain[s] most of what
> RFC1738 says but that clarifies/corrects the biggest mistakes",
> we have issues with getting agreement, not just copying out and
> editing some text.   That, in turn, makes the "clarify and
> correct" job less different from "updating" than might be
> assumed.
My personal opinion is that this way is the most satisfactory, following 
the golden mean principle.  And I think it will be possible to reach an 
agreement on the necessary changes to 1738 specification.
>> If we *are* updating the FTP URI scheme, then surely we have
>> more work to do...
> Indeed.   And, despite my comments above, I'm painfully aware
> that figuring out how to accommodate required commands that are
> not in the 1738 definition, to think about paths and parameters,
> and to allow to extension for new commands without having to
> write a new definition of the URI each time is much more work
> than trying to copy and clarify the 1738 material.    While I'd
> be opposed to it, I can see the sense in a "copy and clarify but
> don't specify anything new or different" model,
I'm really glad to hear this :-)  That's what my draft tries to do.  As 
for the expectations for more radical changes, I think they will really 
appear soon (see my comment #1).
>   especially if we
> hope that an update and revision would come along in the future.
>
>>> 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.
> Concur.  And, fwiw, it is procedurally almost impossible because
> the requirements for Proposed Standard include the "no known
> technical omissions" rule.  An "old known mistake" is certainly
> a known technical omission with regard to that rule.  While the
> IESG can waive the rule, concluding that a new spec is useful
> and necessary enough to justify doing so when there is an
> existing published spec would seem to me to require a trip
> beyond the plausible.
By the way, another requirement for PS is (citing 2026):

>     A Proposed Standard specification is generally stable, has resolved
>     known design choices, [ . . . ]
and, thus, changing the spec radically will certainly fail to suit this 
rule.  But, the way I proposed at the beginning of the message is 
certainly fine to allow the new ftp URI scheme syntax receive these 
"design choices".

So, as far as I can see, we all have reached the following consensus:

(1) repeating 1738 is certainly a bad idea;

(2) repeating 1738 and correcting all known major and minor issues 
should be fine;

(3a) 'ftp' URI scheme really needs more fundamental work; but

(3b) /am not sure if all agree/ it should be done in other way.

Mykyta Yevstifeyev

>      john
>
>


From stpeter@stpeter.im  Tue May 24 09:09:35 2011
Return-Path: <stpeter@stpeter.im>
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 72D92E0777; Tue, 24 May 2011 09:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.614
X-Spam-Level: 
X-Spam-Status: No, score=-102.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 0RQKvJ6Pk85V; Tue, 24 May 2011 09:09:34 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A09C3E06A3; Tue, 24 May 2011 09:09:34 -0700 (PDT)
Received: from dhcp-64-101-72-158.cisco.com (dhcp-64-101-72-158.cisco.com [64.101.72.158]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 42FF840046; Tue, 24 May 2011 10:09:33 -0600 (MDT)
Message-ID: <4DDBD83D.6070208@stpeter.im>
Date: Tue, 24 May 2011 10:09:33 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <4DD89A18.3090105@gmail.com>	<alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr>	<99F2C6CA27936593F2C4F5C5@PST.JCK.COM> <4DDAB342.8080205@gmail.com>	<3DA670729719DD82A5233DAE@PST.JCK.COM> <4DDBC0E9.2010702@gmail.com>
In-Reply-To: <4DDBC0E9.2010702@gmail.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030005030202030009040306"
Cc: uri-review@ietf.org, ftpext@ietf.org, Daniel Stenberg <daniel@haxx.se>
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: Tue, 24 May 2011 16:09:35 -0000

This is a cryptographically signed message in MIME format.

--------------ms030005030202030009040306
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 5/24/11 8:30 AM, Mykyta Yevstifeyev wrote:

> (2) making up the Experimental document proposing a new, experimental
> form of the 'ftp' URI scheme, cleaning up most of the mess in existing
> specification;

What is the scope of the experiment, how will the success of the
experiment be determined, and what will happen if it is a success?

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms030005030202030009040306
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUy
NDE2MDkzM1owIwYJKoZIhvcNAQkEMRYEFMW/46sWt5gmq8K8hyovItOy6QOeMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQAyDn+OeqGaBrDupnvjGmNkBM29uQfXKXjCOf41guZLRvkTkhANQ0p6chsR
ZAQlmDg0P2olHivElzQOsf+sF5GKgQBdN+asVfTINWR0Mbk7gWGKKVborVFmU5d4BrbOSAz5
YHvv3FS8E5e1p50xv5gDIU50bekJEI9VdL96qbyn1lNX/4WYrV95ofc6aLXHNNdo1kt6gw4d
uPLD03ndsAjZtPQWFyEziBDPBC9ZfeW4a578ieXvApyIgdNsW6jTdlsqW/LmuSSiWs2NHRok
LDV4ryzq4nLlRexDWX2VhS0i+RP0KUgstudYca7ky1JI974AOlkVsoHJDG0eqo7GEPyoAAAA
AAAA
--------------ms030005030202030009040306--

From evnikita2@gmail.com  Wed May 25 01:21:20 2011
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 EA370E06E1; Wed, 25 May 2011 01:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 Eiefx2wliRb3; Wed, 25 May 2011 01:21:17 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEBFE06D5; Wed, 25 May 2011 01:21:16 -0700 (PDT)
Received: by gyf3 with SMTP id 3so3730584gyf.31 for <multiple recipients>; Wed, 25 May 2011 01:21:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HvvLi+lygi154OsB7lT+bkt/Wyz4NS/JtoUxdrG4XpY=; b=SCc+LDayvLZOT/3lMn8gv3SEsEUazCp1z+3mLy6UKzUiPnjUNTwS5CuJVZSIDe01aw AikJhBGri2iRtC44LKh70gIrcyz3iLGrsuwJmkxvNA8jzHyXIbd69GQJ54qVCzcq60Zn oBsYoOeqM19pzBDaD49c2Ga7mmTzqrQXXAal8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mW7yKAOxwftom8hhh2bL/u+FV+Rg94ATPKh/wnVxtAnRnLp0SH5tl+V8Ki8mh96P5X TrEz8+3qGR+q923XWU2e1HuAyqO7nLlGrL+sMPLHkLF06bt0vGObJavidmaiLyzkj3y2 vlbLTFvnpaJ/5cW96WdvDNedDvsDMLukABEwE=
MIME-Version: 1.0
Received: by 10.150.14.13 with SMTP id 13mr5273485ybn.438.1306311676499; Wed, 25 May 2011 01:21:16 -0700 (PDT)
Received: by 10.150.148.4 with HTTP; Wed, 25 May 2011 01:21:16 -0700 (PDT)
In-Reply-To: <4DDBD83D.6070208@stpeter.im>
References: <4DD89A18.3090105@gmail.com> <alpine.DEB.2.00.1105221515140.5566@tvnag.unkk.fr> <99F2C6CA27936593F2C4F5C5@PST.JCK.COM> <4DDAB342.8080205@gmail.com> <3DA670729719DD82A5233DAE@PST.JCK.COM> <4DDBC0E9.2010702@gmail.com> <4DDBD83D.6070208@stpeter.im>
Date: Wed, 25 May 2011 11:21:16 +0300
Message-ID: <BANLkTimX61dQhVY+XA=BZGMwW0TOYbkKXw@mail.gmail.com>
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1
Cc: uri-review@ietf.org, ftpext@ietf.org, Daniel Stenberg <daniel@haxx.se>
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: Wed, 25 May 2011 08:21:21 -0000

2011/5/24, Peter Saint-Andre <stpeter@stpeter.im>:
> On 5/24/11 8:30 AM, Mykyta Yevstifeyev wrote:
>
>> (2) making up the Experimental document proposing a new, experimental
>> form of the 'ftp' URI scheme, cleaning up most of the mess in existing
>> specification;
>
> What is the scope of the experiment, how will the success of the
> experiment be determined, and what will happen if it is a success?
>
I hoped I had explained this.  The success of such experiment will be
determined if the new experimental form of the scheme gets widely
implemented and satisfies people enough to replace the existing one
(this is also the answer to "what will happen if it is a success").

I don't clearly understand what you mean under the "scope", but I
suppose I am right saying that the scope is general; but the
experiment is intended to concern application implementators mostly.

Mykyta Yevstifeyev
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>
>

From evnikita2@gmail.com  Fri May 27 01:31:18 2011
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 0D77AE07B1; Fri, 27 May 2011 01:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.511
X-Spam-Level: 
X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MdRt2d0Va3oe; Fri, 27 May 2011 01:31:17 -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 F1B9FE0761; Fri, 27 May 2011 01:31:16 -0700 (PDT)
Received: by bwz13 with SMTP id 13so1237202bwz.31 for <multiple recipients>; Fri, 27 May 2011 01:31:15 -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:content-type; bh=Je5ly40n/DwjHPcarzVb1GL7k8lH/yl2LGkzDO99Ij4=; b=S5bvpyXcyotJvRCo0tXOneQufDKCt/ZyEgPSjtcv4yPoTVXCtyEv9HXjWeFu6JvCJk AF9sjgzsOiSXEv5oVV2cznV0yViQFEYXzIWlU3JjsC7hELL6Jg5gtbyGqNb76KCx9u5P AB/NGM3/pic1/S3NYNmIlmFeBuINK0Pv4ERW8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type; b=sLDIzIFEjxAgoUi1Zpp3zCI3mLY8WQR75ybbVSR0YtdO7RPiQvKqD1zOCSlrTZZDeV WP+HPElv+fs0zmYO0ghTWB8kEf2eQk3SHGxauHSkDl3HAEUf1OqTtZuY21FRGOnZ7rFC 3xhR9IK8ZOd/V1MKI0fF+VavDqsRPixihghrE=
Received: by 10.204.141.14 with SMTP id k14mr1528148bku.37.1306485074041; Fri, 27 May 2011 01:31:14 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 16sm1083583bkm.14.2011.05.27.01.31.11 (version=SSLv3 cipher=OTHER); Fri, 27 May 2011 01:31:13 -0700 (PDT)
Message-ID: <4DDF617E.9050503@gmail.com>
Date: Fri, 27 May 2011 11:31:58 +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: ftpext@ietf.org, "uri-review@ietf.org" <uri-review@ietf.org>
Content-Type: multipart/alternative; boundary="------------070608060209000601090705"
Subject: [ftpext] draft-yevstifeyev-ftp-uri-scheme-01 posted
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: Fri, 27 May 2011 08:31:18 -0000

This is a multi-part message in MIME format.
--------------070608060209000601090705
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,

I've just posted draft-yevstifeyev-ftp-uri-scheme-01; please find it here:

http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-01

The new revision tries to address comments from Daniel as well as from 
John.  It also incorporates various editorial improvements.  The diffs 
can be found here: 
http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-scheme-01.  
Please, if you have any comments and suggestions, feel free to express them.

Considering the necessity of wide community involvement, I'd like to ask 
to adopt this draft as the ftpext2 WG item.  I am copying this message 
to WG chairs to let them know and decide if it is OK.

All the best,
Mykyta Yevstifeyev

> A new version of I-D, draft-yevstifeyev-ftp-uri-scheme-01.txt has been successfully submitted by Mykyta Yevstifeyev and posted to the IETF repository.
>
> Filename:	 draft-yevstifeyev-ftp-uri-scheme
> Revision:	 01
> Title:		 The&#39;ftp&#39; URI Scheme
> Creation date:	 2011-05-27
> WG ID:		 Individual Submission
> Number of pages: 12


--------------070608060209000601090705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    <font size="-1"><big>Hi all,<br>
        <br>
        I've just posted draft-yevstifeyev-ftp-uri-scheme-01; please
        find it here:<br>
        <br>
        <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-01">http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme-01</a><br>
        <br>
        The new revision tries to address comments from Daniel as well
        as from John.  It also incorporates various editorial
        improvements.  The diffs can be found here:
        <a class="moz-txt-link-freetext" href="http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-scheme-01">http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-ftp-uri-scheme-01</a>. 
        Please, if you have any comments and suggestions, feel free to
        express them.<br>
        <br>
        Considering the necessity of wide community involvement, I'd
        like to ask to adopt this draft as the ftpext2 WG item.  I am
        copying this message to WG chairs to let them know and decide if
        it is OK. <br>
        <br>
        All the best,<br>
        Mykyta Yevstifeyev<br>
        <br>
        <blockquote type="cite">
          <pre wrap="">A new version of I-D, draft-yevstifeyev-ftp-uri-scheme-01.txt has been successfully submitted by Mykyta Yevstifeyev and posted to the IETF repository.

Filename:	 draft-yevstifeyev-ftp-uri-scheme
Revision:	 01
Title:		 The &amp;#39;ftp&amp;#39; URI Scheme
Creation date:	 2011-05-27
WG ID:		 Individual Submission
Number of pages: 12
</pre>
        </blockquote>
        <br>
      </big></font>
  </body>
</html>

--------------070608060209000601090705--

From presnick@qualcomm.com  Mon May 30 10:05:07 2011
Return-Path: <presnick@qualcomm.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 5647CE07B6 for <ftpext@ietfa.amsl.com>; Mon, 30 May 2011 10:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.588
X-Spam-Level: 
X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 q3VBMwr3G4G4 for <ftpext@ietfa.amsl.com>; Mon, 30 May 2011 10:05:06 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id EB5EEE072F for <ftpext@ietf.org>; Mon, 30 May 2011 10:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1306775105; x=1338311105; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4DE3CE3F.5000503@qualcomm.com>|Date:=20Mo n,=2030=20May=202011=2012:05:03=20-0500|From:=20Pete=20Re snick=20<presnick@qualcomm.com>|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20John=20C=20Klensin=20<john-iet f@jck.com>|CC:=20<ftpext@ietf.org>|Subject:=20Re:=20[ftpe xt]=20draft-ietf-ftpext2-typeu-00|References:=20<70AD2F64 6D39D0733A704390@PST.JCK.COM>|In-Reply-To:=20<70AD2F646D3 9D0733A704390@PST.JCK.COM>|Content-Type:=20text/plain=3B =20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=FO23sM+VUH2mf08HLNkDtHimdPHb578B3rh942og0cQ=; b=vq7LutrwW0H++sHCRyQG+kgLn+5QmTvp5EjwS5/SGymB3Lr3ZfGYiKdK 7hUy5Nm7g6L1xFXFnOWQcPUuJpNdsd7L8qx9229xMV5dOptsvqv4Bvn3i N5xh96dhvzaSIVQ9o0W96/zjuxy2/1leJ0EEldTTh02P10wu0LLv547qk o=;
X-IronPort-AV: E=McAfee;i="5400,1158,6362"; a="94306244"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 30 May 2011 10:05:05 -0700
X-IronPort-AV: E=Sophos;i="4.65,291,1304319600"; d="scan'208";a="76078995"
Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 30 May 2011 10:05:05 -0700
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 30 May 2011 10:05:04 -0700
Message-ID: <4DE3CE3F.5000503@qualcomm.com>
Date: Mon, 30 May 2011 12:05:03 -0500
From: Pete Resnick <presnick@qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
References: <70AD2F646D39D0733A704390@PST.JCK.COM>
In-Reply-To: <70AD2F646D39D0733A704390@PST.JCK.COM>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: ftpext@ietf.org
Subject: Re: [ftpext] draft-ietf-ftpext2-typeu-00
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, 30 May 2011 17:05:07 -0000

Silence from the mailing list for a week is not a good thing. Chairs, 
what's up with this?

pr

On 5/23/11 1:50 PM, John C Klensin wrote:
> Hi.
>
> I just got a note indicating that this draft is about to expire.
> It was accepted as a WG work item, originally with a "Submit
> 'FTP Extension for Internationalized Text' as working group
> item" date last April and a target of WG Last Call of July.
>
> (1) Does the WG intend to take it up?
>
> (2) If no discussion is needed, when should a WG Last Call be
> initiated?
>
> (3) I'm ok with submitting a -01 just to keep it active but, if
> anyone has anything substantive that they'd like to see changed
> in the draft, now would be a good time to post those comments.
>
>      john
>
>
> _______________________________________________
> ftpext mailing list
> ftpext@ietf.org
> https://www.ietf.org/mailman/listinfo/ftpext
>    


-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102