From tony@att.com Mon Mar 12 07:43:06 2012 Return-Path: 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 406E621E8028 for ; Mon, 12 Mar 2012 07:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqTyF5mHdyUN for ; Mon, 12 Mar 2012 07:43:05 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 37F4121E8025 for ; Mon, 12 Mar 2012 07:43:05 -0700 (PDT) X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1331563383!15913749!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29474 invoked from network); 12 Mar 2012 14:43:04 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Mar 2012 14:43:04 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2CEhYKe015816 for ; Mon, 12 Mar 2012 10:43:34 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2CEhOda015615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Mar 2012 10:43:27 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Mon, 12 Mar 2012 10:42:27 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2CEgRkC026983 for ; Mon, 12 Mar 2012 10:42:27 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2CEgNJg026856 for ; Mon, 12 Mar 2012 10:42:23 -0400 Received: from [135.91.110.142] (dn135-91-110-142.dhcpn.ugn.att.com[135.91.110.142]) by maillennium.att.com (mailgw1) with ESMTP id <20120312143948gw1004orcne> (Authid: tony); Mon, 12 Mar 2012 14:39:48 +0000 X-Originating-IP: [135.91.110.142] Message-ID: <4F5E0B4F.2080401@att.com> Date: Mon, 12 Mar 2012 10:42:23 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ftpext@ietf.org References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> In-Reply-To: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> X-Forwarded-Message-Id: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> Content-Type: multipart/alternative; boundary="------------070603070003050805090607" X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: [ftpext] Fwd: Re: ftpext2 review of FTP HOST command? X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:43:06 -0000 This is a multi-part message in MIME format. --------------070603070003050805090607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I received the following review this weekend about the HOST command draft= =2E Tony -------- Original Message -------- Subject: Re: ftpext2 review of FTP HOST command? From: Patrik F=E4ltstr=F6m I have had a look at the draft, and some of the comments are general that= I presume you have looked at. In no specific order: 1. Denial of service attack What is people try to do a dictionary attack by repeated HOST commands be= fore the authentication? I think the server should have the right to "just say no" after a number = of failed HOST or failed combinations of host/authentication tries. 2. HOST command required The text says this: > A server-PI that receives a USER command to begin the authenticatio= n > sequence without having received a HOST command SHOULD NOT reject t= he > USER command. Is SHOULD NOT good enough? Should there not be a specific error code if the HOST command is required= ? Or should there be always failed authentication if a virtual host is not = given? Hmm...I am thinking of what the situation might look like many years from= now. I do not think the HTTP/1.1 solution is good enough where there is = a default host that normally is either crap, or worse, disclose data that= give hints on low security in the host. So, is it not better to say for example: A server-PI that receives a USER command to begin the authentication sequ= ence without having received a HOST command must either reject the USER c= ommand with error code XXX or treat the authentication as if the user aut= henticates towards a default host or the union of all virtual hosts. 3. Syntax of hostname Is this really correct? domain =3D sub-domain *("." sub-domain) Should it not be domain =3D sub-domain 1*("." sub-domain) If my memory of abnf does not fail me, i.e. at least two domain name part= s? 4. IDN Suggestion, replace: Internationalization of domain names is only supported through the use of Punycode as described in [RFC3492]. With Internationalization of domain names is only supported through the use of= an A-label as defined in [RFCXXXX] as the hostname parameter. 5. HOST command after authentication The text says this: > As discussed in section 3 of this document, if a HOST command is se= nt > after a user has been authenticated, the server MUST treat the > situation as an invalid sequence of commands and return a 503 reply= =2E Is there no command where the user can return to an unauthenticated state= , but still be connected to the host? If so, I think it should be possibl= e to give the HOST command there. So the key is that the HOST command is = only allowed in a non-authenticated state, right? Hope this helps... Patrik --------------070603070003050805090607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I received the following review this weekend about the HOST command draft.

    Tony

-------- Original Message --------
Subject: Re: ftpext2 review of FTP HOST command?
From: Patrik Fältström 

I have had a look at the draft, and some of the comments are general that I presume you have looked at.

In no specific order:

1. Denial of service attack

What is people try to do a dictionary attack by repeated HOST commands before the authentication?

I think the server should have the right to "just say no" after a number of failed HOST or failed combinations of host/authentication tries.

2. HOST command required

The text says this:

>    A server-PI that receives a USER command to begin the authentication
>    sequence without having received a HOST command SHOULD NOT reject the
>    USER command.

Is SHOULD NOT good enough?

Should there not be a specific error code if the HOST command is required?

Or should there be always failed authentication if a virtual host is not given?

Hmm...I am thinking of what the situation might look like many years from now. I do not think the HTTP/1.1 solution is good enough where there is a default host that normally is either crap, or worse, disclose data that give hints on low security in the host.

So, is it not better to say for example:

A server-PI that receives a USER command to begin the authentication sequence without having received a HOST command must either reject the USER command with error code XXX or treat the authentication as if the user authenticates towards a default host or the union of all virtual hosts.

3. Syntax of hostname

Is this really correct?

domain        = sub-domain *("." sub-domain)

Should it not be

domain        = sub-domain 1*("." sub-domain)

If my memory of abnf does not fail me, i.e. at least two domain name parts?

4. IDN

Suggestion, replace:

Internationalization of domain names is only supported through the
use of Punycode as described in [RFC3492].

With

Internationalization of domain names is only supported through the use of an A-label as defined in [RFCXXXX] as the hostname parameter.

5. HOST command after authentication

The text says this:

>    As discussed in section 3 of this document, if a HOST command is sent
>    after a user has been authenticated, the server MUST treat the
>    situation as an invalid sequence of commands and return a 503 reply.

Is there no command where the user can return to an unauthenticated state, but still be connected to the host? If so, I think it should be possible to give the HOST command there. So the key is that the HOST command is only allowed in a non-authenticated state, right?


Hope this helps...

   Patrik
--------------070603070003050805090607-- From john-ietf@jck.com Mon Mar 12 09:32:47 2012 Return-Path: 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 95BD211E809A for ; Mon, 12 Mar 2012 09:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.783 X-Spam-Level: X-Spam-Status: No, score=-102.783 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfWRhMezj5w2 for ; Mon, 12 Mar 2012 09:32:47 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0676511E8091 for ; Mon, 12 Mar 2012 09:32:47 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S786L-000LGs-Dc; Mon, 12 Mar 2012 12:28:01 -0400 Date: Mon, 12 Mar 2012 12:32:40 -0400 From: John C Klensin To: Tony Hansen , ftpext@ietf.org Message-ID: <8050883FA9D9EB809D8E848C@PST.JCK.COM> In-Reply-To: <4F5E0B4F.2080401@att.com> References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.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] WG Status (was: Re: Fwd: Re: ftpext2 review of FTP HOST command?) X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:32:47 -0000 --On Monday, March 12, 2012 10:42 -0400 Tony Hansen wrote: > I received the following review this weekend about the HOST > command draft. >... Tony, I've got several comments on both the draft and on Patrik's comments, but I also have a prerequisite question. Put in the broadest possible way, "Is the WG actually sufficiently functional to process drafts and, if so, which drafts is it serious about processing?" Even if I were more convinced that "HOST" was needed rather than being something whose functionality should be embedded in USER or ACCT (I'm a lot closer on that topic today than I was a few years ago), I'm not convinced that it is inherently more important than ...-hash, ...-typeu, or even ...-ftp64 (I believe the latter is seriously defective). I'd consider it procedurally obnoxious and probably unacceptable if the only draft the WG is willing to process is one on which the co-chair is a co-author. So: Is the WG really functional? If I update and re-post ...-typeu (today or after the 25th) are enough people willing to review it to permit generating a WG Last Call? Do we have commitments to implement whatever the WG comes up with? If the answer to some or all of the above is "no", should people really spend time reviewing this document or should we be thinking about concluding that FTP's detractors are correct about level of interest and hence give up on this effort? Overworked people who are trying to figure out where to spend their time would like to know. best, john From internet-drafts@ietf.org Mon Mar 12 12:15:52 2012 Return-Path: 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 95FCA21F892A; Mon, 12 Mar 2012 12:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waEqtlT9RZep; Mon, 12 Mar 2012 12:15:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F3121F88FF; Mon, 12 Mar 2012 12:15:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312191552.26369.88812.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 12:15:52 -0700 Cc: ftpext@ietf.org Subject: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-03.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 19:15:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FTP Extensions, 2nd edition Working G= roup of the IETF. Title : FTP TYPE Extension for Internationalized Text Author(s) : John C Klensin Filename : draft-ietf-ftpext2-typeu-03.txt Pages : 11 Date : 2012-03-12 The traditional FTP protocol includes a TYPE command to specify the data representation. That command has values for ASCII and EBCDIC text, plus binary ("IMAGE") transmission. As the Internet becomes more international, there is a growing requirement to be able to transmit textual data, encoded in Unicode, in a way that is independent of the coding and line representation forms of particular operating systems. This memo specifies a new FTP representation TYPE value for Unicode data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ftpext2-typeu-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ftpext2-typeu-03.txt From john-ietf@jck.com Mon Mar 12 12:20:04 2012 Return-Path: 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 5B3ED21F8996 for ; Mon, 12 Mar 2012 12:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.772 X-Spam-Level: X-Spam-Status: No, score=-102.772 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNFokTIWMPwC for ; Mon, 12 Mar 2012 12:20:03 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A551421F8992 for ; Mon, 12 Mar 2012 12:20:03 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S7AiE-000LX8-EY for ftpext@ietf.org; Mon, 12 Mar 2012 15:15:18 -0400 Date: Mon, 12 Mar 2012 15:19:58 -0400 From: John C Klensin To: ftpext@ietf.org Message-ID: <27C16AB26D8ACB797B5F80CD@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-03 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 19:20:04 -0000 Hi. Proving that I'm actually a hopeless optimist, I've posted draft-ietf-ftpext2-typeu-03. This reactivates the TYPE U draft as well as incorporating a small number of editorial and other clarifications. Several reviews from the WG would help convince me it is actually alive (and result in my posting my comments about FTP HOST. Waiting impatiently :-( john From tony@att.com Mon Mar 12 22:21:38 2012 Return-Path: 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 E008E21F877E for ; Mon, 12 Mar 2012 22:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.241 X-Spam-Level: X-Spam-Status: No, score=-106.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAktIqMQFSbr for ; Mon, 12 Mar 2012 22:21:38 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 559CD21F877D for ; Mon, 12 Mar 2012 22:21:38 -0700 (PDT) X-Env-Sender: tony@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1331616096!142716!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14376 invoked from network); 13 Mar 2012 05:21:37 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Mar 2012 05:21:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2D5M6C4021374 for ; Tue, 13 Mar 2012 01:22:07 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2D5LwdA021301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 01:21:59 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Tue, 13 Mar 2012 01:21:05 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2D5L4ca027391 for ; Tue, 13 Mar 2012 01:21:04 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2D5KwxY027078 for ; Tue, 13 Mar 2012 01:20:58 -0400 Received: from [135.70.244.6] (vpn-135-70-244-6.vpn.east.att.com[135.70.244.6]) by maillennium.att.com (mailgw1) with ESMTP id <20120313051821gw1004orese> (Authid: tony); Tue, 13 Mar 2012 05:18:22 +0000 X-Originating-IP: [135.70.244.6] Message-ID: <4F5ED938.7090406@att.com> Date: Tue, 13 Mar 2012 01:20:56 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@PST.JCK.COM> In-Reply-To: <8050883FA9D9EB809D8E848C@PST.JCK.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: ftpext@ietf.org Subject: Re: [ftpext] WG Status X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 05:21:39 -0000 John, thank you for posting this note, as well as your updated draft. Pete Resnick, Anthony and I have also been discussing this very question for some time. We've been trying some behind-the-scenes efforts to get some more participation, but have had little success. Frankly, Pete is ready to just pull the plug. Folks, if you care about this working group's existence, please speak up now. Your thoughts are requested on the topics of: *) the group's existence *) the HOST document *) the TYPEU document just posted Thank you. If no one responds, be assured that the group will shut down shortly. Tony Hansen your friendly neighborhood co-chair On 3/12/2012 12:32 PM, John C Klensin wrote: > --On Monday, March 12, 2012 10:42 -0400 Tony Hansen > wrote: > >> I received the following review this weekend about the HOST >> command draft. >> ... > Tony, > > I've got several comments on both the draft and on Patrik's > comments, but I also have a prerequisite question. Put in the > broadest possible way, "Is the WG actually sufficiently > functional to process drafts and, if so, which drafts is it > serious about processing?" > > Even if I were more convinced that "HOST" was needed rather than > being something whose functionality should be embedded in USER > or ACCT (I'm a lot closer on that topic today than I was a few > years ago), I'm not convinced that it is inherently more > important than ...-hash, ...-typeu, or even ...-ftp64 (I believe > the latter is seriously defective). I'd consider it > procedurally obnoxious and probably unacceptable if the only > draft the WG is willing to process is one on which the co-chair > is a co-author. > > So: > > Is the WG really functional? > > If I update and re-post ...-typeu (today or after the > 25th) are enough people willing to review it to permit > generating a WG Last Call? > > Do we have commitments to implement whatever the WG > comes up with? > > If the answer to some or all of the above is "no", should people > really spend time reviewing this document or should we be > thinking about concluding that FTP's detractors are correct > about level of interest and hence give up on this effort? > > Overworked people who are trying to figure out where to spend > their time would like to know. > > best, > john > From anthonybryan@gmail.com Mon Mar 12 22:24:05 2012 Return-Path: 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 3EBEC21F87D8 for ; Mon, 12 Mar 2012 22:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gatjAsSt9+pL for ; Mon, 12 Mar 2012 22:24:03 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 833D921F87CD for ; Mon, 12 Mar 2012 22:24:03 -0700 (PDT) Received: by ggmi1 with SMTP id i1so160799ggm.31 for ; Mon, 12 Mar 2012 22:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=K+52DV8eOm66Uw2vj+ImmvCZcvu6u/w9ZQP3X5fLceI=; b=SCYavCIkilsZK6ykkxFKsMap0SkOiJ+LMbHJoe9yxfPBvOF9XcFuU5TRp4iTm/M4Yg 6+XXlW4SPSXCOx/weQriEY8TqaoKbn3TdzJGP9NuWbfz4/o1rh70epnCTfSN1gSi7U4U qnYaSDJVTGWeMFpneR74VdV4a/gHV9pw896BSP7GsqEXjZxUP4gZyoeKJYwZGrNGi6dL cNPeWjLj3FlEkuoiGAwiRsWnkhyAmC3VjPtN9OJQ5JJ1tGg8n4Ta1iFHUQgrAQuvdvNa 0qOCT5XDBUBxC0XKCmVPpG1QwGs5f5lJSGZUH69SPmaxnPtSmxLY1b1gQjVZZhQ7AbTu sS9w== MIME-Version: 1.0 Received: by 10.236.154.137 with SMTP id h9mr15931298yhk.91.1331616243089; Mon, 12 Mar 2012 22:24:03 -0700 (PDT) Received: by 10.146.95.15 with HTTP; Mon, 12 Mar 2012 22:24:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 01:24:03 -0400 Message-ID: From: Anthony Bryan To: Paul Ford-Hutchinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] Review of FTP HOSTS draft X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 05:24:05 -0000 Paul, thanks for reading & reviewing the review! On Mon, Feb 27, 2012 at 7:42 AM, Paul Ford-Hutchinson wrote: > > Some comments ... > > ftpext-bounces@ietf.org wrote on 24/02/2012 23:20:48: > > > >> Alexey Melnikov was kind enough to review this draft but was not on >> the list so I am forwarding it for him. >> >> 1. =A0Introduction >> >> =A0 This means that different virtual hosts cannot offer different >> =A0 virtual file systems to clients, nor can they offer different >> =A0 authentication systems. =A0Any scheme to overcome this issue needs t= o >> =A0 indicate not only the destination IP address, but also the virtual >> =A0 host name that is associated with the desired virtual FTP server. >> =A0 Typical user-FTP processes currently use hostnames to perform >> =A0 hostname to IP address resolution and then ignore hostnames for the >> =A0 rest of the FTP session, therefore any mechanism to overcome this >> =A0 issue would require modifications to the user-PI and server-PI. >> >> Minor: You should have references for terms like user-PI/server-PI the >> first >> time you reference them. > > [RFC959] ? yes >> In Section 3.2.2: >> >> =A0 This is also true when the HOST command is used with the AUTH and >> =A0 ADAT commands that are discussed in [RFC2228] and [RFC4217]. =A0In t= his >> =A0 scenario, the user-PI sends a HOST command which the server-PI uses >> =A0 to route activity to the correct virtual host, then the user-PI uses >> =A0 the AUTH and ADAT commands to negotiate the security mechanism and >> =A0 relevant authentication token(s) with the server-PI, then the user-P= I >> =A0 sends user credentials using the USER and PASS commands which the >> =A0 server-PI validates. =A0After which the user-PI MAY send an ACCT >> =A0 command to specify any additional account information for the >> =A0 server-PI implementation. =A0The following example illustrates a >> =A0 sequential series of client commands that specify both a HOST and >> =A0 ACCT when used in conjunction with the security commands that are >> =A0 discussed in [RFC2228] and [RFC4217], with the server responses >> =A0 omitted for brevity: >> >> =A0 =A0 =A0 =A0C> HOST ftp.example.com >> =A0 =A0 =A0 =A0C> AUTH >> =A0 =A0 =A0 =A0C> ADAT >> =A0 =A0 =A0 =A0C> USER foo >> =A0 =A0 =A0 =A0C> PASS bar >> =A0 =A0 =A0 =A0C> ACCT project1 >> >> Is USER/PASS actually required after ADAT? (Just asking) > > according to the various RFCs; ADAT, USER and PASS are all optional. =A0T= his > is just an elaboration of what was already in [RFC2228]. maybe that is worth clarifying? (as below) >> 3.3. =A0HOST command errors >> >> =A0 The server-PI SHOULD reply with a 500 or 502 reply if the HOST >> =A0 command is unrecognized or unimplemented. >> >> This requirement is strange: you are either making a requirement on an >> implementation which doesn't support this specification (and thus you >> can't >> do that), or you are saying that an implementation can recognize but >> not implement the HOST command which seems pointless. >> I suggest deleting this sentence (or clarify its purpose). > > It does appear that this is just explicitly restating the standard FTP > responses. yes, perhaps taking a cue from RFC 3659 would be good (some of my drafts need this change as well): "Where the command cannot be correctly parsed, a 500 or 501 reply should be sent, as specified in RFC 959." ... 7.2.1. Error Responses to MLSx commands Many of the 4xy and 5xy responses defined in section 4.2 of STD 9, RFC 959 are possible in response to the MLST and MLSD commands. In particular, syntax errors can generate 500 or 501 replies. Giving a pathname that exists but is not a directory as the argument to a MLSD command generates a 501 reply. Giving a name that does not exist, or for which access permission (to obtain directory information as requested) is not granted will elicit a 550 reply. Other replies (530, 553, 503, 504, and any of the 4xy replies) are also possible in appropriate circumstances. >> In Section 4: >> >> =A0 Section 15.1.1 of [RFC4217] discusses the use of X.509 certificates >> =A0 for server authentication. =A0Taking the information from that docum= ent >> =A0 into account, when securing FTP sessions with the security mechanism= s >> =A0 that are defined in [RFC4217], client implementations SHOULD verify >> =A0 that the hostname they specify in the parameter for the HOST command >> =A0 matches the identity that is specified in the server's X.509 >> =A0 certificate in order to prevent man-in-the-middle attacks. >> >> How can this verification can be achieved? Please either add the text >> (for example by referencing RFC 6125, I can help with wordsmithing), >> or add another appropriate reference here. > > RFC6125 does not discuss FTP. =A0I do not think that this document is a > suitable place for making that linkage by the back door. =A0(I am not say= ing > that FTP shouldn't be in RFC6125 - it probably should - but that the > introduction of the 'HOST' command is not the way to do it.) we could ask Alexey what he thinks it should say, as he offered help with the text? or... > Can we push for an update to RFC6125 that does include FTP and then > reference it in here? I'm not sure - asking other to do more work when this WG has not accomplished anything yet may step on some toes :) perhaps filing an erratum with information to be "Held For Document Update"? that is, if there's a revision, it will include the info. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From john-ietf@jck.com Tue Mar 13 00:25:38 2012 Return-Path: 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 37FEB11E8089 for ; Tue, 13 Mar 2012 00:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.765 X-Spam-Level: X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U50F9fSpdLj for ; Tue, 13 Mar 2012 00:25:37 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 637FB11E8087 for ; Tue, 13 Mar 2012 00:25:37 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S7M2J-000Meu-KJ; Tue, 13 Mar 2012 03:20:47 -0400 Date: Tue, 13 Mar 2012 03:25:28 -0400 From: John C Klensin To: Anthony Bryan , Paul Ford-Hutchinson Message-ID: <0F02790880FAFEA6FA8D28D4@PST.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: ftpext@ietf.org Subject: Re: [ftpext] Review of FTP HOSTS draft X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 07:25:38 -0000 --On Tuesday, March 13, 2012 01:24 -0400 Anthony Bryan wrote: >... >>> In Section 4: >>>=20 >>> =C2=A0 Section 15.1.1 of [RFC4217] discusses the use of = X.509 >>> certificates =C2=A0 for server authentication. =C2=A0Taking = the >>> information from that document =C2=A0 into account, when >>> securing FTP sessions with the security mechanisms =C2=A0 = that >>> are defined in [RFC4217], client implementations SHOULD >>> verify =C2=A0 that the hostname they specify in the = parameter >>> for the HOST command =C2=A0 matches the identity that is >>> specified in the server's X.509 =C2=A0 certificate in order = to >>> prevent man-in-the-middle attacks. >>>=20 >>> How can this verification can be achieved? Please either add >>> the text (for example by referencing RFC 6125, I can help >>> with wordsmithing), or add another appropriate reference >>> here. >>=20 >> RFC6125 does not discuss FTP. =C2=A0I do not think that this >> document is a suitable place for making that linkage by the >> back door. =C2=A0(I am not saying that FTP shouldn't be in >> RFC6125 - it probably should - but that the introduction of >> the 'HOST' command is not the way to do it.) >=20 > we could ask Alexey what he thinks it should say, as he > offered help with the text? >=20 > or... >=20 >> Can we push for an update to RFC6125 that does include FTP >> and then reference it in here? >=20 > I'm not sure - asking other to do more work when this WG has > not accomplished anything yet may step on some toes :) >=20 > perhaps filing an erratum with information to be "Held For > Document Update"? that is, if there's a revision, it will > include the info. Hmm. 4217 notwithstanding, it seems to me that, if we are not going to turn FTP into a single-channel protocol through the back door, there is the potential, first, for the server to which the command channel is connected to have a certificate per HOST name (virtual host) or one certificate for the physical host/ host farm. The server to (or from) which the data channel is connected may be yet a different machine, actually one machine per command for those commands that cause data to be transferred (PUT and GET, but also LIST and NLST, etc.). This can be seen as another instance of scenario (iii) in Section 7 of RFC 4217 -- a case that 4217 excludes completely. If one were serious about using PASV in the general case, I think HOST effectively introduces a fourth scenario -- "virtual host/ server farm-friendly client/server data exchange" -- that looks a lot like scenario (ii) but that has most of the nasty properties of scenario (iii), i.e., the control connection proceeds as in scenario (ii) but the host/address specified for the data connection by the (command channel) server is a function of the argument to the HOST command, not just the properties of the server hosting the command channel. If this fourth scenario is excluded, as RFC 4217 excludes Scenario (iii), then the utility of HOST, as specified in this draft, in situations where TLS security is desired goes down considerably: if FTP virtual hosts are supported via one server-PI (control connection server) but multiple content servers/hosts for different collections of virtual host file systems, HOST is not usable with per-content-server certificates. I'd expect that case to be common, for obvious reasons. That is technically known as "a mess". It requires significantly more FTP-specific analysis than one could put into an erratum or try to load onto RFC 6125bis. It can be added to the list of reasons I've been nervous about the possibility that, because of the serial two-stream model, an FTP HOST command opens up problems and unintended consequences that are much broader than those experienced with HTTP 1.1 and its HOST command. At a minimum, I think this document is required to include some discussion of issues that would be encountered if the HOST command/extension were anticipated to be used in conjunction with the RFC 4217 TLS one. Perhaps some of the comments above could be used to start that discussion; feel free to use or adapt them. john From daniel@haxx.se Tue Mar 13 00:32:27 2012 Return-Path: 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 AB89B21F886B for ; Tue, 13 Mar 2012 00:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5tR5O76Gkxd for ; Tue, 13 Mar 2012 00:32:26 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7257821F8865 for ; Tue, 13 Mar 2012 00:32:26 -0700 (PDT) Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id q2D7WJ9r023739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Mar 2012 08:32:19 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id q2D7WISj023729; Tue, 13 Mar 2012 08:32:18 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 13 Mar 2012 08:32:18 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: John C Klensin In-Reply-To: <8050883FA9D9EB809D8E848C@PST.JCK.COM> Message-ID: References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@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 Cc: ftpext@ietf.org Subject: Re: [ftpext] WG Status (was: Re: Fwd: Re: ftpext2 review of FTP HOST command?) X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 07:32:27 -0000 On Mon, 12 Mar 2012, John C Klensin wrote: > Do we have commitments to implement whatever the WG > comes up with? If server softwares would implement HOST and if server admins would configure their servers to use it, then I'd be inclined to add support for it (in curl). A lot of ifs in there and given history I'd say we're a loooong way from that situation. > If the answer to some or all of the above is "no", should people really > spend time reviewing this document or should we be thinking about concluding > that FTP's detractors are correct about level of interest and hence give up > on this effort? I'm sorry to agree: this is not a very functional WG. To me, it looks like there's not enough interest from implementors to update FTP. -- / daniel.haxx.se From john-ietf@jck.com Tue Mar 13 07:10:29 2012 Return-Path: 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 C9CB321F8880 for ; Tue, 13 Mar 2012 07:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.762 X-Spam-Level: X-Spam-Status: No, score=-102.762 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Dx2k5SMewe3 for ; Tue, 13 Mar 2012 07:10:28 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id C23A021F887F for ; Tue, 13 Mar 2012 07:10:28 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S7SM7-000N5c-Dx; Tue, 13 Mar 2012 10:05:39 -0400 Date: Tue, 13 Mar 2012 10:10:20 -0400 From: John C Klensin To: Daniel Stenberg Message-ID: <25D7B5EC576CA65951F75AB8@PST.JCK.COM> In-Reply-To: References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@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 Cc: ftpext@ietf.org Subject: Re: [ftpext] WG Status (was: Re: Fwd: Re: ftpext2 review of FTP HOST command?) X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 14:10:30 -0000 --On Tuesday, March 13, 2012 08:32 +0100 Daniel Stenberg wrote: >> If the answer to some or all of the above is "no", should >> people really spend time reviewing this document or should >> we be thinking about concluding that FTP's detractors are >> correct about level of interest and hence give up on this >> effort? > > I'm sorry to agree: this is not a very functional WG. To me, > it looks like there's not enough interest from implementors to > update FTP. Let me say something slightly more optimistic than the above, even though I don't think it helps the WG very much. I think we have several implementers out there, each with a client/customer base. While those clusters of customers probably overlap enough in their properties and needs to be different from a niche-per-implementer/ vendor, they are different. The result is that vendor X wants extensions A, B, and C (which they may have developed, implemented, and deployed in some form). Vendor Y wants extensions D, E, and C', where C' is functionally more or less like C but not identical. Maybe we could get them together to work on a common C-approximation (although there hasn't been evidence of that so far). But X sees no commercial value in working on, or even reviewing D or E and Y sees no commercial value in working on A or B. Worse from our point of view, X's main interest, as a server vendor, in bringing A and B to the IETF is to get them standardized so they can beat up client vendors who haven't implemented what would otherwise be a perfectly good proprietary feature. That not only gives them no incentive to invest energy on D or E, it gives them significant incentive to push back on any changes to their already-implemented versions of A and B (using "running code" as an excuse). I think (Anthony can correct me if needed) we can understand the target audience for HOST in that context. While it is one that might occasionally require strong user authentication (including the usual cryptographic isolation of the relevant information and/or handshaking), and might require integrity protection of the data stream (and that is where draft-ietf-ftpext2-hash comes in) it would rarely require privacy protection. I say "occasionally" because there would be many cases where the approach would be used anonymously or with a minimum of identification (just like "normal" FTP). In that sense, the model is very similar to web pages that are accessed to retrieve information rather that, e.g., to carry out transactions that might require authentication and/or transmission of sensitive information. If that is the model, then the proposal in this spec is reasonable and most of the concern about TLS, especially TLS with strong certificate-based protection, is largely irrelevant. However, that view raises the obvious and usual questions: (1) Will (and should) the IETF accept a proposal with known security weaknesses if the author says "just don't use it in contexts requiring strong data privacy protection". (ii) Are the WG and the IETF willing to accept an FTP Extension spec that doesn't play well with extant extensions? The charter is remarkably silent on that matter. (iii) What value can/does the IETF add in this type of limited scenario case? (iv) Why doesn't the specification describe the usage scenarios clearly enough that it can clearly exclude those cases that require strong security? Pragmatically, what this all amounts to, IMO, is "draft needs work". And the evidence remains that the WG doesn't have whatever it takes to get that work done. john p.s. On looking at the charter, I discovered that one of the things the WG committed to do was "* Review and confirm or reject errata of current FTP RFCs" Circa 18 months after we got serious about chartering the group (longer than that if one uses other criteria), that task hasn't been started. Another entry in the "not a good sign" list, IMO. From tj@castaglia.org Tue Mar 13 09:16:57 2012 Return-Path: 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 D04C321E8038 for ; Tue, 13 Mar 2012 09:16:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUWtK78oU9h2 for ; Tue, 13 Mar 2012 09:16:57 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by ietfa.amsl.com (Postfix) with ESMTP id ACDF021E8039 for ; Tue, 13 Mar 2012 09:16:56 -0700 (PDT) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 93850205EB for ; Tue, 13 Mar 2012 12:16:55 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 13 Mar 2012 12:16:55 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=castaglia.org; h= date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=mesmtp; bh=0y+Pu4SbysG23urAFL6KkX9 ydH0=; b=gb0XmARvmnkRfcm5Lv0MJRlDyan1hvMAuBWvXydIiImuOJxjwEQvRtt NxwsliEbkR6RGPKpnpR3LRlMvRUVwV4IAVQERizwX0a8STTNieLtwHRN5kk0BWi7 qf2FMVSmyEJkxqQRVOCi26xgeDtQOgR83SiJhtCoUy0nQEVdONz0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:in-reply-to :message-id:references:mime-version:content-type; s=smtpout; bh= 0y+Pu4SbysG23urAFL6KkX9ydH0=; b=rctq48scVjX1hffLxL8U1YgjFTQvgf4+ pr8TBYqOtz6TJe7KyA4H6e0w7E423c8+TkVaUK2YMLP9sJiP6S+Rgnxn2N86UfM/ 3fHdhvkvzaB4LxGG9rnrepCgSr+TGXg/muxlVVcYYL9bS2xOlpYn61IMmb84kUpn Qnbt1IPZzF8= X-Sasl-enc: HY/NWctAvHF0Q7ygzesCcEF+OgnyDko5zeiAIii6vPU/ 1331655415 Received: from familiar.local (64-71-23-251.static.wiline.com [64.71.23.251]) by mail.messagingengine.com (Postfix) with ESMTPSA id 0E0AB8E0109; Tue, 13 Mar 2012 12:16:54 -0400 (EDT) Date: Tue, 13 Mar 2012 09:16:53 -0700 (PDT) From: TJ Saunders To: Tony Hansen In-Reply-To: <4F5ED938.7090406@att.com> Message-ID: References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@PST.JCK.COM> <4F5ED938.7090406@att.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ftpext@ietf.org Subject: Re: [ftpext] WG Status X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 16:16:57 -0000 > *) the HOST document Given the paucity of IPv4 addresses (and their widespread use), I still consider name-based virtual hosting support in FTP, via the proposed HOST command, to be of considerable value. I will be implementing this command in proftpd for the next RC release; as such, I have been reading closely many of the comments on this topic. My impression is that the HOST command proposal will end up being implemented whether or not the WG continues to exist. Without the WG pushing the proposal through to Standard status, however, those implementations are more likely to differ. To ameliorate that possibility, I for one would like to see the WG continue. I am not much for document formatting and scheduling and such, but if the perceived lack of progress on the HOST draft is due to lack of implementations, then I can do my part to address that need for an implementation. I suspect others have already implemented HOST, however. There have been, and will continue to be, questions about how to handle HOST edge cases (REIN, close the connection, etc), and how it will interact with e.g. TLS SNI. These are excellent questions, and should be addressed -- but please do not let the lack of resolution on these questions cause the HOST draft to be stopped altogether. "Don't let the perfect be the enemy of the good", as it were. Just my thoughts on this particular topic. Cheers, TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Drink to me only with thine eyes, And I will pledge with mine; Or leave a kiss but in the cup And I'll not look for wine. -Ben Jonson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From sm@resistor.net Tue Mar 13 09:30:51 2012 Return-Path: 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 4F40421F8790 for ; Tue, 13 Mar 2012 09:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.642 X-Spam-Level: X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmQ8pOdz2r+w for ; Tue, 13 Mar 2012 09:30:48 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D488F21F86A7 for ; Tue, 13 Mar 2012 09:30:48 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2DGUgWJ003557; Tue, 13 Mar 2012 09:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331656247; i=@resistor.net; bh=TOGX7uTiI/JKXqu5x4PTDYVW6obGHFNqhB3meAI3c4A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=w8JQ0iFCkS/Pt5e+49rC5rz0WQZYh0ZLFm19djOcI/WN6cQgbChXb0wGt+Ju4h9KW Bzfq3uUt5iiQPz6OEPnZjY5e6ZI9OK6wapKqZY2yHeb3sjXR6Sz1Bcg5K6F28VYpD9 4kQOx40wH8SrvYmh7SEjgNRNFqIdjMeml3pssIEM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1331656247; i=@resistor.net; bh=TOGX7uTiI/JKXqu5x4PTDYVW6obGHFNqhB3meAI3c4A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Y1fGkcNaGpivLWnDJkdrMgv9f+vJqNpNdqlqg1q6AbQYbI7kPNoRQIvOjhFiDg4a5 Hz9HNngaurCx/4B2x5EiP1aANU7Q9aPCfoH6cBbbfY/KfXT7WTcRbtB4O021AngCH3 jypJI55hrMJ2KR5dNz6iR5ScjCinKi+Og30I9iBA= Message-Id: <6.2.5.6.2.20120313090805.08f0d5a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Mar 2012 09:24:58 -0700 To: John C Klensin From: SM In-Reply-To: <25D7B5EC576CA65951F75AB8@PST.JCK.COM> References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@PST.JCK.COM> <25D7B5EC576CA65951F75AB8@PST.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ftpext@ietf.org Subject: Re: [ftpext] WG Status (was: Re: Fwd: Re: ftpext2 review of FTP HOST command?) X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 16:30:51 -0000 Hi John, At 07:10 13-03-2012, John C Klensin wrote: >Let me say something slightly more optimistic than the above, >even though I don't think it helps the WG very much. I think we >have several implementers out there, each with a client/customer >base. While those clusters of customers probably overlap enough >in their properties and needs to be different from a >niche-per-implementer/ vendor, they are different. The result >is that vendor X wants extensions A, B, and C (which they may >have developed, implemented, and deployed in some form). Vendor >Y wants extensions D, E, and C', where C' is functionally more >or less like C but not identical. Maybe we could get them >together to work on a common C-approximation (although there >hasn't been evidence of that so far). But X sees no commercial >value in working on, or even reviewing D or E and Y sees no >commercial value in working on A or B. > >Worse from our point of view, X's main interest, as a server >vendor, in bringing A and B to the IETF is to get them >standardized so they can beat up client vendors who haven't >implemented what would otherwise be a perfectly good proprietary >feature. That not only gives them no incentive to invest energy >on D or E, it gives them significant incentive to push back on >any changes to their already-implemented versions of A and B >(using "running code" as an excuse). It's up to X and Y to figure out what's in their mutual interest. Otherwise, one ends up with the classic scenario of a non-working group. >p.s. On looking at the charter, I discovered that one of the >things the WG committed to do was > > "* Review and confirm or reject errata of current FTP > RFCs" > >Circa 18 months after we got serious about chartering the group >(longer than that if one uses other criteria), that task hasn't >been started. Another entry in the "not a good sign" list, IMO. The WG doesn't have any RFC to show since it was chartered in November 2010. That's not a good sign. Regards, -sm From anthonybryan@gmail.com Tue Mar 13 12:55:14 2012 Return-Path: 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 027E221F8644 for ; Tue, 13 Mar 2012 12:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.666 X-Spam-Level: X-Spam-Status: No, score=-4.666 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTeCxmBcYFyW for ; Tue, 13 Mar 2012 12:55:13 -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 1310221F863E for ; Tue, 13 Mar 2012 12:55:13 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1110925ghb.31 for ; Tue, 13 Mar 2012 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wpHW8wPeqA3jvm870e48lA6kmeLDc89raKcFAyH3na0=; b=ujEZNIPlaUyoWFON5+HtcACRPzgLJZ5eJRTUpsXMDKh+vYaItN1UC95SK8xdTY/iee hxDsAM7to54++PDm/j2QDBZ7DsD2HDt42i+BvwkYsRvEPhLWkav4j71cp7T9CWosV2BA wffTiEQY+XXn/nTSunleCFuLNW3K6utqcGzrWXGWAsqteQ4ucjuptcFcSB3shiucL645 QDIG7JG9mN0ess5ZQc+/3dtfy3WCrnsfADTWChBZGM/bmnonxnuodoY+iNIcwd2AXy7i iM13KpNq+CmFpSHi3u8CQgWriCqAKjO4NfiTH3mU0/gTDKHZ/a5Jh8fse3hqqN3pw5hS zxYg== MIME-Version: 1.0 Received: by 10.101.151.34 with SMTP id d34mr5822497ano.19.1331668512702; Tue, 13 Mar 2012 12:55:12 -0700 (PDT) Received: by 10.146.95.15 with HTTP; Tue, 13 Mar 2012 12:55:12 -0700 (PDT) In-Reply-To: <8050883FA9D9EB809D8E848C@PST.JCK.COM> References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@PST.JCK.COM> Date: Tue, 13 Mar 2012 15:55:12 -0400 Message-ID: From: Anthony Bryan To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] WG Status (was: Re: Fwd: Re: ftpext2 review of FTP HOST command?) X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 19:55:14 -0000 On Mon, Mar 12, 2012 at 12:32 PM, John C Klensin wrote: > > > --On Monday, March 12, 2012 10:42 -0400 Tony Hansen > wrote: > >> I received the following review this weekend about the HOST >> command draft. >>... > > Tony, > > I've got several comments on both the draft and on Patrik's > comments, but I also have a prerequisite question. =A0Put in the > broadest possible way, "Is the WG actually sufficiently > functional to process drafts and, if so, which drafts is it > serious about processing?" I would like to hear your comments on both, John... this WG may not be functional enough, but as I understand it we will still have the mailing list (if the WG is closed) & drafts could progress through individual submission. so, either way, your comments will improve the draft - despite your concerns, wouldn't you rather it be as good as possible? here are the drafts on our charter. FTP consideration for IPv4/IPv6 transition http://tools.ietf.org/html/draft-ietf-ftpext2-ftp64 FTP TYPE Extension for Internationalized Text http://tools.ietf.org/html/draft-ietf-ftpext2-typeu HASH Command for Cryptographic Hashes http://tools.ietf.org/html/draft-ietf-ftpext2-hash HOST Command for Virtual Hosts http://tools.ietf.org/html/draft-ietf-ftpext2-hosts > Even if I were more convinced that "HOST" was needed rather than > being something whose functionality should be embedded in USER > or ACCT (I'm a lot closer on that topic today than I was a few > years ago), I'm not convinced that it is inherently more > important than ...-hash, ...-typeu, or even ...-ftp64 (I believe > the latter is seriously defective). =A0I'd consider it > procedurally obnoxious and probably unacceptable if the only > draft the WG is willing to process is one on which the co-chair > is a co-author. no one is saying one is more important than the other, but some have more interest than others. I can see how my draft progressing would be annoying but don't worry about that, there either will be a WG or there won't. > > So: > > =A0 =A0 =A0 =A0Is the WG really functional? > > =A0 =A0 =A0 =A0If I update and re-post ...-typeu (today or after the > =A0 =A0 =A0 =A025th) are enough people willing to review it to permit > =A0 =A0 =A0 =A0generating a WG Last Call? I have reviewed it but I don't know enough about this subject matter to comment unfortunately. please, everyone who is knowledgeable on it, review typeu! > =A0 =A0 =A0 =A0Do we have commitments to implement whatever the WG > =A0 =A0 =A0 =A0comes up with? > > If the answer to some or all of the above is "no", should people > really spend time reviewing this document or should we be > thinking about concluding that FTP's detractors are correct > about level of interest and hence give up on this effort? HOST has 6 or more implementations already. HASH, where I did a good deal of advocacy, has a number of implementations ready to upgrade from similar previous non-standard commands. I don't think I have read of implementations for the other 2 drafts. > Overworked people who are trying to figure out where to spend > their time would like to know. I hear you - I'm publicly apologizing for where I've dropped the ball in this WG. we all have real life to deal with & things come up. all volunteer work is appreciated & I think we are doing useful work that will be used by people. :) --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Tue Mar 13 13:33:53 2012 Return-Path: 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 8F4A221F856F for ; Tue, 13 Mar 2012 13:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evwQPZ0QElZL for ; Tue, 13 Mar 2012 13:33:52 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C32EF21F84C9 for ; Tue, 13 Mar 2012 13:33:52 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1155530ggm.31 for ; Tue, 13 Mar 2012 13:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qVDDVCOMzdxiW8mzlyF2GNQ1zJNzH+VW2AxT0KhNfyw=; b=edYAX/HyfGTuMyAxspjPS/RMqTCxBee3QJL9ZL+rrIVMAl5zFyt+g4Pr3QJ671wG2e 7Spa+JZSWa4QrN6hiPKTLGzi+WF+6bPF3fLPKfFmdjpN40G1cVjuTLOYYUOKPpOxY6PI n0hKj8ofjAOTYxriG0j/MJtJVDl0X/QuqwAKrQSzirr5m60rSfUr4frm5DVmpJzHw1PQ XoLXQQOwm/UDre9Pfu1uPnLPkWash1CWZGoXNwV/L2j6stNpN/0kvm1/qP0g6DHBhNQY hV+G1LAVd3ho+fwpW2bndWKixnDGGTjOsFY0G+HRMUN6Hk0s19F+Vn3i5P4iuDS0YkSR K5ZQ== MIME-Version: 1.0 Received: by 10.236.153.104 with SMTP id e68mr18277311yhk.74.1331670832434; Tue, 13 Mar 2012 13:33:52 -0700 (PDT) Received: by 10.146.95.15 with HTTP; Tue, 13 Mar 2012 13:33:52 -0700 (PDT) In-Reply-To: References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@PST.JCK.COM> <4F5ED938.7090406@att.com> Date: Tue, 13 Mar 2012 16:33:52 -0400 Message-ID: From: Anthony Bryan To: TJ Saunders Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] WG Status X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 20:33:53 -0000 On Tue, Mar 13, 2012 at 12:16 PM, TJ Saunders wrote: > >> =A0 =A0 *) the HOST document > > Given the paucity of IPv4 addresses (and their widespread use), I still > consider name-based virtual hosting support in FTP, via the proposed HOST > command, to be of considerable value. > > I will be implementing this command in proftpd for the next RC release; a= s > such, I have been reading closely many of the comments on this topic. thanks for letting us know. here are the other implementations as of a year ago: IIS FTP service Serv-U server WS_FTP service SmartpFTP client Beyond Compare client FTP Voyager client. > My impression is that the HOST command proposal will end up being > implemented whether or not the WG continues to exist. =A0Without the WG > pushing the proposal through to Standard status, however, those > implementations are more likely to differ. =A0To ameliorate that > possibility, I for one would like to see the WG continue. as it already is implemented, I believe implementations would grow. & I assume the draft would be submitted as an individual submission which I think is more work than a WG submission? I see HOST documented in an RFC better than it not. > There have been, and will continue to be, questions about how to handle > HOST edge cases (REIN, close the connection, etc), and how it will > interact with e.g. TLS SNI. =A0These are excellent questions, and should = be > addressed -- but please do not let the lack of resolution on these > questions cause the HOST draft to be stopped altogether. =A0"Don't let th= e > perfect be the enemy of the good", as it were. I agree, these issues must be addressed. I think we ran into 2 problems here... 1) HOST passed IETF wide Last Call almost 2 years ago. so people are not as interested in reviewing something that has been in limbo & held up by being included in this WG. 2) non core FTP issues like internationalization & security where we need outside help (& have gotten some). > Just my thoughts on this particular topic. thank you very much, they have been helpful! --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From robmcm@microsoft.com Tue Mar 13 22:49:00 2012 Return-Path: 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 1AABA21F8564 for ; Tue, 13 Mar 2012 22:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tr3HiqkjnNs for ; Tue, 13 Mar 2012 22:48:59 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6B321F8562 for ; Tue, 13 Mar 2012 22:48:58 -0700 (PDT) Received: from mail101-db3-R.bigfish.com (10.3.81.241) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Mar 2012 05:48:59 +0000 Received: from mail101-db3 (localhost [127.0.0.1]) by mail101-db3-R.bigfish.com (Postfix) with ESMTP id 591354A0373 for ; Wed, 14 Mar 2012 05:48:59 +0000 (UTC) X-SpamScore: -50 X-BigFish: VS-50(zzbb2dI9371I1b0bM542M1432N98dK4015I111aI148cM179cMzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail101-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=robmcm@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail101-db3 (localhost.localdomain [127.0.0.1]) by mail101-db3 (MessageSwitch) id 1331704137587872_7065; Wed, 14 Mar 2012 05:48:57 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.232]) by mail101-db3.bigfish.com (Postfix) with ESMTP id 81A0F100048 for ; Wed, 14 Mar 2012 05:48:57 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Mar 2012 05:48:56 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 14 Mar 2012 05:48:52 +0000 Received: from mail183-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Wed, 14 Mar 2012 05:48:53 +0000 Received: from mail183-va3 (localhost [127.0.0.1]) by mail183-va3-R.bigfish.com (Postfix) with ESMTP id B7C58260165 for ; Wed, 14 Mar 2012 05:48:53 +0000 (UTC) Received: from mail183-va3 (localhost.localdomain [127.0.0.1]) by mail183-va3 (MessageSwitch) id 1331704128334377_11875; Wed, 14 Mar 2012 05:48:48 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.250]) by mail183-va3.bigfish.com (Postfix) with ESMTP id 4B60E100134; Wed, 14 Mar 2012 05:48:48 +0000 (UTC) Received: from CH1PRD0310HT005.namprd03.prod.outlook.com (157.56.244.37) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Mar 2012 05:48:47 +0000 Received: from CH1PRD0310MB391.namprd03.prod.outlook.com ([169.254.4.104]) by CH1PRD0310HT005.namprd03.prod.outlook.com ([10.255.137.40]) with mapi id 14.16.0123.000; Wed, 14 Mar 2012 05:48:45 +0000 From: Robert McMurray To: Anthony Bryan , Paul Ford-Hutchinson , "ftpext@ietf.org" Thread-Topic: [ftpext] Review of FTP HOSTS draft Thread-Index: AQHNASMcg4ZtTdf/DkyeggS/LEFc05ZpSDMw Date: Wed, 14 Mar 2012 05:48:44 +0000 Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C303A154C@CH1PRD0310MB391.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.233] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%UK.IBM.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [ftpext] Review of FTP HOSTS draft X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 05:49:00 -0000 Thanks, Anthony. As an FYI - I've been watching the WG discussions about the HOST draft, but= I probably won't have a chance to offer up a rewritten draft for at least = a few weeks due to pressing work-related priorities. (We all have to pay th= e bills somehow.) Thanks again, Robert McMurray -----Original Message----- From: Anthony Bryan [mailto:anthonybryan@gmail.com]=20 Sent: Monday, March 12, 2012 10:24 PM To: Paul Ford-Hutchinson Cc: ftpext@ietf.org Subject: Re: [ftpext] Review of FTP HOSTS draft Paul, thanks for reading & reviewing the review! On Mon, Feb 27, 2012 at 7:42 AM, Paul Ford-Hutchinson wrote: > > Some comments ... > > ftpext-bounces@ietf.org wrote on 24/02/2012 23:20:48: > > > >> Alexey Melnikov was kind enough to review this draft but was not on=20 >> the list so I am forwarding it for him. >> >> 1. =A0Introduction >> >> =A0 This means that different virtual hosts cannot offer different >> =A0 virtual file systems to clients, nor can they offer different >> =A0 authentication systems. =A0Any scheme to overcome this issue needs t= o >> =A0 indicate not only the destination IP address, but also the virtual >> =A0 host name that is associated with the desired virtual FTP server. >> =A0 Typical user-FTP processes currently use hostnames to perform >> =A0 hostname to IP address resolution and then ignore hostnames for the >> =A0 rest of the FTP session, therefore any mechanism to overcome this >> =A0 issue would require modifications to the user-PI and server-PI. >> >> Minor: You should have references for terms like user-PI/server-PI=20 >> the first time you reference them. > > [RFC959] ? yes >> In Section 3.2.2: >> >> =A0 This is also true when the HOST command is used with the AUTH and >> =A0 ADAT commands that are discussed in [RFC2228] and [RFC4217]. =A0In=20 >> this >> =A0 scenario, the user-PI sends a HOST command which the server-PI uses >> =A0 to route activity to the correct virtual host, then the user-PI=20 >> uses >> =A0 the AUTH and ADAT commands to negotiate the security mechanism and >> =A0 relevant authentication token(s) with the server-PI, then the=20 >> user-PI >> =A0 sends user credentials using the USER and PASS commands which the >> =A0 server-PI validates. =A0After which the user-PI MAY send an ACCT >> =A0 command to specify any additional account information for the >> =A0 server-PI implementation. =A0The following example illustrates a >> =A0 sequential series of client commands that specify both a HOST and >> =A0 ACCT when used in conjunction with the security commands that are >> =A0 discussed in [RFC2228] and [RFC4217], with the server responses >> =A0 omitted for brevity: >> >> =A0 =A0 =A0 =A0C> HOST ftp.example.com >> =A0 =A0 =A0 =A0C> AUTH >> =A0 =A0 =A0 =A0C> ADAT >> =A0 =A0 =A0 =A0C> USER foo >> =A0 =A0 =A0 =A0C> PASS bar >> =A0 =A0 =A0 =A0C> ACCT project1 >> >> Is USER/PASS actually required after ADAT? (Just asking) > > according to the various RFCs; ADAT, USER and PASS are all optional. =A0 > This is just an elaboration of what was already in [RFC2228]. maybe that is worth clarifying? (as below) >> 3.3. =A0HOST command errors >> >> =A0 The server-PI SHOULD reply with a 500 or 502 reply if the HOST >> =A0 command is unrecognized or unimplemented. >> >> This requirement is strange: you are either making a requirement on=20 >> an implementation which doesn't support this specification (and thus=20 >> you can't do that), or you are saying that an implementation can=20 >> recognize but not implement the HOST command which seems pointless. >> I suggest deleting this sentence (or clarify its purpose). > > It does appear that this is just explicitly restating the standard FTP=20 > responses. yes, perhaps taking a cue from RFC 3659 would be good (some of my drafts ne= ed this change as well): "Where the command cannot be correctly parsed, a 500 or 501 reply should be= sent, as specified in RFC 959." ... 7.2.1. Error Responses to MLSx commands Many of the 4xy and 5xy responses defined in section 4.2 of STD 9, RFC 959 are possible in response to the MLST and MLSD commands. In particular, syntax errors can generate 500 or 501 replies. Giving a pathname that exists but is not a directory as the argument to a MLSD command generates a 501 reply. Giving a name that does not exist, or for which access permission (to obtain directory information as requested) is not granted will elicit a 550 reply. Other replies (530, 553, 503, 504, and any of the 4xy replies) are also possible in appropriate circumstances. >> In Section 4: >> >> =A0 Section 15.1.1 of [RFC4217] discusses the use of X.509 certificates >> =A0 for server authentication. =A0Taking the information from that=20 >> document >> =A0 into account, when securing FTP sessions with the security=20 >> mechanisms >> =A0 that are defined in [RFC4217], client implementations SHOULD verify >> =A0 that the hostname they specify in the parameter for the HOST=20 >> command >> =A0 matches the identity that is specified in the server's X.509 >> =A0 certificate in order to prevent man-in-the-middle attacks. >> >> How can this verification can be achieved? Please either add the text=20 >> (for example by referencing RFC 6125, I can help with wordsmithing),=20 >> or add another appropriate reference here. > > RFC6125 does not discuss FTP. =A0I do not think that this document is a=20 > suitable place for making that linkage by the back door. =A0(I am not=20 > saying that FTP shouldn't be in RFC6125 - it probably should - but=20 > that the introduction of the 'HOST' command is not the way to do it.) we could ask Alexey what he thinks it should say, as he offered help with t= he text? or... > Can we push for an update to RFC6125 that does include FTP and then=20 > reference it in here? I'm not sure - asking other to do more work when this WG has not accomplish= ed anything yet may step on some toes :) perhaps filing an erratum with information to be "Held For Document Update"= ? that is, if there's a revision, it will include the info. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From A.Hoenes@TR-Sys.de Thu Mar 15 06:57:07 2012 Return-Path: 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 0EDF921F85E1 for ; Thu, 15 Mar 2012 06:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.59 X-Spam-Level: X-Spam-Status: No, score=-98.59 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3DJvYowlhXn for ; Thu, 15 Mar 2012 06:57:06 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id AF53521F8624 for ; Thu, 15 Mar 2012 06:57:04 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA186849757; Thu, 15 Mar 2012 14:55:57 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA14201; Thu, 15 Mar 2012 14:55:56 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203151355.OAA14201@TR-Sys.de> To: draft-ietf-ftpext2-hosts.all@tools.ietf.org Date: Thu, 15 Mar 2012 14:55:56 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: ftpext@ietf.org Subject: [ftpext] Review of draft-ietf-ftpext2-hosts-05 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:57:07 -0000 My apologies for not being able to dedicate substantial time for over a year, but following the encouragement, I'm happy to provide another review of the FTP HOST command document. Prologue: I have encouraged and helped the predecessor individual draft for a long time, and I'm a bit surprised that the draft -- after more than 4 years of being technically rather stable and already having more than a handful of independent implementations -- still hasn't made it to the RFC Editor Queue. IETF leadership should not be surprised if reviewers get tired after such long time periods. I fully support this draft and, upon a detailed textual review from scratch, it seems almost ready now for publication. The minor issues explained below seem to be a tribute to the long history of the draft and the evolution of meta-rules in the IETF (/ IESG) to be followed. I also mention a few editorials, but I refrain from indicating minor details like placement of commas that the RFC Editor folks will be happy to put their hands on anyway. However, I omit topics that already seem to be covered enough by other reviews. A) Minor issues: +++++++++++++++ A.1) Section 1 / established precise terminology Please use the correct term, "header field", in the final paragraph of Section 1. OLD: It should be noted that this same problem existed for HTTP/1.0 as defined in [RFC1945], and was resolved in HTTP/1.1 as defined in | [RFC2616] through the addition of the Host request header. [...] ^^^^^^ NEW: It should be noted that this same problem existed for HTTP/1.0 as defined in [RFC1945], and was resolved in HTTP/1.1 as defined in | [RFC2616] through the addition of the Host request header field. [...] ^^^^^^^^^^^^ A.2) Section 3.1 / unique normative source in IETF Std-Track For the sake of avoiding possible conflicts and ambiguity, the IETF prefers having a single normative source for a specific bit of specification that is reused in different protocols. The syntax of the argument of the HOST command is largely borrowed from the Generic URI Syntax (STD 66, RFC 3986) rule, with added restrictions to reflect current need and practice, and to avoid opening the path to implementation bugs by including unspecified extension rules, e.g. for some future address family. I would highly appreciate if the draft could shortly spell out this intent and indicate which parts of the syntax are copied from RFC 3986 for informational purposes only. To this end, I suggest a few text additions, as shown below. a) I suggest to insert, immediately below the ABNF at the beginning of Section 3.1, the following paragraph: | The rule is a restricted form of the rule | specified in the "Generic URI Syntax", STD 66 [RFC3986]. | Details of the additional restrictions imposed by this document | are given further down in this section in the discussion of the | syntax; they aim at simplifying implementations by only allowing | what currently is specified precisely and in use on the Internet. | The and ABNF rules and all subordinate | ABNF rules given above are taken literally from [RFC3986] and | reproduced here for the convenience of readers; however, RFC 3986 | remains the normative specification for the syntactic form of | IPv4 and IPv6 address literals, in order to ensure identical | presentation in 'ftp' URI hostname parts and in the protocol element | specified here. b) Additionally, I suggest to fulfill part of the promise given by the above text by adding more text at the very end of Section 3.1 as follows. OLD: Neither [RFC1034] nor [RFC1035] impose any other restrictions upon what kinds of names can be stored in the DNS. This specification, however, only allows the use of names that can be inferred from the ABNF grammar given for the "hostname". NEW: Neither [RFC1034] nor [RFC1035] impose any other restrictions upon what kinds of names can be stored in the DNS. This specification, however, only allows the use of names that can be inferred from the | ABNF grammar given for the "hostname". Similarly, this specification | restricts address literals to the IPv4 and IPv6 address families well | established in the Internet. A.3) Section 3.1 -- Internationalization / IDNA -- and Section 6.1 The draft needs to be updated to refer to the IDNA2008 document set and use IDNA2008 terminology. OLD: Internationalization of domain names is only supported through the | use of Punycode as described in [RFC3492]. NEW: Internationalization of domain names is only supported through the | use of IDNA "A-Labels" for as described in [RFC5890]. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^ [ Note: This is one instance of description of additional restrictions in the syntax vs. RFC 3986 as mentioned in item A.2 a) above. ] Consequentially, the Ref. item [RFC3492] in the Normative References (Section 6.1) needs to be replaced by a citation of RFC 5890. A.4) Section 3.2.3 -- clarification for transitions omitted in diagrams I suggest to clarify the text intended to indicate state transitions not shown in the state diagrams in Section 3.2.3, by amending the 4th paragraph of Section 3.2.3 as follows. OLD: | In each of these diagrams, a REIN command will return the diagram to | the (B) "begin" state. NEW: | For each of these diagrams, without those state transitions being | shown, a REIN command will return the diagram from any wait state to | the (B) "begin" state. B) Editorials: +++++++++++++ B.1) Abstract RFC Abstracts are to be exctracted and placed into metadata records without access to the References; therefore, formal citations are not possible in the Abstract. So please drop "[RFC0959]" there: OLD: | The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. [...] NEW: | The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. [...] B.2 Section 2.2, last paragraph Please provide the needed hypen: "three digit code" --> "three-digit code" B.3 Section 3.2.1 -- textual clarification I suggest to add the word "afterwards" for clarification, as follows. OLD: As specified in [RFC0959], the REIN command returns the state of the connection to what it was immediately after the transport connection was opened. This specification makes no changes to that behavior. The effect of a HOST command MUST be reset if a REIN command is | performed, and a new HOST command MUST be issued in order to connect to a virtual host. NEW: As specified in [RFC0959], the REIN command returns the state of the connection to what it was immediately after the transport connection was opened. This specification makes no changes to that behavior. The effect of a HOST command MUST be reset if a REIN command is | performed, and a new HOST command MUST be issued afterwards in order to connect to a virtual host. C) Remarks on other review comments +++++++++++++++++++++++++++++++++++ C.1) Section 3.1, ABNF rule Patrik suggested to require at least two domain labels in the ABNF. However, the draft, in response to implementation and deployment practice, explains in the sequel of Section 3.1 that in specific environments, the use of *relative* domain names might be appropriate, and therefore the present draft doen *not* require a Fully Qualified Domain Name (FQDN) for the production. C.2) Several comments on use of specific terms in Section 1 We have Terminology/Conventions sections in I-Ds / RFCs to explain the usage and provenience of technical terms used in a document. Other SDOs place such section *before* the Introduction, but RFC Editor policy doesn't allow that. It would IMHO be detrimental to the readability of a well-written introduction (that is intended to give a high-level intro to the topic while being precise in terminology) to reproduce there all things explained in the Terminology/Conventions section, only because, for the sake of precision, specific terms are used there. If we really want to insist on full explanation (with citation) at the very first use, even in the leading introductory text, we should better allow the Introduction to go after the Terminology Section(s) of IETF documents. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From A.Hoenes@TR-Sys.de Thu Mar 15 07:47:00 2012 Return-Path: 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 1EDB621F8704 for ; Thu, 15 Mar 2012 07:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.595 X-Spam-Level: X-Spam-Status: No, score=-98.595 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68XRsWi3nnUE for ; Thu, 15 Mar 2012 07:46:59 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4480221F8455 for ; Thu, 15 Mar 2012 07:46:58 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA187082753; Thu, 15 Mar 2012 15:45:53 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA14429; Thu, 15 Mar 2012 15:45:51 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203151445.PAA14429@TR-Sys.de> To: evnikita2@gmail.com Date: Thu, 15 Mar 2012 15:45:51 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Cc: ftpext@ietf.org Subject: Re: [ftpext] Grandfathered RFC commands and corresponding registry X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:47:00 -0000 In an attempt to catch up with unanswered messages ... At Fri, 08 Jul 2011 06:45:46 +0300, Mykyta Yevstifeyev wrote: > Hello, > > RFC 5797, as you should know, established the registry for FTP > commands. However, when making up Section 3, a number of pre-959 > legacy commands were excluded from that list. They include: > BYTE, SOCK, BYE (predecessor to QUIT), from RFC 354, MLFF and MAIL > from RFC 385, LSTN from RFC 438, FORM from RFC 454, RDMF and RDML > from RFC 458, 10 mail-related commands from RFC 475, OPEN, CLOS, > SETP, GETP, READ, WRIT from RFC 520, XTP from RFC 683, XSEN, XSEM, > XMAS from RFC 737, XRSQ and XRCP from RFC 734. Correspondingly, > I'd like to ask whether there is some (if any) sense in registering > these values ass 'historical' in the FTP commands registry and > to which extent (beginning with which RFC)? > > Mykyta Yevstifeyev Mykyta, RFC 5797 was intended to accompany the maintenance of an IETF Standard protocol. It wold not make much sense to extend its coverage back into the ARPANET age, since implementations from then have not survived into the current Internet and are of no relevance to contemporary implementors and designers of FTP extensions. In particular, anything related to FTP-Mail is double-gravestone dead! Therefore, RFC 5797 captured in the registry the opcodes from RFC 959 and more recent RFCs, but it also includes the legacy opcodes mentioned in RFC 959 and RFC 1123 (e.g. the X... variants of the directory commands from RFC 775 that -- presumably because of this mention -- are still supported in popular FTP server implementations, including those in use at ftp.rfc-editor.org, ftp.ietf.org, and ftp.iana.org). New registrations need to conform to Sections 2.2 and 2.3, and the second paragraph of Section 5, of RFC 5797. This IMO basically excludes the registration of very old proposed legacy opcodes, due to lack of specification applicable to RFC 959 based FTP implementations and/or exicting implementation. Best regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From anthonybryan@gmail.com Fri Mar 16 15:01:52 2012 Return-Path: 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 9913A21E807A for ; Fri, 16 Mar 2012 15:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.239 X-Spam-Level: X-Spam-Status: No, score=-4.239 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8rTZCGlIFMY for ; Fri, 16 Mar 2012 15:01:51 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57D4C21E801A for ; Fri, 16 Mar 2012 15:01:51 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2286941yhk.31 for ; Fri, 16 Mar 2012 15:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RmlR5BlDrONpEw+DttCLmsiQ7QhKmz0iy0TQwi0JNV0=; b=CxYNxAfdxfpF9dFtETJZjvbIuv1CIKbuLZzlzljJNTusND++jnY+LOVOg0MFZHtIas agSsO+v31/c97c/dCltOmdBc6l+pEdyDR9/VudHJ/XGFPMqhzQ4ipcjp32dUZIfnxV1p Xvaz1FVX4a+em0ueXKV4tgT9T2oc9ApEQnfkyxBaFxENek7Dst+R1tT+KorpleDMAHsu WvBfxsybYnoaEMMTyNyQY+ouEySGdJGsMgvlrTQp1u3rjLBZ3zbWQzC2u6f1+IdmSGDM ghWjZLEiVaiVvNYUadNR0QFwkqA7YYr6amaVMiMgEcZwRV7LctXn/ZnRvQxqUz+Cc38P 6LNw== MIME-Version: 1.0 Received: by 10.236.153.104 with SMTP id e68mr4265831yhk.74.1331935310979; Fri, 16 Mar 2012 15:01:50 -0700 (PDT) Received: by 10.146.95.15 with HTTP; Fri, 16 Mar 2012 15:01:50 -0700 (PDT) In-Reply-To: <25D7B5EC576CA65951F75AB8@PST.JCK.COM> References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@PST.JCK.COM> <25D7B5EC576CA65951F75AB8@PST.JCK.COM> Date: Fri, 16 Mar 2012 18:01:50 -0400 Message-ID: From: Anthony Bryan To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] WG Status (was: Re: Fwd: Re: ftpext2 review of FTP HOST command?) X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 22:01:52 -0000 On Tue, Mar 13, 2012 at 10:10 AM, John C Klensin wrote: > > > --On Tuesday, March 13, 2012 08:32 +0100 Daniel Stenberg > wrote: > >>> If the answer to some or all of the above is "no", should >>> people really =A0spend time reviewing this document or should >>> we be thinking about concluding =A0that FTP's detractors are >>> correct about level of interest and hence give up =A0on this >>> effort? >> >> I'm sorry to agree: this is not a very functional WG. To me, >> it looks like there's not enough interest from implementors to >> update FTP. > > Let me say something slightly more optimistic than the above, > even though I don't think it helps the WG very much. =A0I think we > have several implementers out there, each with a client/customer > base. =A0While those clusters of customers probably overlap enough > in their properties and needs to be different from a > niche-per-implementer/ vendor, they are different. =A0The result > is that vendor X wants extensions A, B, and C (which they may > have developed, implemented, and deployed in some form). =A0Vendor > Y wants extensions D, E, and C', where C' is functionally more > or less like C but not identical. =A0Maybe we could get them > together to work on a common C-approximation (although there > hasn't been evidence of that so far). =A0But X sees no commercial > value in working on, or even reviewing D or E and Y sees no > commercial value in working on A or B. perhaps I'm misunderstanding, but what are C & C'? HASH vs the many hash like commands (XCRC, XMD5, XSHA, etc)? > Worse from our point of view, X's main interest, as a server > vendor, in bringing A and B to the IETF is to get them > standardized so they can beat up client vendors who haven't > implemented what would otherwise be a perfectly good proprietary > feature. =A0That not only gives them no incentive to invest energy > on D or E, it gives them significant incentive to push back on > any changes to their already-implemented versions of A and B > (using "running code" as an excuse). I (& my co-authors) are the only ones who have proposed more than one command (HASH, RANG, LOCK) to be standardized. we are all independent AFAIK but work on our own implementations (curl, aria2, FileZilla). if you're talking about HOST, it was created by Bero in the open source realm quite some time ago. it appears to first be specified in 1998, in the ID that became RFC 3659: http://tools.ietf.org/html/draft-ietf-ftpext-mlst-05 if you mean, as far as a person from Microsoft investing time to standardize/finalize it, isn't that a good thing to be done at the IETF out in the open than "beat[ing] up client vendors" with something proprietary that is only known internally & documented in a .doc file? :) [no offense I have no idea how things work there.] > I think (Anthony can correct me if needed) we can understand the > target audience for HOST in that context. =A0While it is one that > might occasionally require strong user authentication (including > the usual cryptographic isolation of the relevant information > and/or handshaking), and might require integrity protection of > the data stream (and that is where draft-ietf-ftpext2-hash comes > in) it would rarely require privacy protection. =A0I say > "occasionally" because there would be many cases where the > approach would be used anonymously or with a minimum of > identification (just like "normal" FTP). =A0 In that sense, the > model is very similar to web pages that are accessed to retrieve > information rather that, e.g., to carry out transactions that > might require authentication and/or transmission of sensitive > information. > > If that is the model, then the proposal in this spec is > reasonable and most of the concern about TLS, especially TLS > with strong certificate-based protection, is largely irrelevant. > However, that view raises the obvious and usual questions: > > =A0 =A0 =A0 =A0(1) Will (and should) the IETF accept a proposal with > =A0 =A0 =A0 =A0known security weaknesses if the author says "just don't > =A0 =A0 =A0 =A0use it in contexts requiring strong data privacy > =A0 =A0 =A0 =A0protection". > > =A0 =A0 =A0 =A0(ii) Are the WG and the IETF willing to accept an FTP > =A0 =A0 =A0 =A0Extension spec that doesn't play well with extant > =A0 =A0 =A0 =A0extensions? =A0The charter is remarkably silent on that > =A0 =A0 =A0 =A0matter. > > =A0 =A0 =A0 =A0(iii) What value can/does the IETF add in this type of > =A0 =A0 =A0 =A0limited scenario case? > > =A0 =A0 =A0 =A0(iv) Why doesn't the specification describe the usage > =A0 =A0 =A0 =A0scenarios clearly enough that it can clearly exclude > =A0 =A0 =A0 =A0those cases that require strong security? > > Pragmatically, what this all amounts to, IMO, is "draft needs > work". =A0And the evidence remains that the WG doesn't have > whatever it takes to get that work done. I agree the draft needs work, but do you think it needs more than these last reviews (& hopefully a later AppsDir & SecDir review) can provide. granted obviously the WG has been at death's door, but we should still have the mailing list if it gets closed. > p.s. On looking at the charter, I discovered that one of the > things the WG committed to do was > > =A0 =A0 =A0 =A0"* Review and confirm or reject errata of current FTP > =A0 =A0 =A0 =A0RFCs" > > Circa 18 months after we got serious about chartering the group > (longer than that if one uses other criteria), that task hasn't > been started. =A0Another entry in the "not a good sign" list, IMO. I see that an errata discussion started in July 2010. some were filed in 2010 against RFC 959 & 3659 by a quick look, & we should follow up that thread. most were marked "held for document update" --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From anthonybryan@gmail.com Fri Mar 16 15:17:51 2012 Return-Path: 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 C208721E802B for ; Fri, 16 Mar 2012 15:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.982 X-Spam-Level: X-Spam-Status: No, score=-3.982 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVJkfwmhAp0b for ; Fri, 16 Mar 2012 15:17:50 -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 B6F3E21E801A for ; Fri, 16 Mar 2012 15:17:50 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5355172ghb.31 for ; Fri, 16 Mar 2012 15:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pp4++rg7SVvbaQJd1bVp4LgmIysTWBR36bU4ySM6RZg=; b=tPhTGdUmjsxyfO/woW13NnjQR8TcJguXRj8FThE4BE7BFE408Jh86hClIsBQOe85i5 gKpjnZDpCUIXS960LMOsQtOmhhootJHadGzo+1VWOvKA1O3unQFWkmKz1RdTA+et5WPW lW0F4ylvKcOkEPkPCiaInTZhMVGlDCi/OpSILdSrGOD/bPPrdBXp2Dr7F95ozHmPhriX 91iYUkbVzVQF4YsnUzqwgbQnyKGYvnRl5754bgcDRLHffVAkVDOZnCkaJmTQDYNT4n3Z SqDOyUlRwdwg582ATzV0uuSsA6t7IOBTbpY5UPk0aA6XNJJ2efifjbqPZMUuNPjappLs x3Qg== MIME-Version: 1.0 Received: by 10.236.37.199 with SMTP id y47mr3322588yha.125.1331936270231; Fri, 16 Mar 2012 15:17:50 -0700 (PDT) Received: by 10.146.95.15 with HTTP; Fri, 16 Mar 2012 15:17:50 -0700 (PDT) In-Reply-To: <201203151355.OAA14201@TR-Sys.de> References: <201203151355.OAA14201@TR-Sys.de> Date: Fri, 16 Mar 2012 18:17:50 -0400 Message-ID: From: Anthony Bryan To: =?ISO-8859-1?Q?Alfred_H=CEnes?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ftpext@ietf.org Subject: Re: [ftpext] Review of draft-ietf-ftpext2-hosts-05 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 22:17:52 -0000 On Thu, Mar 15, 2012 at 9:55 AM, Alfred H=CEnes wrote: > My apologies for not being able to dedicate substantial time > for over a year, but following the encouragement, I'm happy > to provide another review of the FTP HOST command document. I think that has happened to a number of us. thank you for ANOTHER review :) > Prologue: > I have encouraged and helped the predecessor individual draft for > a long time, and I'm a bit surprised that the draft -- after more > than 4 years of being technically rather stable and already having > more than a handful of independent implementations -- still hasn't > made it to the RFC Editor Queue. =A0IETF leadership should not be > surprised if reviewers get tired after such long time periods. yes, I see this as the main problem of this draft/command - age & tired eye= s. it finished IETF wide Last Call in May 2010, almost 2 years ago. originally introduced in http://tools.ietf.org/html/draft-ietf-ftpext-mlst-05 in 98 over 13 years ago. I am sorry if inclusion in FTPEXT2 slowed things down for HOST, but on the other hand the draft is stronger. it has just taken a long time :) so, let's finish HOST off. PLEASE take the time to look it over. here are the reviews we need to keep an eye on, & please comment on THEM if you need to. Alexey Melnikov's http://www.ietf.org/mail-archive/web/ftpext/current/msg00410.html (and Paul Ford-Hutchinson's followup http://www.ietf.org/mail-archive/web/ftpext/current/msg00411.html & John Klensin's http://www.ietf.org/mail-archive/web/ftpext/current/msg00418.html ) Patrik F=E4ltstr=F6m http://www.ietf.org/mail-archive/web/ftpext/current/msg00412.html Alfred H=F6nes http://www.ietf.org/mail-archive/web/ftpext/current/msg00426.html --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From A.Hoenes@TR-Sys.de Wed Mar 21 03:16:49 2012 Return-Path: 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 D10C021F868C for ; Wed, 21 Mar 2012 03:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.601 X-Spam-Level: X-Spam-Status: No, score=-98.601 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0G8--3OcOGy for ; Wed, 21 Mar 2012 03:16:49 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id C63A821F8680 for ; Wed, 21 Mar 2012 03:16:47 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA229194939; Wed, 21 Mar 2012 11:15:39 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id LAA22565; Wed, 21 Mar 2012 11:15:37 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201203211015.LAA22565@TR-Sys.de> To: john+ietf@jck.com Date: Wed, 21 Mar 2012 11:15:37 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: ftpext@ietf.org Subject: [ftpext] A review of draft-ietf-ftpext2-typeu-03 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 10:16:49 -0000 I took the time to re-consider and re-review the most recent (-03) version of draft-ietf-ftpext2-typeu and would like to submit a few comments, most of which are editorial in nature. The technical content of the draft seems reasonable and specified in sufficient detail to further interoperable implementation. The items below are listed in textual order of (first) appearance. (1) Terminology In the Abstract and in the 2nd paragraph of Section 1.1, the draft talks about "... textual data, encoded in Unicode, ...". IMO, this is stressing the IETF terminology on character sets and encodings, since "Unicode" -- despite its name -- is not regarded as a character set *encoding* per se. Instead, and actually, the draft specifies the use of a specific encoding format for Unicode, (a profile of) UTF-8, the Unicode Transformation Format preferred in the IETF and the contemporary Internet. Therefore, I suggest to substitute for the above quote (in both places) "... textual data, represented in Unicode and encoded in UTF-8, ...". (2) Section 1.3 YES, I appreciate the information in this section, and it seems to be very useful background information for all readers, and thus, I strongly recommend to keep this part of the memo, but drop the leading "Note in Draft" -- including the dangling reference to another discussion list, contrary to Section 1.5 (see below). (3) Section 1.4, 2nd paragraph I suggest to emphasize the key terms from RFC 959 by enclosing them in double quotes in the second sentence of this paragraph -- in the same style the RFC 2119 terms are presented in the first paragraph of this section. (4) Section 1.5 -- pointer to discussion list Since the draft apparently is prepared using xml2rfc, I suggest to make use of a specific property of the RFC 2629 format that produces an unnumbered mini-section on the draft front page to convey this information, instead of a numbered section deeply embedded in the document body -- thus putting this hint into a prominent place for the attention of readers. Thus, you might want to use the element within the part of the XML source of the draft to carry the pointer to the discussion list. (5) Addition to Section 2 -- likely Section 2.1 It might be wise to recall somewhere in the document, perhaps at the end of Section 2.1, that the effective choices for TYPE (and STRU) not only affect actual file transfers but also the processing by other commands, in particular the SIZE command [RFC3659]. (6) Section 2.4 and Section 5 Since Section 2.4 specifies an extension to FEAT usage for the "TYPE" command, it would make sense to have the "TYPE" entry in the "FTP Commands and Extensions" IANA registry amended by an additional reference to this document. To this end, I suggest to insert new text paragraph into Section 5 and use the precise name of the registry in the present text. For example: OLD: |5. IANA Considerations | | When this specification is approved, IANA is requested to add an | additional table to the FTP Extensions Registry established by RFC | 5797 [RFC5797]. That table should be titled "TYPE command arguments" | and should include "A (m) RFC 959", "E (o) RFC 959", "I (o) RFC 959", | "L (o) RFC 959", and "U (o) RFCNNNN". NEW: |5. IANA Considerations | | Upon approval of this specification, IANA is requested to perform / | has performed the following additions to the "FTP Commands and | Extensions" Registry established by RFC 5797 [RFC5797]. | | An additional reference to this RFC is added to the "TYPE" entry. | | Footnote [4] (pointed to by the "TYPE" entry) is amended to say: | | [4] FEAT String: TYPE {semicolon-separated list of supported types} | where the supported types are drawn from the TYPE arguments | listed in the sub-registry below | | An additional sub-registry and table titled "TYPE command arguments" | is added as follows, with a primary reference to this RFC, and | registration policy same as for the primary registry (per RFC 5797): | | TYPE conf Reference | argument | -------- -------- --------- | A m [RFC0959] | E o [RFC0959] | I o [RFC0959] | L o [RFC0959] | U o [RFCthis] (7) Section 7.1, Reference for ASCII Recently, RFC 20 has been used as the preferred reference for ASCII in contemporary RFCs. Maybe this choice could be adopted here. BTW (for my interest as an I-D author): How do you happen to include the additional note for a reference as shown in the [ASCII] entry in the draft, using xml2rfc ? (8) Section 7.2 -- reference update The rfc3536bis draft has been published as RFC 6365. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From internet-drafts@ietf.org Tue Mar 27 00:02:54 2012 Return-Path: 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 5171821F8743; Tue, 27 Mar 2012 00:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0prD4ptWjmW; Tue, 27 Mar 2012 00:02:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700D921F8738; Tue, 27 Mar 2012 00:02:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120327070253.15741.52583.idtracker@ietfa.amsl.com> Date: Tue, 27 Mar 2012 00:02:53 -0700 Cc: ftpext@ietf.org Subject: [ftpext] I-D Action: draft-ietf-ftpext2-hash-03.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:02:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FTP Extensions, 2nd edition Working G= roup of the IETF. Title : File Transfer Protocol HASH Command for Cryptographic Ha= shes Author(s) : Anthony Bryan Tim Kosse Daniel Stenberg Filename : draft-ietf-ftpext2-hash-03.txt Pages : 16 Date : 2012-03-27 The File Transfer Protocol does not offer any method to verify the integrity of a transferred file, nor can two files be compared against each other without actually transferring them first. Cryptographic hashes are a possible solution to this problem. In the past, several attempts have been made to add commands to obtain checksums and hashes, however none have been formally specified, leading to non-interoperability and confusion. To solve these issues, this document specifies a new FTP command to be used by clients to request cryptographic hashes of files. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ftpext2-hash-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ftpext2-hash-03.txt From presnick@qualcomm.com Fri Mar 30 02:45:57 2012 Return-Path: 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 66E6A21F8888 for ; Fri, 30 Mar 2012 02:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbJaev0xxZl0 for ; Fri, 30 Mar 2012 02:45:56 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id A3F4321F8873 for ; Fri, 30 Mar 2012 02:45:56 -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=1333100756; x=1364636756; h=message-id:date:from:user-agent:mime-version:to:subject: references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F7580CD.2020802@qualcomm.com>|Date:=20Fr i,=2030=20Mar=202012=2011:45:49=20+0200|From:=20Pete=20Re snick=20|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:=20|Subject:=20R e:=20[ftpext]=20WG=20Status|References:=20<8CC6BE90-16F4- 41DB-835B-B8BC9722156A@frobbit.se>=09<4F5E0B4F.2080401@at t.com>=20<8050883FA9D9EB809D8E848C@PST.JCK.COM>=20<4F5ED9 38.7090406@att.com>|In-Reply-To:=20<4F5ED938.7090406@att. com>|Content-Type:=20text/plain=3B=20charset=3D"ISO-8859- 1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.48.1]; bh=Aa9eScfhfBIzi3aOmaltdHXUksXMnkFcyJ2+j04rQu8=; b=TVDRmidXzZPjJoQzsZy3rfx8kVPwP5IPkoiNg3rqDlk1qLybRzJynKcK RO3P6yF0iHeIF/u8UGkouU+KxF/xIz+6SIrhhtCXl4/9Jt5ejC5awgD6y P8cDwwMVOyaIDgNuER8odu21cYbz0nkUqOFD4lTaPLnffqL0ON4F30Yey 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6664"; a="177263142" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 30 Mar 2012 02:45:53 -0700 X-IronPort-AV: E=Sophos;i="4.75,340,1330934400"; d="scan'208";a="183500426" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 30 Mar 2012 02:45:53 -0700 Received: from dhcp-25af.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 30 Mar 2012 02:45:53 -0700 Message-ID: <4F7580CD.2020802@qualcomm.com> Date: Fri, 30 Mar 2012 11:45:49 +0200 From: Pete Resnick 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: References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@PST.JCK.COM> <4F5ED938.7090406@att.com> In-Reply-To: <4F5ED938.7090406@att.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: Re: [ftpext] WG Status X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 09:45:57 -0000 On 3/13/12 6:20 AM, Tony Hansen wrote: > Pete Resnick, Anthony and I have also been discussing this very > question for some time. We've been trying some behind-the-scenes > efforts to get some more participation, but have had little success. > Frankly, Pete is ready to just pull the plug. > > Folks, if you care about this working group's existence, please speak > up now. Your thoughts are requested on the topics of: > > *) the group's existence > *) the HOST document > *) the TYPEU document just posted > > Thank you. If no one responds, be assured that the group will shut > down shortly. Though there was a small burst of posting in the last 2 weeks, there has not been enough participation to convince me that there is energy to sustain a WG effort. I've decided to close the WG. Documents that the WG was working on will be moved to individual documents and will be replaced with renamed documents (without the "draft-ietf-" name) if and when they are updated. If publication of these documents is desired, they will need to be published as individual submissions sponsored by an Area Director. The mailing list shall remain open for discussion of these documents and any other FTP work. Thanks to everyone (especially the chairs and document editors) for your efforts in getting this work to move forward. I think we may have more luck dealing with these documents in individual efforts. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From tony@att.com Fri Mar 30 17:41:57 2012 Return-Path: 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 77C1221F86A8 for ; Fri, 30 Mar 2012 17:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.007 X-Spam-Level: X-Spam-Status: No, score=-104.007 tagged_above=-999 required=5 tests=[AWL=-1.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ap0tu39IyGRl for ; Fri, 30 Mar 2012 17:41:56 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 70AC421F869C for ; Fri, 30 Mar 2012 17:41:56 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 4d2567f4.0.2171752.00-275.6075796.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 31 Mar 2012 00:41:56 +0000 (UTC) X-MXL-Hash: 4f7652d403f7a3c8-f04bacbf5d344429f37c97fbe3cb17fc42c9010e Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2V0ftE9001959 for ; Fri, 30 Mar 2012 20:41:55 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2V0fonx001924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Mar 2012 20:41:51 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Fri, 30 Mar 2012 20:41:27 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2V0fQN4027442 for ; Fri, 30 Mar 2012 20:41:26 -0400 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q2V0fK42027356 for ; Fri, 30 Mar 2012 20:41:21 -0400 Received: from [135.70.89.101] (vpn-135-70-89-101.vpn.swst.att.com[135.70.89.101]) by maillennium.att.com (mailgw1) with ESMTP id <20120331003829gw1004ormfe> (Authid: tony); Sat, 31 Mar 2012 00:38:29 +0000 X-Originating-IP: [135.70.89.101] Message-ID: <4F7652AD.3060201@att.com> Date: Fri, 30 Mar 2012 20:41:17 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: ftpext@ietf.org References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@PST.JCK.COM> <4F5ED938.7090406@att.com> <4F7580CD.2020802@qualcomm.com> In-Reply-To: <4F7580CD.2020802@qualcomm.com> Content-Type: multipart/alternative; boundary="------------050100060402040308020102" X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=Q1bhx3XkwJwA:10 a=ftvWwXIVLBAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=rg] X-AnalysisOut: [20VTZoIwHZLBIEA7AA:9 a=qHygi_KlYb0reWGHZd4A:7 a=wPNLvfGTeE] X-AnalysisOut: [IA:10 a=EUspDBNiAAAA:8 a=hHIpBUO25oDvo1Ll_QYA:9 a=RGxOev0W] X-AnalysisOut: [4maCPxSdSVMA:7 a=_W_S_7VecoQA:10 a=IG2fH9E8heMA:10] Subject: Re: [ftpext] WG Status X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 00:41:57 -0000 This is a multi-part message in MIME format. --------------050100060402040308020102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Well folks, we've officially shut the working group down. That does *not* mean that work on these drafts needs to die. First off, this mailing list will stay open indefinitely. (After all, it's the same list we used for the FTPEXT working group many years ago.) Second, Anthony and I are not abandoning you. We will continue to be available to help shepherd the drafts through the IETF process. However, the onus is shifting from the working group back to you, the individual. It is now *your* responsibility to push your documents forward. *IF* you care about your particular FTP extension draft, here is a way forward: 1) Repost your draft as an individual submission. Please use a name of "draft-YOURNAME-ftpext-TOPIC". 2) Please post a note to this mailing list about your updated document. 3) Solicit comments from people, particularly people who you know who either have implemented your extension or are willing to implement your extension. Also solicit comments from people who are good at looking for completeness of the specs and making sure that the nits are taken care of. 4) When you have at least 5 or 6 people who are willing to send an email to the mailing list saying that your document is ready to be published as an RFC, send an email message to Anthony and the mailing list asking for it to be published. 5) Anthony will work with me to fill out the proper shepherding forms to get the Area Directory to issue a IETF-wide last call process. Let the good times roll. Your (former) friendly neighborhood FTPEXT2 co-chairs Tony Hansen and Anthony Bryan On 3/30/2012 5:45 AM, Pete Resnick wrote: > > Though there was a small burst of posting in the last 2 weeks, there > has not been enough participation to convince me that there is energy > to sustain a WG effort. I've decided to close the WG. Documents that > the WG was working on will be moved to individual documents and will > be replaced with renamed documents (without the "draft-ietf-" name) if > and when they are updated. If publication of these documents is > desired, they will need to be published as individual submissions > sponsored by an Area Director. The mailing list shall remain open for > discussion of these documents and any other FTP work. > > Thanks to everyone (especially the chairs and document editors) for > your efforts in getting this work to move forward. I think we may have > more luck dealing with these documents in individual efforts. > > pr > --------------050100060402040308020102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well folks, we've officially shut the working group down. That does *not* mean that work on these drafts needs to die.

First off, this mailing list will stay open indefinitely. (After all, it's the same list we used for the FTPEXT working group many years ago.)

Second, Anthony and I are not abandoning you. We will continue to be available to help shepherd the drafts through the IETF process.

However, the onus is shifting from the working group back to you, the individual. It is now *your* responsibility to push your documents forward.

*IF* you care about your particular FTP extension draft, here is a way forward:

1) Repost your draft as an individual submission. Please use a name of "draft-YOURNAME-ftpext-TOPIC".
2) Please post a note to this mailing list about your updated document.
3) Solicit comments from people, particularly people who you know who either have implemented your extension or are willing to implement your extension. Also solicit comments from people who are good at looking for completeness of the specs and making sure that the nits are taken care of.
4) When you have at least 5 or 6 people who are willing to send an email to the mailing list saying that your document is ready to be published as an RFC, send an email message to Anthony and the mailing list asking for it to be published.
5) Anthony will work with me to fill out the proper shepherding forms to get the Area Directory to issue a IETF-wide last call process.

Let the good times roll.

    Your (former) friendly neighborhood FTPEXT2 co-chairs
    Tony Hansen and Anthony Bryan


On 3/30/2012 5:45 AM, Pete Resnick wrote:

Though there was a small burst of posting in the last 2 weeks, there has not been enough participation to convince me that there is energy to sustain a WG effort. I've decided to close the WG. Documents that the WG was working on will be moved to individual documents and will be replaced with renamed documents (without the "draft-ietf-" name) if and when they are updated. If publication of these documents is desired, they will need to be published as individual submissions sponsored by an Area Director. The mailing list shall remain open for discussion of these documents and any other FTP work.

Thanks to everyone (especially the chairs and document editors) for your efforts in getting this work to move forward. I think we may have more luck dealing with these documents in individual efforts.

pr

--------------050100060402040308020102-- From john-ietf@jck.com Fri Mar 30 18:56:20 2012 Return-Path: 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 22E4721F85CF for ; Fri, 30 Mar 2012 18:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.681 X-Spam-Level: X-Spam-Status: No, score=-102.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgvjMQbIg8Kw for ; Fri, 30 Mar 2012 18:56:19 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 72A3121F85C4 for ; Fri, 30 Mar 2012 18:56:19 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SDnTN-000DTz-Ct; Fri, 30 Mar 2012 21:51:21 -0400 Date: Fri, 30 Mar 2012 21:56:13 -0400 From: John C Klensin To: Tony Hansen , ftpext@ietf.org Message-ID: <47AD9A4DA948CB38636CB5EE@PST.JCK.COM> In-Reply-To: <4F7652AD.3060201@att.com> References: <8CC6BE90-16F4-41DB-835B-B8BC9722156A@frobbit.se> <4F5E0B4F.2080401@att.com> <8050883FA9D9EB809D8E848C@PST.JCK.COM> <4F5ED938.7090406@att.com> <4F7580CD.2020802@qualcomm.com> <4F7652AD.3060201@att.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 is now draft-klensin-ftpext-typeu X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 01:56:20 -0000 Hi, Per Tony's "WG Status" note of about an hour ago, I've reissued the "TYPE U" draft with the name draft-klensin-ftpext-typeu. This is identical to draft-ietf-ftpext2-typeu except for * The file name * The date * A revised description of the mailing list on which the draft is being discussed * Removal of the name of the FTPEXT2 Working Group * A new change log section that provides a backtrace. Quid Pro Quo offer: I'll review yours if you will either review or implement mine :-). Note that a valid minimal implementation of this extension for systems that use Unicode internally and already support conversion of whatever encoding is used internally to and from UTF-8 for on the wire use consists of: * Advertising the extension if one is a server and receives a FEAT command. * Sending the extended TYPE request if one is a client * Ensuring that lines end with CRLF if one is a sender (note that the relevant code for this purpose is in any implementation that supports TYPE A). One should also normalize to NFC, but that is not required (the spec deliberately says "SHOULD...if at all possible", not MUST). Note also that any data stream that is valid for TYPE A is also value for TYPE U. Systems that do not support Unicode natively would have to do some potentially-significant conversions to support this command; they are not candidates for a trivial implementation unless appropriate tools already exist or are easily adapted. best, john