From evnikita2@gmail.com Sun Jul 3 21:39:05 2011 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 1467C1F0C73 for ; Sun, 3 Jul 2011 21:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+X11SgAbHlb for ; Sun, 3 Jul 2011 21:39:04 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2873B1F0C83 for ; Sun, 3 Jul 2011 21:39:03 -0700 (PDT) Received: by fxe4 with SMTP id 4so5900468fxe.27 for ; Sun, 03 Jul 2011 21:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kSMK7NR9HUDBek3gBwv1YFMnOgmcGgLod1u7wXwmcMk=; b=WT9vDgSDqWs2KGFCrs8FCiqWUiDHXLQFjQncDVFYrfwZYvl6ekkVcXqyV3CHAr05vw B45TKmbrQYQZ/h1eGnbuSPG1r16GqpsWuPIKAW64QhAt3RKeoXPjDuIzMb/P45WyVlpo wX/8PBReDyPnsMVchaUIeq3kNjUTD1n5DlkCM= Received: by 10.223.145.2 with SMTP id b2mr8927308fav.99.1309754342994; Sun, 03 Jul 2011 21:39:02 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id q14sm4242496faa.27.2011.07.03.21.39.01 (version=SSLv3 cipher=OTHER); Sun, 03 Jul 2011 21:39:01 -0700 (PDT) Message-ID: <4E114414.3070908@gmail.com> Date: Mon, 04 Jul 2011 07:39:48 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: John C Klensin References: <20110620160631.14534.46793.idtracker@ietfa.amsl.com> <4E02B7C3.10402@gmail.com> In-Reply-To: <4E02B7C3.10402@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ftpext@ietf.org Subject: Re: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-01.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, 04 Jul 2011 04:39:05 -0000 John, Sorry for being a bit curious, but did my comments (http://www.ietf.org/mail-archive/web/ftpext/current/msg00353.html) arrive to you? Are you going to consider some (if any) of them? M. Yevstifeyev 23.06.2011 6:49, Mykyta Yevstifeyev wrote: > Hello John, all, > > I'd like to comment the new revision of draft-ietf-ftpext2-typeu, > which was uploaded on 20 June. > > [ . . . ] > From evnikita2@gmail.com Sun Jul 3 21:53:42 2011 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 8A22D21F84F9 for ; Sun, 3 Jul 2011 21:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToE3lqYBdQPU for ; Sun, 3 Jul 2011 21:53:42 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id CB75321F850B for ; Sun, 3 Jul 2011 21:53:41 -0700 (PDT) Received: by fxe4 with SMTP id 4so5906650fxe.27 for ; Sun, 03 Jul 2011 21:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=R+5y57hee/BHc+tQ9ev7z53OkCTRKKqs7QDyHvqfwUc=; b=yHS4ShrUPFBHU21e8tw7tKS8V9/eHXoZAWFsKWp7qYouQlXz1bQ2M5DSOTruQHt5hv 6HRO8yVLevuZlFY3cYrJFlWMdYiU70/a6uGfz5jvy56yr907WdxwQxpxOqqPsG1xAYOO dObw11xOwFCV0n9reX8QhW+LlUrmctBMkc5Zw= Received: by 10.223.145.144 with SMTP id d16mr8982327fav.100.1309755220921; Sun, 03 Jul 2011 21:53:40 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id h1sm4246790fag.35.2011.07.03.21.53.39 (version=SSLv3 cipher=OTHER); Sun, 03 Jul 2011 21:53:40 -0700 (PDT) Message-ID: <4E114782.4020404@gmail.com> Date: Mon, 04 Jul 2011 07:54:26 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "ftpext@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [ftpext] FWD: I-D Action: draft-yevstifeyev-foobar-to-historic-00.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, 04 Jul 2011 04:53:42 -0000 FYI. Any comments are welcome. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Moving RFC 1545 and RFC 1639 to Historic > Author(s) : Mykyta Yevstifeyev > Filename : draft-yevstifeyev-foobar-to-historic-00.txt > Pages : 4 > Date : 2011-07-03 > > RFC 1639 and its predecessor - RFC 1545 - specified the way to denote > network addresses in the format other than that used with IPv4 when > establishing File Transfer Protocol (FTP) data connection. Because > of some reasons, described in this document, these commands are now > deprecated and their use is discouraged; in order to reflect this it > moves RFC 1545 and RFC 1639 to Historic status and obsoletes these > two RFCs. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yevstifeyev-foobar-to-historic-00.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-yevstifeyev-foobar-to-historic-00.txt From maxpassion@gmail.com Sun Jul 3 22:04:57 2011 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 3479121F855F for ; Sun, 3 Jul 2011 22:04: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcGsp7ovdJXI for ; Sun, 3 Jul 2011 22:04:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 878BF21F8560 for ; Sun, 3 Jul 2011 22:04:56 -0700 (PDT) Received: by iye7 with SMTP id 7so5185250iye.31 for ; Sun, 03 Jul 2011 22:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FxyqPcz/0gs8ySG7IQ9fH7UQhCSpQ63x+g7+BHa8GCI=; b=BFG6+z+QbfjCqJms+kHvdvROhhc7PvjdOtSdCdQUG4VCYgvyIfsU6Z1gUIfslxZmVm 6s8h+n3VyiU2QFW+ZJVupiLidLk7YuHMwN1EQFcXEqQatyWv9hgnIh91Kdzf5cvYHTrH bssQpz6umdcto9VvkmxG3n8eTcK6ujV4jo+gc= MIME-Version: 1.0 Received: by 10.42.19.2 with SMTP id z2mr1187673ica.498.1309755895831; Sun, 03 Jul 2011 22:04:55 -0700 (PDT) Received: by 10.231.115.8 with HTTP; Sun, 3 Jul 2011 22:04:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Jul 2011 13:04:55 +0800 Message-ID: From: liu dapeng To: Robert Oslin Content-Type: text/plain; charset=ISO-8859-1 Cc: "ftpext@ietf.org" Subject: Re: [ftpext] draft-ietf-ftpext2-ftp64-00 translation scenario 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, 04 Jul 2011 05:04:57 -0000 Hi Robert, Thanks for the comments. 2011/1/18, Robert Oslin : > This draft makes the case for how an IPv6 FTP client should behave when > processing an IPv4 FTP Server PASV/PORT reply when going from an IPv6 > network through a translation device. > > In general I'm in favor of "client intelligence"*, and I don't see that it > explicitly violates RFC959 in terms of handling the PASV response, although > it does so implicitly since the client should be using the IP and port > provided in the server reply. > > My point of contention is this: Why an RFC at all? Unless I'm mistaken, > translation, such as NAT-PT, BIS, BIA, etc. has been moved to experimental > status, as translation should be considered a "last resort" when other IPv6 > transition options are unavailable (dual stack, tunneling, etc.). ==> Actually, in Behave working group, NAT64 (RFC6146 ) is intend to be standard track. Besides, in IPv4/IPv6 transition period, there would be IPv6 client access IPv4 server scenario, that is why IETF specifies NAT64. > ~~~ > > *Clients should do this today in an IPv4 world if for example a PASV reply > contains network address prefix, e.g. 192.168.0.0/16, which can happen if > using encrypted communications and going though NAT and the server hasn't > configured the "external" facing IP (And since the session is encrypted, NAT > can't see the address to change it). The client should identify this (and > similar) wrong IPs and reuse the control connection's IP. ==> That is a valide scenario, I will include this in the updated version. Thanks! Best regards, Dapeng Liu > Robert Oslin > Director of Product Management > Tel: 1 (210) 293-7902 > Fax: 1 (210) 690-8824 > Send me large files securely > > www.globalscape.com > > (NYSE Amex:GSB) > *This communication, including attachments, is for the exclusive use of the > addressee and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, any use, copying, > disclosure, dissemination or distribution is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately by return > email and delete this communication and destroy all copies. > > > _______________________________________________ > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext > -- ------ Best Regards, Dapeng Liu From wmaton@ottix.net Mon Jul 4 06:17:02 2011 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 EDCB79E8008 for ; Mon, 4 Jul 2011 06:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZatZyfuv9wtE for ; Mon, 4 Jul 2011 06:17:02 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [192.231.228.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4019E8005 for ; Mon, 4 Jul 2011 06:17:00 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id p64DGZdp024278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jul 2011 09:16:35 -0400 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id p64DGZIR024275; Mon, 4 Jul 2011 09:16:35 -0400 Date: Mon, 4 Jul 2011 09:16:35 -0400 (EDT) From: "William F. Maton" To: Mykyta Yevstifeyev In-Reply-To: <4E114782.4020404@gmail.com> Message-ID: References: <4E114782.4020404@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ftpext@ietf.org" Subject: Re: [ftpext] FWD: I-D Action: draft-yevstifeyev-foobar-to-historic-00.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, 04 Jul 2011 13:17:03 -0000 I think based on just very recent discussions, this may be something whose time has come. Thanks for writing this! On Mon, 4 Jul 2011, Mykyta Yevstifeyev wrote: > FYI. Any comments are welcome. > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Moving RFC 1545 and RFC 1639 to Historic >> Author(s) : Mykyta Yevstifeyev >> Filename : draft-yevstifeyev-foobar-to-historic-00.txt >> Pages : 4 >> Date : 2011-07-03 >> >> RFC 1639 and its predecessor - RFC 1545 - specified the way to denote >> network addresses in the format other than that used with IPv4 when >> establishing File Transfer Protocol (FTP) data connection. Because >> of some reasons, described in this document, these commands are now >> deprecated and their use is discouraged; in order to reflect this it >> moves RFC 1545 and RFC 1639 to Historic status and obsoletes these >> two RFCs. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-yevstifeyev-foobar-to-historic-00.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-yevstifeyev-foobar-to-historic-00.txt > > _______________________________________________ > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext > wfms From evnikita2@gmail.com Thu Jul 7 07:53:30 2011 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 67DB921F8759; Thu, 7 Jul 2011 07:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5Jj6n5cA9-e; Thu, 7 Jul 2011 07:53:29 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2305621F8751; Thu, 7 Jul 2011 07:53:28 -0700 (PDT) Received: by bwb17 with SMTP id 17so1082502bwb.31 for ; Thu, 07 Jul 2011 07:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=FCiAl4+tB6tIqO19supqHKDVppYOyXVVzIU1KJsiC5U=; b=oLmrpu00E6oLmINS/Jtr/zZXpsM2SuKtMWIoUXE7/K5dcPG/QqXJYKfa3CCV7jUgu8 OL6nzOTYri5SJZliBWs7g0+x0AX11m9JXtPb2KM0vtpuhKWnhcfYAo1XS6LuzgLGKBPI IuCx3qvBOMNzah8jPdNkr9snLvz97gSBwHqoA= Received: by 10.204.37.141 with SMTP id x13mr807313bkd.116.1310050408128; Thu, 07 Jul 2011 07:53:28 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id k5sm8610455bka.17.2011.07.07.07.53.26 (version=SSLv3 cipher=OTHER); Thu, 07 Jul 2011 07:53:27 -0700 (PDT) Message-ID: <4E15C895.6020701@gmail.com> Date: Thu, 07 Jul 2011 17:54:13 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "ftpext@ietf.org" , "uri-review@ietf.org" , URI , Apps-discuss list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [ftpext] Fwd: I-D Action: draft-yevstifeyev-ftp-uri-scheme-04.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: Thu, 07 Jul 2011 14:53:30 -0000 I've just uploaded a new version of draft-yevstifeyev-ftp-uri-scheme. Any further comments are welcome. Mykyta > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : The'ftp' URI Scheme > Author(s) : Mykyta Yevstifeyev > Filename : draft-yevstifeyev-ftp-uri-scheme-04.txt > Pages : 22 > Date : 2011-07-07 > > This document specifies the'ftp' Uniform Resource Identifier (URI) > scheme, which is used to refer to resources accessible via File > Transfer Protocol (FTP). It updates RFC 959 and RFC 1738. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-04.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-yevstifeyev-ftp-uri-scheme-04.txt From evnikita2@gmail.com Thu Jul 7 20:45:02 2011 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 26C3A21F8686 for ; Thu, 7 Jul 2011 20:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP0uBUyB058N for ; Thu, 7 Jul 2011 20:45:01 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF3721F8663 for ; Thu, 7 Jul 2011 20:45:01 -0700 (PDT) Received: by fxe4 with SMTP id 4so2143807fxe.27 for ; Thu, 07 Jul 2011 20:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=+iYoPSk78QA3kNmRsXvMIOJm7EKrc71LpW9MgmAjeBE=; b=RD7tQ5xd8w/ewNlX/rjnDt0GWOcMLEMoGouoOWMRkT/w5Vnnsu4nJe/tbzDcENsFL0 nxC7lAeEtMHV8gbCyS8rfrwhxwFs8TPwiOLABh50r5HoRyKzqog8ykWKOa0BiiRHv1zK qwL2/CxudNu7aun45E3umf1dmJYDxm24inyAs= Received: by 10.223.20.154 with SMTP id f26mr2359237fab.104.1310096700426; Thu, 07 Jul 2011 20:45:00 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id h28sm7104096faj.5.2011.07.07.20.44.59 (version=SSLv3 cipher=OTHER); Thu, 07 Jul 2011 20:44:59 -0700 (PDT) Message-ID: <4E167D6A.4040708@gmail.com> Date: Fri, 08 Jul 2011 06:45:46 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "ftpext@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [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: Fri, 08 Jul 2011 03:45:02 -0000 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 From internet-drafts@ietf.org Sun Jul 10 19:18:24 2011 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 CC34521F887C; Sun, 10 Jul 2011 19:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVuDjYTEkOFc; Sun, 10 Jul 2011 19:18:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D7121F881B; Sun, 10 Jul 2011 19:18:24 -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: 3.55 Message-ID: <20110711021824.28949.30520.idtracker@ietfa.amsl.com> Date: Sun, 10 Jul 2011 19:18:24 -0700 Cc: ftpext@ietf.org Subject: [ftpext] I-D Action: draft-ietf-ftpext2-ftp64-01.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, 11 Jul 2011 02:18:24 -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 extension for IPv4/IPv6 transition Author(s) : Dapeng Liu Iljitsch van Beijnum Zhen Cao Filename : draft-ietf-ftpext2-ftp64-01.txt Pages : 7 Date : 2011-07-10 The File transfer protocol, which is defined by the RFC 959, has a long history, but still being widely used. The original version of FTP specification defines IPv4 version of FTP. RFC 2428 defines IPv6 extensions of FTP, introducingEPRT and EPSV command. In the IPv6- IPv4 translation scenario, considerations should be applied to FTP client, server and translation box to ensure FTP protocol work properly. This document discusses the details for FTP to work in IPv4-IPv6 transitiion scenario. This document proposes to update IPv6 FTP client's specification to make it easier to work in 6to4 scenario. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ftpext2-ftp64-01.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-ftp64-01.txt From john-ietf@jck.com Sun Jul 10 19:58:20 2011 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 3820B21F8650 for ; Sun, 10 Jul 2011 19:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kKAt09FQJBP for ; Sun, 10 Jul 2011 19:58:19 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9C53C21F8605 for ; Sun, 10 Jul 2011 19:58:19 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qg6hP-000HBP-3Y for ftpext@ietf.org; Sun, 10 Jul 2011 22:58:19 -0400 Date: Sun, 10 Jul 2011 22:58:18 -0400 From: John C Klensin To: ftpext@ietf.org Message-ID: <307F6EAD43104B7DB589F155@PST.JCK.COM> In-Reply-To: <20110711021824.28949.30520.idtracker@ietfa.amsl.com> References: <20110711021824.28949.30520.idtracker@ietfa.amsl.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: Re: [ftpext] I-D Action: draft-ietf-ftpext2-ftp64-01.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, 11 Jul 2011 02:58:20 -0000 > The File transfer protocol, which is defined by the RFC > 959, has a long history, but still being widely used. The > original version of FTP specification defines IPv4 version > of FTP. This is obviously not a big deal --I'll have more real comments on the draft later-- but the above statement from the abstract is unquestionably false. The original version of the FTP specification was published in April 1971 in RFC 114, long before IPv4 was even imagined. It defined the NCP version of FTP for the ARPANET. -- john (Aka cranky old guy who was somewhat involved in the original design and who has been using FTP since 1971) From evnikita2@gmail.com Sun Jul 10 20:48:23 2011 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 90F9521F88A0 for ; Sun, 10 Jul 2011 20:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuwZLxp4WXAr for ; Sun, 10 Jul 2011 20:48:23 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id BBAAB21F889F for ; Sun, 10 Jul 2011 20:48:22 -0700 (PDT) Received: by fxe4 with SMTP id 4so4500673fxe.27 for ; Sun, 10 Jul 2011 20:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bhz2ep5ndzW/+en10eraVjhp/RyHqPaYLOE3vKct6zo=; b=Idlwm2pq+FqJxUACqavLes8UyCpruYar6fwiullA5LKmWkZiP9aA/Vm9QuNe43lCmR DslXBX3oGWwRVv71OEhuubZJnCYi1ODNIzrmWMhnIU7cBrGCto9ViGawxv+NVyMEWEx3 XN8qmNcbY4Tx+76Ng3ipxp3+s0oAlT+BGB1lc= Received: by 10.223.13.211 with SMTP id d19mr6848352faa.67.1310356101807; Sun, 10 Jul 2011 20:48:21 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id h26sm916239faj.35.2011.07.10.20.48.19 (version=SSLv3 cipher=OTHER); Sun, 10 Jul 2011 20:48:20 -0700 (PDT) Message-ID: <4E1A72B2.3030202@gmail.com> Date: Mon, 11 Jul 2011 06:49:06 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ftpext@ietf.org References: <20110711021824.28949.30520.idtracker@ietfa.amsl.com> <307F6EAD43104B7DB589F155@PST.JCK.COM> In-Reply-To: <307F6EAD43104B7DB589F155@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ftpext] I-D Action: draft-ietf-ftpext2-ftp64-01.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, 11 Jul 2011 03:48:23 -0000 11.07.2011 5:58, John C Klensin wrote: >> The File transfer protocol, which is defined by the RFC >> 959, has a long history, but still being widely used. The >> original version of FTP specification defines IPv4 version >> of FTP. > This is obviously not a big deal --I'll have more real comments > on the draft later-- but the above statement from the abstract > is unquestionably false. +1 > > The original version of the FTP specification was published in > April 1971 in RFC 114, long before IPv4 was even imagined. It > defined the NCP version of FTP for the ARPANET. Actually this is true. The first document which specified FTP as we currently know it was RFC 354, though. But the concept was set in RFC 114. Mykyta > > -- john > (Aka cranky old guy who was somewhat involved in the > original design and who has been using FTP since 1971) > > _______________________________________________ > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext > From internet-drafts@ietf.org Sun Jul 10 22:01:28 2011 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 2329E21F88E4; Sun, 10 Jul 2011 22:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPzvUFf697JU; Sun, 10 Jul 2011 22:01:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B063E21F8687; Sun, 10 Jul 2011 22:01:27 -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: 3.55 Message-ID: <20110711050127.13929.50068.idtracker@ietfa.amsl.com> Date: Sun, 10 Jul 2011 22:01:27 -0700 Cc: ftpext@ietf.org Subject: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-02.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, 11 Jul 2011 05:01:28 -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-02.txt Pages : 11 Date : 2011-07-10 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 bec= omes 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-02.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-02.txt From john-ietf@jck.com Sun Jul 10 22:02:27 2011 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 73CFB21F8870 for ; Sun, 10 Jul 2011 22:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWciE9iMddgE for ; Sun, 10 Jul 2011 22:02:26 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7865B21F8828 for ; Sun, 10 Jul 2011 22:02:26 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qg8dV-000JBw-ID; Mon, 11 Jul 2011 01:02:25 -0400 Date: Mon, 11 Jul 2011 01:02:24 -0400 From: John C Klensin To: Mykyta Yevstifeyev Message-ID: <6F976528673B234FA96F687F@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] I-D Action: draft-ietf-ftpext2-typeu-01.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, 11 Jul 2011 05:02:27 -0000 --On Monday, July 04, 2011 07:39 +0300 Mykyta Yevstifeyev wrote: > John, > > Sorry for being a bit curious, but did my comments > (http://www.ietf.org/mail-archive/web/ftpext/current/msg00353. > html) arrive to you? Are you going to consider some (if any) > of them? I hadn't gotten to it -- I've been preoccupied with a few other things as those who follow the rfc-interest list may have figured out. Thanks for the comments and the reminder. A new version is now in the posting queue. I don't think I've made any of the changes exactly as you suggested, but think I've now addressed most of them. As an example of the reasons for the difference between what you suggested and what I did, "data type" is a horribly ambiguous term. RFC 959 carefully distinguishes between "Representation Type" and "File Structure" either of which could be considered "data type" information. So I tried to clarify things as you suggested while staying very close to traditional FTP terminology. I haven't taken out the user-PI, etc., terms because the text says "if used here". They might be worth taking out when the WG is otherwise finished with the document, but not now. > Why not completely replace server-FTP process and user-FTP > process with server and client, respectively, within the whole > document at all? Well, because I learned several things in the transition from RFC 821 (which, like FTP, used Jon Postel's terminology and BNF) to RFC 2821 (which used ABNF). One of them was that Jon wrote protocol specifications with a much higher degree of precision than is typical in the iETF today. In 2821 (and 5321), it was sometimes necessary to use Jon's historical "sender" and "receiver" terminology because client-server terminology can get confusing or ambiguous when one is talking, e.g., about relay hosts who act as both. With FTP, the separation of control and data connections will sometimes require careful identification of USER-PI, SERVER-PI, server-DTP and user-DTP, and so on. The fact that I've managed to construct a draft for TYPE U without needing those distinctions is no guarantee that we won't need them before the specification is approved. And, if I were to give general advice to the WG at this point, it would be to try to stick to the terminology of RFC 959 rather than trying to retrofit "modern" terminology. If I were writing this draft for the first time today, I would not have bothered with that sentence about convenience at all, but I acknowledge that it is somewhat a matter of taste. > For the reader's convenience, the reference to some material > concerning EBCDIC could be provided The sentence refers to RFC 959, which ought to be sufficient. While it doesn't provide references for EBCDIC the reality today is that anyone who doesn't know what it means almost certainly doesn't care and will never care. Worse, the authoritative references are hard to find and access today, so incorporating them in the document wouldn't do much good. >> If it does, the server MAY > Probably SHOULD or SHALL is more appropriate here; what is an > other way to indicate that U data type isn't supported, in > this case? The sentence is correct as written. Support for the feature is optional, so the server MAY support it. If it doesn't, or doesn't want to provide that service to a particular user, it returns 504. Otherwise, there is a firm requirement ("MUST") about what it does. best, john From evnikita2@gmail.com Mon Jul 11 01:30:38 2011 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 0C13621F8A00 for ; Mon, 11 Jul 2011 01:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wdiAN3nxoo7 for ; Mon, 11 Jul 2011 01:30:37 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA43921F89B8 for ; Mon, 11 Jul 2011 01:30:36 -0700 (PDT) Received: by bwb17 with SMTP id 17so3552818bwb.31 for ; Mon, 11 Jul 2011 01:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8BRP96L4N0Hc2YkvwdfBoo3qO3EPih9H33ZhZSbi6MI=; b=LeU8JdtRzbez4KQ7E0GVR1n1XeA8IGuUU6MeDJJkG8j5SxstiPFmGat4NRHGu8ZWqU vheCqbUBhUQkEOd9b6cCWNDilr325ZQx0ejb409ievUWBpTJayJSLUUx3Y2WgQkYGAu3 zWwgiLinrghfKn0IAc4ApIK1+DdYpkJEDZ5Xc= Received: by 10.204.135.211 with SMTP id o19mr859481bkt.63.1310373035812; Mon, 11 Jul 2011 01:30:35 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id u32sm946515bkk.49.2011.07.11.01.30.33 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 01:30:34 -0700 (PDT) Message-ID: <4E1AB4D8.1090808@gmail.com> Date: Mon, 11 Jul 2011 11:31:20 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: John C Klensin References: <6F976528673B234FA96F687F@PST.JCK.COM> In-Reply-To: <6F976528673B234FA96F687F@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ftpext@ietf.org Subject: Re: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-01.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, 11 Jul 2011 08:30:38 -0000 11.07.2011 8:02, John C Klensin wrote: > > --On Monday, July 04, 2011 07:39 +0300 Mykyta Yevstifeyev > wrote: > >> John, >> >> Sorry for being a bit curious, but did my comments >> (http://www.ietf.org/mail-archive/web/ftpext/current/msg00353. >> html) arrive to you? Are you going to consider some (if any) >> of them? > I hadn't gotten to it -- I've been preoccupied with a few other > things as those who follow the rfc-interest list may have > figured out. I see what you mean. > > Thanks for the comments and the reminder. A new version is now > in the posting queue. Yes, I've seen the new revision of the document. Please see my responses in-lime below. > > I don't think I've made any of the changes exactly as you > suggested, but think I've now addressed most of them. > > As an example of the reasons for the difference between what you > suggested and what I did, "data type" is a horribly ambiguous > term. RFC 959 carefully distinguishes between "Representation > Type" and "File Structure" either of which could be considered > "data type" information. So I tried to clarify things as you > suggested while staying very close to traditional FTP > terminology. The current terminology seems mostly fine. Those corrections which you have made with respect to "data type" etc. deal with my concern. > > I haven't taken out the user-PI, etc., terms because the text > says "if used here". They might be worth taking out when the WG > is otherwise finished with the document, but not now. I have no strong position/objections regarding this. > > >> Why not completely replace server-FTP process and user-FTP >> process with server and client, respectively, within the whole >> document at all? > Well, because I learned several things in the transition from > RFC 821 (which, like FTP, used Jon Postel's terminology and BNF) > to RFC 2821 (which used ABNF). One of them was that Jon wrote > protocol specifications with a much higher degree of precision > than is typical in the iETF today. In 2821 (and 5321), it was > sometimes necessary to use Jon's historical "sender" and > "receiver" terminology because client-server terminology can get > confusing or ambiguous when one is talking, e.g., about relay > hosts who act as both. With FTP, the separation of control and > data connections will sometimes require careful identification > of USER-PI, SERVER-PI, server-DTP and user-DTP, and so on. The > fact that I've managed to construct a draft for TYPE U without > needing those distinctions is no guarantee that we won't need > them before the specification is approved. And, if I were to > give general advice to the WG at this point, it would be to try > to stick to the terminology of RFC 959 rather than trying to > retrofit "modern" terminology. If I were writing this draft for > the first time today, I would not have bothered with that > sentence about convenience at all, but I acknowledge that it is > somewhat a matter of taste. So I withdraw this concern. If the reader is acquainted with RFC 959 terminology, this won't be a problem for them. > > >> For the reader's convenience, the reference to some material >> concerning EBCDIC could be provided > The sentence refers to RFC 959, which ought to be sufficient. > While it doesn't provide references for EBCDIC the reality today > is that anyone who doesn't know what it means almost certainly > doesn't care and will never care. Worse, the authoritative > references are hard to find and access today, so incorporating > them in the document wouldn't do much good. Your arguments are quite reasonable here; so I don't insist. > > >>> If it does, the server MAY >> Probably SHOULD or SHALL is more appropriate here; what is an >> other way to indicate that U data type isn't supported, in >> this case? > The sentence is correct as written. Support for the feature is > optional, so the server MAY support it. If it doesn't, or > doesn't want to provide that service to a particular user, it > returns 504. Otherwise, there is a firm requirement ("MUST") > about what it does. I personally think the sentence where these regulations are placed needs clarifying a bit, but I don't think it will be incorrect if left as-is. I also have several comments to new IANA considerations which I'll send in a separate message. Mykyta > > best, > john > > From evnikita2@gmail.com Mon Jul 11 01:42:59 2011 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 B300221F8891 for ; Mon, 11 Jul 2011 01:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5uoTfcS0pS2 for ; Mon, 11 Jul 2011 01:42:59 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE88E21F887C for ; Mon, 11 Jul 2011 01:42:58 -0700 (PDT) Received: by bwb17 with SMTP id 17so3561595bwb.31 for ; Mon, 11 Jul 2011 01:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=u9SZ5Pnt5zkS3LYs1kx1sI/5ovGbHgUGR50xK1ctGCU=; b=vA92YUrAjrIXoZK9JwmDvgwjN7hqXXnIBHL/dbRd525/Nvtts7mN1TN5iujiXreSO6 LWeIeGicq+CQg8YrSuo6RZOheMgEoarvi2WMPUUAFyfzYTLPi+3ksgxg2LsgcLVad0Hl dRPHl/UYruajyFPTK0MQUBMNPB4bhdLiia/Ns= Received: by 10.205.64.197 with SMTP id xj5mr1401570bkb.407.1310373777456; Mon, 11 Jul 2011 01:42:57 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id d12sm512809bke.12.2011.07.11.01.42.56 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 01:42:56 -0700 (PDT) Message-ID: <4E1AB7BE.7020307@gmail.com> Date: Mon, 11 Jul 2011 11:43:42 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ftpext@ietf.org References: <20110711050127.13929.50068.idtracker@ietfa.amsl.com> In-Reply-To: <20110711050127.13929.50068.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-02.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, 11 Jul 2011 08:42:59 -0000 As I mentioned in my previous message, I have several comments on new IANA considerations, which follow. The current Section 5 is: > 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". First, this sections doesn't mention clearly what is the new "table". I suppose you wanted a new sub-registry. In this case it really lacks a number of information required by RFC 5226. This includes: (1) what is the format of the sub-registry (I guess this should be "TYPE parameter", "conformance" and "reference"). Probably we can also create the separate column entitled "2nd parameter" and corresponding possible values "allowed/not-allowed"; (2) what is the addition policy for the new entries (I suppose this should be "IETF Consensus" or "RFC Required"; I think the 1st is better). (3) see also bullet 2 of Section 4.2 of RFC 5226. Moreover, I think creating the registry should be done by the separate document, whereas your one should only register the corresponding value in it. This will be clearer a bit, IMO. Yet, I don't insist much on this particular issue. Mykyta 11.07.2011 8:01, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FTP Extensions, 2nd edition Working Group of the IETF. > > Title : FTP TYPE Extension for Internationalized Text > Author(s) : John C Klensin > Filename : draft-ietf-ftpext2-typeu-02.txt > Pages : 11 > Date : 2011-07-10 > > From evnikita2@gmail.com Mon Jul 11 02:09:05 2011 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 F090021F875E for ; Mon, 11 Jul 2011 02:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_PROLOSTOCK_SYM3=1.63] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM0gZOIcePd3 for ; Mon, 11 Jul 2011 02:09:05 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0628321F86EE for ; Mon, 11 Jul 2011 02:09:04 -0700 (PDT) Received: by bwb17 with SMTP id 17so3580707bwb.31 for ; Mon, 11 Jul 2011 02:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8hGSJ3NKLYBCR0Ex/YNK6Aw9UQD4t2bvADEvbLDsyO0=; b=CLxsqM+kPmxOivxmcM9u+w8+54nbq5tCxQBtDAW0CdRVx0dAHpGHbes/Kd/NywtMLo 6Z2afXICDuY35U4WVvUtnrukhrTMD+91ea0eYqRrzHge5gVpu5yDxkSmuCcCui5vK1Af mjA3a5hR80jU6FkQiod/2yZhkANX5ghbCyY64= Received: by 10.204.17.8 with SMTP id q8mr1019462bka.77.1310375342418; Mon, 11 Jul 2011 02:09:02 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id o25sm963470bkf.18.2011.07.11.02.09.00 (version=SSLv3 cipher=OTHER); Mon, 11 Jul 2011 02:09:01 -0700 (PDT) Message-ID: <4E1ABDDB.1090707@gmail.com> Date: Mon, 11 Jul 2011 12:09:47 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ftpext@ietf.org References: <20110711021824.28949.30520.idtracker@ietfa.amsl.com> In-Reply-To: <20110711021824.28949.30520.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ftpext] I-D Action: draft-ietf-ftpext2-ftp64-01.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, 11 Jul 2011 09:09:06 -0000 Hello, I'd like to provide some comments on this draft. (Sorry John if I hijack some of what you wanted to say.) > RFC 2428 defines IPv6 > extensions of FTP, introducing EPRT and EPSV command. The EPRT and EPSV commands are really scoped mainly to IPv6 addresses, but not only. It uses the RIP address family identifier (http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xml) to allow addresses in the format other that used with IPv4. So I think the aforementioned statement should be corrected. The same applies to Introduction. Section 1: > It should be noted that in some scenario, the FTP client that running > on the IPv6 host maybe legacy IPv4 FTP client. There is no explicit explanation of what does the "legacy IPv4 FTP client" mean. Moreover, no explicit statement on what should be considered to be "IPv4/IPv6 client/server" is provided as well. Section 5: > This document argues that since FTP is a protocol that could avoid > ALG by slightly adjusting the operation of the IPv6 FTP client it is > not recommended the translation box to implement FTP ALG. Your document does not explain what does the "ALG" mean. Section 6: > The extension that > defines in this document will not impact FTP security. First, s/defines/is defined/ (this is not an only instance of such mistakes in the document). Second, I don't see the "extension" in your document. (This also applies to title). The intended status is Informational. However, I'd better like BCP, since your document tries to make normative recommendation. Moreover, in Abstract you say: > This document proposes to update > IPv6 FTP client's specification What document is the "IPv6 FTP client's specification"? Also, some conclusion summarizing the document's recommendation will be useful. Thanks, Mykyta Yevstifeyev 11.07.2011 5:18, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FTP Extensions, 2nd edition Working Group of the IETF. > > Title : FTP extension for IPv4/IPv6 transition > Author(s) : Dapeng Liu > Iljitsch van Beijnum > Zhen Cao > Filename : draft-ietf-ftpext2-ftp64-01.txt > Pages : 7 > Date : 2011-07-10 > > From john-ietf@jck.com Mon Jul 11 03:59:40 2011 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 1C54C21F8B1C for ; Mon, 11 Jul 2011 03:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpxlkaBhj0m9 for ; Mon, 11 Jul 2011 03:59:39 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 05A4821F8B1A for ; Mon, 11 Jul 2011 03:59:39 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QgEDC-000PDm-7X; Mon, 11 Jul 2011 06:59:38 -0400 Date: Mon, 11 Jul 2011 06:59:37 -0400 From: John C Klensin To: Mykyta Yevstifeyev , ftpext@ietf.org Message-ID: In-Reply-To: <4E1AB7BE.7020307@gmail.com> References: <20110711050127.13929.50068.idtracker@ietfa.amsl.com> <4E1AB7BE.7020307@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [ftpext] I-D Action: draft-ietf-ftpext2-typeu-02.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, 11 Jul 2011 10:59:40 -0000 --On Monday, July 11, 2011 11:43 +0300 Mykyta Yevstifeyev wrote: > As I mentioned in my previous message, I have several comments > on new IANA considerations, which follow. The current Section > 5 is: > >> 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". > > First, this sections doesn't mention clearly what is the new > "table". I suppose you wanted a new sub-registry. In this > case it really lacks a number of information required by RFC > 5226. This includes: (1) what is the format of the > sub-registry (I guess this should be "TYPE parameter", > "conformance" and "reference"). Probably we can also create > the separate column entitled "2nd parameter" and corresponding > possible values "allowed/not-allowed"; (2) what is the > addition policy for the new entries (I suppose this should be > "IETF Consensus" or "RFC Required"; I think the 1st is > better). (3) see also bullet 2 of Section 4.2 of RFC 5226. Given the time, other commitments, and closeness to the deadline, I put something there that would clearly indicate a direction without taking the time to check 5226 or laying out a table that would have made the intent more clear. That represented a tradeoff between having an updated document the WG could discuss in Quebec if it were so inclined and missing the posting deadline. I probably should have inserted a note in the draft indicating awareness of those issues but didn't think to do so. Sorry. Addressed in the next draft. > Moreover, I think creating the registry should be done by the > separate document, whereas your one should only register the > corresponding value in it. This will be clearer a bit, IMO. > Yet, I don't insist much on this particular issue. While I understand your concern, we create registries in protocol specs fairly frequently. In retrospect, we should have make explicit provision in RFC 5797 for registry tables ("subregistries" if you will) for argument values to base FTP commands as they are extended. It seems to me that creating a separate document either to create this particular registry or to establish the general principle would be mostly a waste of time. YMMD, but that is how I intend to proceed until / unless the WG tells me otherwise. Again, thanks for the close reading. john From evnikita2@gmail.com Thu Jul 14 07:42:15 2011 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 F1A6321F8AEA for ; Thu, 14 Jul 2011 07:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npOTYLNazdqe for ; Thu, 14 Jul 2011 07:42:14 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44A8221F8AC9 for ; Thu, 14 Jul 2011 07:42:14 -0700 (PDT) Received: by eye13 with SMTP id 13so219492eye.31 for ; Thu, 14 Jul 2011 07:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=vBdVjL2eav0mbomHIku69uAhUn3vB8zx7D43/3wumBY=; b=InYSIbkGKdEsm/TSKbhR7nXED66/PdXo/H9aNK4GbTDpVJZSYjnySLuB0EKbdMkAJu Py781Iw5jlvBcMBujx/v1gTdhr4yPoQA6ImmmcFLDeeIt29HvS1bAaGb4w8ZEa53/939 T6DAhZnC7fldA9SvZiPPCEJuonUbyy9oB2eVY= Received: by 10.213.4.136 with SMTP id 8mr1540367ebr.20.1310654533211; Thu, 14 Jul 2011 07:42:13 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id b13sm202580een.31.2011.07.14.07.42.11 (version=SSLv3 cipher=OTHER); Thu, 14 Jul 2011 07:42:12 -0700 (PDT) Message-ID: <4E1F006F.8050102@gmail.com> Date: Thu, 14 Jul 2011 17:42:55 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "ftpext@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Gregory Lundberg Subject: [ftpext] OPTS UTF8 needs work (...probably in FTPEXT2) 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, 14 Jul 2011 14:42:15 -0000 Hello, I've recently found the draft of FTPEXT WG: http://tools.ietf.org/id/draft-ietf-ftpext-utf-8-option-00.txt. It specifies the mechanism to negotiate the use of UTF-8 encoded pathnames in FTP. To my knowledge, this option is currently implemented by many applications, but still remain undocumented. In order to fill this gap, I'd like to propose the FTPEXT2 WG to undertake the effort to reopen the work on the document. Any thoughts? Mykyta Yevstifeyev From wmaton@ottix.net Thu Jul 14 07:47:37 2011 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 0E22521F8911 for ; Thu, 14 Jul 2011 07:47:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjhuI25-Jzh0 for ; Thu, 14 Jul 2011 07:47:36 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by ietfa.amsl.com (Postfix) with ESMTP id 66F1B21F891F for ; Thu, 14 Jul 2011 07:47:36 -0700 (PDT) Received: from iskra.ottix.net (localhost [127.0.0.1]) by iskra.ottix.net (8.14.4/8.14.4) with ESMTP id p6EElVvJ030120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jul 2011 10:47:31 -0400 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id p6EElUnA030108; Thu, 14 Jul 2011 10:47:30 -0400 Date: Thu, 14 Jul 2011 10:47:30 -0400 (EDT) From: "William F. Maton" To: Mykyta Yevstifeyev In-Reply-To: <4E1F006F.8050102@gmail.com> Message-ID: References: <4E1F006F.8050102@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ftpext@ietf.org" , Gregory Lundberg Subject: Re: [ftpext] OPTS UTF8 needs work (...probably in FTPEXT2) 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, 14 Jul 2011 14:47:37 -0000 Hi Mytyka, You are correct, this is one of two I-D's that Gregory drafted a long time ago (the other one is I think unrelated). I'm in contact with him sporadically so I'll ask if he has anything he'd like to add to it. Thanks, On Thu, 14 Jul 2011, Mykyta Yevstifeyev wrote: > Hello, > > I've recently found the draft of FTPEXT WG: > http://tools.ietf.org/id/draft-ietf-ftpext-utf-8-option-00.txt. It specifies > the mechanism to negotiate the use of UTF-8 encoded pathnames in FTP. To my > knowledge, this option is currently implemented by many applications, but > still remain undocumented. In order to fill this gap, I'd like to propose > the FTPEXT2 WG to undertake the effort to reopen the work on the document. > Any thoughts? > > Mykyta Yevstifeyev > _______________________________________________ > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext > wfms From anthonybryan@gmail.com Thu Jul 14 16:51:47 2011 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 5862821F8764 for ; Thu, 14 Jul 2011 16:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKJJOKcuqUSW for ; Thu, 14 Jul 2011 16:51:46 -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 1026321F8762 for ; Thu, 14 Jul 2011 16:51:45 -0700 (PDT) Received: by ywp31 with SMTP id 31so375010ywp.31 for ; Thu, 14 Jul 2011 16:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=GH4J34DFjCzekZXYlDtrdtMcQsueJut8tTQAKvkXkic=; b=Yt2j5xGXCndTE8/iD2I3JirCkkHglbAZ9MfLd0jjcg7JhRlqMQjEDgCEWDyw9UXtri HpsvkXRqnW2rmUlaly1mMNX3eM95lu5cS3mQVAGpp3KjOXfIRipHEzzVaTdtk2vltpli behOQwk4b6ZVeemQVhwAiUSwfx9jhh3QoWefg= MIME-Version: 1.0 Received: by 10.91.126.15 with SMTP id d15mr2989521agn.128.1310687505220; Thu, 14 Jul 2011 16:51:45 -0700 (PDT) Received: by 10.90.52.10 with HTTP; Thu, 14 Jul 2011 16:51:45 -0700 (PDT) Date: Thu, 14 Jul 2011 19:51:45 -0400 Message-ID: From: Anthony Bryan To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [ftpext] HOST back to FTPEXT2 WG for more review 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, 14 Jul 2011 23:51:47 -0000 HOST has been brought back to our WG for more review, after being sent to the IESG. HOST has had a long history and fair amount of implementations, but there were some late comments and changes. thank you to everyone who has contributed so far! *** if you have not reviewed HOST yet, please take some time to do so. it is one of the primary drafts that this WG was chartered to work on & is in the final stages. please, review, make comments, & have them addressed. :) *** the WG really needs to focus on its official work, the 4 drafts at http://tools.ietf.org/wg/ftpext2/ - I know there is a lot to do, & we can be sidetracked a bit, as long as we are making progress on our main goals. so, let's concentrate on HOST & our other mature work & see if any other things needs to be done. if you have reviewed HOST before, please review any changes in the past few months. if you have comments, please make sure that they have been addressed to your satisfaction and state whether you are for or against the approval of HOST (even if you have in the past). past discussion can be found on the list archives: http://www.ietf.org/mail-archive/web/ftpext/current/maillist.html the author also posted a pre-submission -04 revision that he will submit once the ID submission moratorium is over (& may wish to put online somewhere in plain text format): http://www.ietf.org/mail-archive/web/ftpext/current/msg00366.html fancy diffs are available at http://tools.ietf.org/html/draft-ietf-ftpext2-hosts to see changes, so you can minimize the time you need to spend re-reviewing. --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] =A0 )) Easier, More Reliable, Self Healing Downloads From daniel@haxx.se Fri Jul 22 13:43:52 2011 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 0F5F921F8B09 for ; Fri, 22 Jul 2011 13:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.929 X-Spam-Level: X-Spam-Status: No, score=-3.929 tagged_above=-999 required=5 tests=[AWL=-1.680, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2TiA5aeurJz for ; Fri, 22 Jul 2011 13:43:51 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7808421F87C2 for ; Fri, 22 Jul 2011 13:43:50 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id p6MKhXYq006457; Fri, 22 Jul 2011 22:43:33 +0200 Date: Fri, 22 Jul 2011 22:43:33 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Anthony Bryan In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.8 (giant.haxx.se [80.67.6.50]); Fri, 22 Jul 2011 22:43:34 +0200 (CEST) Cc: ftpext@ietf.org Subject: Re: [ftpext] HOST back to FTPEXT2 WG for more review 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, 22 Jul 2011 20:43:52 -0000 On Thu, 14 Jul 2011, Anthony Bryan wrote: > if you have reviewed HOST before, please review any changes in the past few > months. if you have comments, please make sure that they have been addressed > to your satisfaction and state whether you are for or against the approval > of HOST (even if you have in the past). I got back to this spec now and I still think the HOST should accept a port number and with the -03's new section 3.2.2 where it says: If a user-PI sends an additional HOST command before attempting to authenticate the user, a server-FTP process that conforms to this specification MUST treat the additional HOST command as though a REIN command was sent, ... I think even more strongly than before that it would make more sense to have section 3's two alternative versions a and b just be the version B as then a "wrongly placed" HOST would always imply a REIN. Nice and simple. It seems we won't get a lot more feedback on this spec in this WG. -- / daniel.haxx.se From paulfordh@uk.ibm.com Mon Jul 25 04:53:56 2011 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 CB88321F854E for ; Mon, 25 Jul 2011 04:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVKueYiNOfAt for ; Mon, 25 Jul 2011 04:53:55 -0700 (PDT) Received: from mtagate7.uk.ibm.com (mtagate7.uk.ibm.com [194.196.100.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1612321F8879 for ; Mon, 25 Jul 2011 03:35:00 -0700 (PDT) Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p6PAYxox020878 for ; Mon, 25 Jul 2011 10:34:59 GMT Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p6PAYqOo2121978 for ; Mon, 25 Jul 2011 11:34:59 +0100 Received: from d06av07.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p6PAYq73007230 for ; Mon, 25 Jul 2011 04:34:52 -0600 Received: from d06ml069.portsmouth.uk.ibm.com (d06ml069.portsmouth.uk.ibm.com [9.149.38.218]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p6PAYptA007227; Mon, 25 Jul 2011 04:34:51 -0600 In-Reply-To: References: To: Daniel Stenberg MIME-Version: 1.0 X-KeepSent: E237FE3A:1794CEA8-802578D8:0039F193; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 From: Paul Ford-Hutchinson Message-ID: Date: Mon, 25 Jul 2011 11:34:51 +0100 X-MIMETrack: Serialize by Router on D06ML069/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 25/07/2011 11:34:51, Serialize complete at 25/07/2011 11:34:51 Content-Type: multipart/alternative; boundary="=_alternative 003A1A75802578D8_=" Cc: ftpext@ietf.org Subject: Re: [ftpext] HOST back to FTPEXT2 WG for more review 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, 25 Jul 2011 11:53:56 -0000 This is a multipart message in MIME format. --=_alternative 003A1A75802578D8_= Content-Type: text/plain; charset="US-ASCII" Daniel Stenberg wrote on 22/07/2011 21:43:33: > ... I think even more strongly than before that it would make more sense to > have section 3's two alternative versions a and b just be the version B as > then a "wrongly placed" HOST would always imply a REIN. Nice and simple. > Just to clarify - this is the section that currently reads ... Server-FTP processes SHOULD treat a situation where the HOST command is issued after the user has been authenticated by using one of the following two behaviors: a. Treat the late HOST command as an erroneous sequence of commands and return a 503 reply. b. Treat the late HOST command as though a REIN command was sent before the HOST command and reset the user-PI to the state that existed after the TCP connection was first established and before the initial user authentication and then return the appropriate reply for the HOST command. We have to think "why is this being described" and "in which situations is it relevant". So, for "why is this being described" - I think we have - For Server processes to code to - For Client implementations to code to for "in which situations is it relevant" - We have - Servers that want to implement this command - Servers that don't want to implement this command but don't want to break any clients (this includes servers that don't want to change behaviour at all) - Clients that want to use the HOST command with servers which support it For servers implementing HOST, you are correct, servers which implement this spec, should behave like (b) - and, if we wish to mandate that linkage in the spec (i.e. behaviour (a) is not permitted if the client knows the server supports HOST (either by FEAT or a successful HOST during the current session)) - feel free to do so. However, servers which do not implement HOST, will do (a). Therefore, for client writers, the client needs to be coded to expect the behaviour of the server to be (a) or (b) and MUST check the reply to the HOST to determine if an implicit REIN has happened. Therefore (a) and (b) should be specified in the doc. HOWEVER ... We should mandate an explicit REIN =============================================== Just to mention it one more time in case it got buried in a previous comment.... I think that the REIN should be mandated as explicitly required; and a second or subsequent HOST should not be valid until the Client and Server have successfully completed a REIN/220 exchange. This is because (for example in RFC4217) the REIN command itself may be governed by 'special' processing. It is not specified in this document how such processing should, in general terms, be used for the HOST command. I have been persuaded not to like "Command XXXX" implicitly does "Command YYYY". In fact, I got told off for it during the draft stages of what became RFC4217, which is why "AUTH SSL" (bad) and "AUTH TLS" (good) are not functionally equivalent. Paul -- Paul Ford-Hutchinson CISSP - Tivoli Security Consultant IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU Tel +44 (0)7500 078379 (internal: 37269105) --=_alternative 003A1A75802578D8_= Content-Type: text/html; charset="US-ASCII"
Daniel Stenberg wrote on 22/07/2011 21:43:33:

> ... I think even more strongly than before that it would make more sense to
> have section 3's two alternative versions a and b just be the version B as
> then a "wrongly placed" HOST would always imply a REIN. Nice and simple.
>

Just to clarify - this is the section that currently reads ...

   Server-FTP processes SHOULD treat a situation where the HOST command
  is issued after the user has been authenticated by using one of the
  following two behaviors:

  a.  Treat the late HOST command as an erroneous sequence of commands
      and return a 503 reply.

  b.  Treat the late HOST command as though a REIN command was sent
      before the HOST command and reset the user-PI to the state that
      existed after the TCP connection was first established and before
      the initial user authentication and then return the appropriate
      reply for the HOST command.
We have to think "why is this being described" and "in which situations is it relevant".

So, for "why is this being described" - I think we have

- For Server processes to code to
- For Client implementations to code to

for "in which situations is it relevant" - We have

 - Servers that want to implement this command
 - Servers that don't want to implement this command but don't want to break any clients (this includes servers that don't want to change behaviour at all)
 - Clients that want to use the HOST command with servers which support it

For servers implementing HOST, you are correct, servers which implement this spec, should behave like (b) - and, if we wish to mandate that linkage in the spec (i.e. behaviour (a) is not permitted if the client knows the server supports HOST (either by FEAT or a successful HOST during the current session)) - feel free to do so.

However, servers which do not implement HOST, will do (a).

Therefore, for client writers, the client needs to be coded to expect the behaviour of the server to be (a) or (b) and MUST check the reply to the HOST to determine if an implicit REIN has happened.  Therefore (a) and (b) should be specified in the doc.

HOWEVER ... We should mandate an explicit REIN
===============================================

Just to mention it one more time in case it got buried in a previous comment....

I think that the REIN should be mandated as explicitly required; and a second or subsequent HOST should not be valid until the Client and Server have successfully completed a REIN/220 exchange.  This is because (for example in RFC4217) the REIN command itself may be governed by 'special' processing.  It is not specified in this document how such processing should, in general terms, be used for the HOST command.

I have been persuaded not to like "Command XXXX" implicitly does "Command YYYY".  In fact, I got told off for it during the draft stages of what became RFC4217, which is why "AUTH SSL" (bad) and "AUTH TLS" (good) are not functionally equivalent.


Paul
--

Paul Ford-Hutchinson CISSP - Tivoli Security Consultant
IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU

Tel +44 (0)7500 078379  (internal: 37269105)
 --=_alternative 003A1A75802578D8_=-- From robmcm@microsoft.com Mon Jul 25 19:17:59 2011 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 BBCC321F87BC for ; Mon, 25 Jul 2011 19:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.934 X-Spam-Level: X-Spam-Status: No, score=-6.934 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVLCYUJUBTyF for ; Mon, 25 Jul 2011 19:17:59 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 310DF21F8760 for ; Mon, 25 Jul 2011 19:17:59 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 25 Jul 2011 19:17:58 -0700 Received: from VA3EHSOBE009.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.323.2; Mon, 25 Jul 2011 19:17:58 -0700 Received: from mail69-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.22; Tue, 26 Jul 2011 02:17:57 +0000 Received: from mail69-va3 (localhost.localdomain [127.0.0.1]) by mail69-va3-R.bigfish.com (Postfix) with ESMTP id 54E3D11781DC for ; Tue, 26 Jul 2011 02:17:57 +0000 (UTC) X-SpamScore: -20 X-BigFish: PS-20(zz103dKzz1202h1082kzz1033IL8275dhz31h2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT007.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail69-va3: transitioning domain of microsoft.com does not designate 157.55.61.146 as permitted sender) client-ip=157.55.61.146; envelope-from=robmcm@microsoft.com; helo=CH1PRD0302HT007.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail69-va3 (localhost.localdomain [127.0.0.1]) by mail69-va3 (MessageSwitch) id 1311646676678472_22414; Tue, 26 Jul 2011 02:17:56 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.238]) by mail69-va3.bigfish.com (Postfix) with ESMTP id 8430B238050; Tue, 26 Jul 2011 02:17:56 +0000 (UTC) Received: from CH1PRD0302HT007.namprd03.prod.outlook.com (157.55.61.146) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 26 Jul 2011 02:17:53 +0000 Received: from CH1PRD0302MB131.namprd03.prod.outlook.com ([169.254.11.249]) by CH1PRD0302HT007.namprd03.prod.outlook.com ([10.28.29.126]) with mapi id 14.01.0225.063; Tue, 26 Jul 2011 02:17:53 +0000 From: Robert McMurray To: Paul Ford-Hutchinson , Daniel Stenberg , "ftpext@ietf.org" Thread-Topic: [ftpext] HOST back to FTPEXT2 WG for more review Thread-Index: AQHMSv0xR7qFJ/RaKUS0hZb/bMvAeJT9xMHQ Date: Tue, 26 Jul 2011 02:17:52 +0000 Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C194E2EA3@CH1PRD0302MB131.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: [10.28.29.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: CH1PRD0302HT007.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$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%HAXX.SE$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-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com Subject: Re: [ftpext] HOST back to FTPEXT2 WG for more review 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, 26 Jul 2011 02:17:59 -0000 In response to Daniel's and Paul's emails, which are archived at http://www= .ietf.org/mail-archive/web/ftpext/current/msg00388.html and http://www.ietf= .org/mail-archive/web/ftpext/current/msg00389.html respectively, Daniel bri= ngs up a point in section 3 that has been addressed before, which is where = I documented two possible options when a HOST command is issued after the u= ser has been authenticated. After recent discussions, I do not think that this is necessary after all. = In a separate thread it was suggested that the HOST draft should be specifi= c and not provide both options, and after looking at Daniel's and Paul's em= ails I concede the point that it is probably better for the HOST draft to s= pecify only one option. That being said, I agree with Paul that an implicit= REIN is not the way to implement this. FTP already has a REIN command, and= it's simple enough for a client to send a REIN command followed by HOST co= mmand if that's the desired behavior. Therefore the better option is to ret= urn a 503 reply for an erroneous sequence of commands when a HOST command i= s issued after the user has been authenticated. With that in mind, I am rew= ording that portion of section 3 as follows: "Server-FTP processes that conform to this specification MUST treat a situa= tion where the HOST command is issued more than once before the user has be= en authenticated as though a previous HOST command was not sent, and return= the appropriate reply for the new HOST command. Server-FTP processes MUST = treat a situation where the HOST command is issued after the user has been = authenticated as an erroneous sequence of commands and return a 503 reply." Of course, in situations where a server-FTP process does NOT implement the = HOST command, the server-FTP process will return a 500 or 502 reply, as it = would with any other unrecognized command. As far as specifying a port is concerned, it does not make sense to pass a = port in the HOST command. This concept has been discussed previously, see h= ttp://www.ietf.org/mail-archive/web/ftpext/current/msg00264.html for detail= s. Thanks! --Robert From evnikita2@gmail.com Mon Jul 25 21:18:31 2011 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 F125921F8B08 for ; Mon, 25 Jul 2011 21:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBEZ++kRIBwk for ; Mon, 25 Jul 2011 21:18:31 -0700 (PDT) Received: from mail-ey0-f176.google.com (mail-ey0-f176.google.com [209.85.215.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3921F8B07 for ; Mon, 25 Jul 2011 21:18:31 -0700 (PDT) Received: by eya28 with SMTP id 28so79825eya.21 for ; Mon, 25 Jul 2011 21:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JSb3EnMlqElsVdjbz2YMw4k6GLNmLD2rLfyg0e12Lss=; b=v1cUEF1q1eXv/DUufe+a/8G2nEg3m0FKPEZAzc484kMQv6Tz0NNWWXHxeF7EeWnVZo C54MXe37F7mu9HzXeZwXCJ3Qu3wIbfTDPXzzFnQxaGlv1Hz6ezhPwCot8YmCpGLwNgHJ ud7AIbWyYy4z5ov1hJQN6XdBkwnIAjcVJZklY= Received: by 10.204.132.200 with SMTP id c8mr1679200bkt.235.1311653910171; Mon, 25 Jul 2011 21:18:30 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id s14sm23058bkw.52.2011.07.25.21.18.28 (version=SSLv3 cipher=OTHER); Mon, 25 Jul 2011 21:18:29 -0700 (PDT) Message-ID: <4E2E403E.7040509@gmail.com> Date: Tue, 26 Jul 2011 07:19:10 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ftpext@ietf.org References: <01AA9EC92749BF4894AC2B3039EA4A2C194E2EA3@CH1PRD0302MB131.namprd03.prod.outlook.com> In-Reply-To: <01AA9EC92749BF4894AC2B3039EA4A2C194E2EA3@CH1PRD0302MB131.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ftpext] HOST back to FTPEXT2 WG for more review 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, 26 Jul 2011 04:18:32 -0000 26.07.2011 5:17, Robert McMurray wrote: > "Server-FTP processes that conform to this specification MUST treat a situation where the HOST command is issued more than once before the user has been authenticated as though a previous HOST command was not sent, and return the appropriate reply for the new HOST command. Server-FTP processes MUST treat a situation where the HOST command is issued after the user has been authenticated as an erroneous sequence of commands and return a 503 reply." > > Of course, in situations where a server-FTP process does NOT implement the HOST command, the server-FTP process will return a 500 or 502 reply, as it would with any other unrecognized command. +1. Such approach seems to be fine and wise. I think the document is now ready for IESG review. Mykyta From alun@texis.com Mon Jul 25 21:58:00 2011 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 F23B411E8078 for ; Mon, 25 Jul 2011 21:57:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfKaZiv+fF3x for ; Mon, 25 Jul 2011 21:57:59 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 27FFB11E8072 for ; Mon, 25 Jul 2011 21:57:59 -0700 (PDT) Received: from cliff (c-50-132-18-131.hsd1.wa.comcast.net [50.132.18.131]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LxPxy-1RVKup25Oc-016msv; Tue, 26 Jul 2011 00:57:56 -0400 From: "Alun Jones" To: "'Robert McMurray'" , References: <01AA9EC92749BF4894AC2B3039EA4A2C194E2EA3@CH1PRD0302MB131.namprd03.prod.outlook.com> In-Reply-To: <01AA9EC92749BF4894AC2B3039EA4A2C194E2EA3@CH1PRD0302MB131.namprd03.prod.outlook.com> Date: Mon, 25 Jul 2011 21:57:51 -0700 Organization: Texas Imperial Software Message-ID: <09db01cc4b50$95226d30$bf674790$@texis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGHyGkueDSPjGUeR5jz7z0YkYS9rwDssXAzA28o/qIBdNqekpVYij7A Content-Language: en-us X-Provags-ID: V02:K0:Wm8kIatyDIIXOuhz6fFxU9sSyDg02IP/3R+fpaK/pcP DwxUxMouSzHk93LcgU5sIOBRNRQDfSfggYjZZAhKM1LUIzR46a gdHnGwkKKQ2rvGv6NJ/JZigdNHrLcvLZUs9kKYrCN6NdXHT8dL x5I4wdrkclJTJyolMFH2Jpb2vaP9XcGnEBZUOVYzHHr/CbFdnw BOP8dN4xqIWbmGiX4ggvQ== Subject: Re: [ftpext] HOST back to FTPEXT2 WG for more review X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: alun@texis.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 04:58:00 -0000 Calling HOST _after_ AUTH - is that deliberately undefined behaviour? I can imagine a scenario where a somewhat public gateway FTP server feeds to a number of more private backend FTP servers, where it's not considered a good idea to publicise which server you're eventually connecting to. Alun. ~~~~ > -----Original Message----- > From: ftpext-bounces@ietf.org [mailto:ftpext-bounces@ietf.org] On Behalf > Of Robert McMurray > Sent: Monday, July 25, 2011 7:18 PM > To: Paul Ford-Hutchinson; Daniel Stenberg; ftpext@ietf.org > Subject: Re: [ftpext] HOST back to FTPEXT2 WG for more review > > In response to Daniel's and Paul's emails, which are archived at > http://www.ietf.org/mail-archive/web/ftpext/current/msg00388.html and > http://www.ietf.org/mail-archive/web/ftpext/current/msg00389.html > respectively, Daniel brings up a point in section 3 that has been addressed > before, which is where I documented two possible options when a HOST > command is issued after the user has been authenticated. > > After recent discussions, I do not think that this is necessary after all. In a > separate thread it was suggested that the HOST draft should be specific and > not provide both options, and after looking at Daniel's and Paul's emails I > concede the point that it is probably better for the HOST draft to specify only > one option. That being said, I agree with Paul that an implicit REIN is not the > way to implement this. FTP already has a REIN command, and it's simple > enough for a client to send a REIN command followed by HOST command if > that's the desired behavior. Therefore the better option is to return a 503 > reply for an erroneous sequence of commands when a HOST command is > issued after the user has been authenticated. With that in mind, I am > rewording that portion of section 3 as follows: > > "Server-FTP processes that conform to this specification MUST treat a > situation where the HOST command is issued more than once before the > user has been authenticated as though a previous HOST command was not > sent, and return the appropriate reply for the new HOST command. Server- > FTP processes MUST treat a situation where the HOST command is issued > after the user has been authenticated as an erroneous sequence of > commands and return a 503 reply." > > Of course, in situations where a server-FTP process does NOT implement the > HOST command, the server-FTP process will return a 500 or 502 reply, as it > would with any other unrecognized command. > > As far as specifying a port is concerned, it does not make sense to pass a port > in the HOST command. This concept has been discussed previously, see > http://www.ietf.org/mail-archive/web/ftpext/current/msg00264.html for > details. > > Thanks! > > --Robert > > > > > > > _______________________________________________ > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext From internet-drafts@ietf.org Thu Jul 28 12:02:06 2011 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 BB94521F874C; Thu, 28 Jul 2011 12:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MZmq+iDuxAV; Thu, 28 Jul 2011 12:02:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB7021F8665; Thu, 28 Jul 2011 12:02:06 -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: 3.57 Message-ID: <20110728190206.27942.42243.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2011 12:02:06 -0700 Cc: ftpext@ietf.org Subject: [ftpext] I-D Action: draft-ietf-ftpext2-hash-02.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: Thu, 28 Jul 2011 19:02:06 -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-02.txt Pages : 16 Date : 2011-07-28 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-02.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-02.txt From evnikita2@gmail.com Fri Jul 29 03:17:58 2011 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 6FFF021F8B77 for ; Fri, 29 Jul 2011 03:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=1.101, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3E33TPrEvwg for ; Fri, 29 Jul 2011 03:17:57 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAE621F8876 for ; Fri, 29 Jul 2011 03:17:57 -0700 (PDT) Received: by fxe6 with SMTP id 6so2449915fxe.31 for ; Fri, 29 Jul 2011 03:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=o65+BCW5nfFx68Q1sDOoeYad8Vh97MTI8XB/LdI+QAQ=; b=fOp5NUWYpfj4aV4AoWIsm4Lb5IkYt/8kSftatW3sg2teUM2hxiEOH8nw9ElPWB8r4b dGWLXYp2kEBoe2NNrZsh3aiWeIgCOyC1ojjqkMCaAYeRAWVbymFQ9diu0zJSXts4enSu VJieFUpIrgQ/pBi9kulnshw0jQpJFt786yTQE= Received: by 10.223.26.70 with SMTP id d6mr1546166fac.78.1311934676528; Fri, 29 Jul 2011 03:17:56 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id h17sm292345fai.2.2011.07.29.03.17.53 (version=SSLv3 cipher=OTHER); Fri, 29 Jul 2011 03:17:54 -0700 (PDT) Message-ID: <4E3288FB.4070605@gmail.com> Date: Fri, 29 Jul 2011 13:18:35 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ftpext@ietf.org References: <20110728190206.27942.42243.idtracker@ietfa.amsl.com> In-Reply-To: <20110728190206.27942.42243.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ftpext] I-D Action: draft-ietf-ftpext2-hash-02.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: Fri, 29 Jul 2011 10:17:58 -0000 Hello, I'd like to provide some comments on draft-ietf-ftpext2-hash-02, which was uploaded on 28 July. Section 2: > The term "pathname" is used as defined in Section 2.2 of > [RFC3659]. This statement and the "" used in ABNF productions need to be clarified. Explicitly, your document should be clear regarding the fact that ABNF production is defined in RFC 3659 and is imported from there. Moreover, as is a valid ABNF production, and it's imported from RFC 3659, there is no reason to enclose it in the angle brackets when defining other ABNF productions. In section 3: > hash-ok = "213" SP hashname SP start-point "-" end-point SP filehash SP CRLF RFC 5234 allows line breaks in ABNF definitions. Ibid (and in Section 3.1): > hashname = 1*( hchar ) It's OK to change this to: > hashname = 1*hchar here. Ibid: > All hash values MUST be encoded in lowercase hexadecimal format. This confuses with: > Note that in ABNF, string literals are case insensitive. in Section 2.1. RFC 5234 is: > HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" and therefore allows uppercase as well as lowercase a-f letters. If you want to mandate use of lowercase only, please use "DIGIT / %x61-66"; but I don't think it makes sense. In Section 3.5 you use the SHOULD RFC 2119 keyword. From RFC 2119: > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. What may be such "valid reasons in particular circumstances" not to send the error response? I'd recommend to use non-normative "should" here. I've noted that Section 3.2 says: > The pathname argument MUST represent a file path, not a > directory path. while Section 3.5 mentions: > The server-PI SHOULD reply with a 553 reply if the user requests the > HASH of a directory, which is not allowed. Maybe you meant "a file which is placed in a directory, that is not allowed" here? As an editorial issue. RFC 5234 recommends to enclose ABNF productions in the text in < and > rather than ' and ', as you currently do. Mykyta Yevstifeyev 28.07.2011 22:02, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FTP Extensions, 2nd edition Working Group of the IETF. > > Title : File Transfer Protocol HASH Command for Cryptographic Hashes > Author(s) : Anthony Bryan > Tim Kosse > Daniel Stenberg > Filename : draft-ietf-ftpext2-hash-02.txt > Pages : 16 > Date : 2011-07-28 From evnikita2@gmail.com Sat Jul 30 21:38:54 2011 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 BD88621F861A; Sat, 30 Jul 2011 21:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRes7EH+kYIR; Sat, 30 Jul 2011 21:38:54 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9A1021F85B9; Sat, 30 Jul 2011 21:38:50 -0700 (PDT) Received: by fxe6 with SMTP id 6so4041893fxe.31 for ; Sat, 30 Jul 2011 21:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=nSZQgMPHe58jhKShor9BGF+/srrXnMvgb8+Mk3YCKSI=; b=UB2tp81g+rT6ZiA5Oy94RPcmZbFnTADpo6KnJUZ7L7xP7O4RZ6w/csGUwvNHrGJMOR EuvJpCTttK+LLjb025yWFXnRiaDVaGsM8fTxBE2/2VCNZi1uyJdyFHqS1xiaWy/pFBp3 Hnhit5CiXCfQB8GEd2FutPTl9HpHDu9WKBOOU= Received: by 10.223.76.17 with SMTP id a17mr4334247fak.32.1312087132413; Sat, 30 Jul 2011 21:38:52 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id w11sm2054748faj.14.2011.07.30.21.38.50 (version=SSLv3 cipher=OTHER); Sat, 30 Jul 2011 21:38:51 -0700 (PDT) Message-ID: <4E34DC83.30504@gmail.com> Date: Sun, 31 Jul 2011 07:39:31 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Apps-discuss list , "uri-review@ietf.org" , URI , "ftpext@ietf.org" , register@uri.arpa, "public-iri@w3.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [ftpext] FWD: I-D Action: draft-yevstifeyev-ftp-uri-scheme-05.txt X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Apps-discuss list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 04:38:54 -0000 Hello, Sorry for cross-posting to 6 addresses :-); please send all your comments to apps-discuss@ietf.org. Note to public-iri subscribers: please have a look at Section 6. Note to register@uri.arpa subscribers: please comment Appendix A of the document. (The link to HTML version: http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme.) Thanks, Mykyta Yevstifeyev > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : The'ftp' URI Scheme > Author(s) : Mykyta Yevstifeyev > Filename : draft-yevstifeyev-ftp-uri-scheme-05.txt > Pages : 29 > Date : 2011-07-24 > > This document specifies the'ftp' Uniform Resource Identifier (URI) > scheme, which is used to refer to resources accessible via File > Transfer Protocol (FTP). It updates RFC 959 and RFC 1738. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yevstifeyev-ftp-uri-scheme-05.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-yevstifeyev-ftp-uri-scheme-05.txt From evnikita2@gmail.com Sun Jul 31 02:58:44 2011 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 8B2F321F87C5; Sun, 31 Jul 2011 02:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVQfTp4Nd7pI; Sun, 31 Jul 2011 02:58:43 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3380E21F87BD; Sun, 31 Jul 2011 02:58:43 -0700 (PDT) Received: by fxe6 with SMTP id 6so4192090fxe.31 for ; Sun, 31 Jul 2011 02:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=L3KBKDYqbgh++YjmziDNDA0Z6aFTB4oQCV+hyiylaMI=; b=WyuwlGqmyrT6kxpUPNOcwCw0LNNs5ojL0qQi4SOI9wZqCMYog+Atp/HsgVTUkjp9Fs 7r8ziRPlJCSoOVcCuq4DIKlIsAHZARB373q5QmDBKbbp7+cPwx61IloTlw1TOtlfwv8b VxztHdLyU+tFNtaK8iPtzeLp7AAycYfJ7fxY0= Received: by 10.223.14.24 with SMTP id e24mr4645514faa.15.1312106325443; Sun, 31 Jul 2011 02:58:45 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id w11sm2176317faj.14.2011.07.31.02.58.43 (version=SSLv3 cipher=OTHER); Sun, 31 Jul 2011 02:58:44 -0700 (PDT) Message-ID: <4E35277B.5010708@gmail.com> Date: Sun, 31 Jul 2011 12:59:23 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: John Cowan References: <4E34DC83.30504@gmail.com> <20110731083853.GB30568@mercury.ccil.org> In-Reply-To: <20110731083853.GB30568@mercury.ccil.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: register@uri.arpa, Apps-discuss list , "ftpext@ietf.org" , URI , "public-iri@w3.org" , "uri-review@ietf.org" Subject: Re: [ftpext] FWD: I-D Action: draft-yevstifeyev-ftp-uri-scheme-05.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: Sun, 31 Jul 2011 09:58:44 -0000 31.07.2011 11:38, John Cowan wrote: > Mykyta Yevstifeyev scripsit: > >> Sorry for cross-posting to 6 addresses :-); please send >> all your comments to apps-discuss@ietf.org. Note to >> public-iri subscribers: please have a look at Section >> 6. Note to register@uri.arpa subscribers: please comment >> Appendix A of the document. (The link to HTML version: >> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme.) > It's inappropriate to say that the client SHALL request a password > from the user if none is supplied and the server demands one (and > likewise for accounts). The client must be free to fail under such > circumstances, as it may be a robot or otherwise not have a user > available. Likewise with SHALL notify the user, etc. These should be > changed to MAYs or SHOULDs. I think such occurrences of SHALL will be replaced with SHOULD or non-normative "should". (I don't think 'ftp' URIs will be used with applications that have no UI; so I don't see reasons to assume they will be used in such way. But, anyway, your comment regarding SHALL is reasonable). > > Editorial notes: Lots of people don't know what "ibidem" means, or even > its standard abbreviation "ibid". I suggest changing the first instance > to "in RFC 959", the second instance to "below", and the third instance > to "in the". I'll make the following corrections: 1st instance - "in RFC 959" (as currently), 2nd one - "in the same document", 3rd one (I guess this is regarding ASCII) - "in RFC 959". > > Note error "internalization" for "internationalization", "internalized" > for "internationalized", etc. Fixed now. > > Note persistent typo "exmaple.com" for "example.com". ACK. Thanks for reading the document. Mykyta > From cowan@ccil.org Sun Jul 31 01:38:53 2011 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 639DB21F8802; Sun, 31 Jul 2011 01:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aJiAou+g8wd; Sun, 31 Jul 2011 01:38:52 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id 3B09221F87C3; Sun, 31 Jul 2011 01:38:52 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.69) (envelope-from ) id 1QnRXx-0006My-5K; Sun, 31 Jul 2011 04:38:53 -0400 Date: Sun, 31 Jul 2011 04:38:53 -0400 From: John Cowan To: Apps-discuss list Message-ID: <20110731083853.GB30568@mercury.ccil.org> References: <4E34DC83.30504@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E34DC83.30504@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: John Cowan X-Mailman-Approved-At: Sun, 31 Jul 2011 09:06:13 -0700 Cc: register@uri.arpa, "public-iri@w3.org" , "uri-review@ietf.org" , URI , "ftpext@ietf.org" Subject: Re: [ftpext] FWD: I-D Action: draft-yevstifeyev-ftp-uri-scheme-05.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: Sun, 31 Jul 2011 08:38:53 -0000 Mykyta Yevstifeyev scripsit: > Sorry for cross-posting to 6 addresses :-); please send > all your comments to apps-discuss@ietf.org. Note to > public-iri subscribers: please have a look at Section > 6. Note to register@uri.arpa subscribers: please comment > Appendix A of the document. (The link to HTML version: > http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme.) It's inappropriate to say that the client SHALL request a password from the user if none is supplied and the server demands one (and likewise for accounts). The client must be free to fail under such circumstances, as it may be a robot or otherwise not have a user available. Likewise with SHALL notify the user, etc. These should be changed to MAYs or SHOULDs. Editorial notes: Lots of people don't know what "ibidem" means, or even its standard abbreviation "ibid". I suggest changing the first instance to "in RFC 959", the second instance to "below", and the third instance to "in the ". Note error "internalization" for "internationalization", "internalized" for "internationalized", etc. Note persistent typo "exmaple.com" for "example.com". -- Do what you will, John Cowan this Life's a Fiction cowan@ccil.org And is made up of http://www.ccil.org/~cowan Contradiction. --William Blake From john-ietf@jck.com Sun Jul 31 12:42:19 2011 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 4629821F88A0; Sun, 31 Jul 2011 12:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.634 X-Spam-Level: X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYoD5IQxMqbM; Sun, 31 Jul 2011 12:42:18 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE9921F889D; Sun, 31 Jul 2011 12:42:18 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Qnbu1-0002yH-OR; Sun, 31 Jul 2011 15:42:22 -0400 Date: Sun, 31 Jul 2011 15:42:20 -0400 From: John C Klensin To: John Cowan , Apps-discuss list Message-ID: In-Reply-To: <20110731083853.GB30568@mercury.ccil.org> References: <4E34DC83.30504@gmail.com> <20110731083853.GB30568@mercury.ccil.org> 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] FWD: I-D Action: draft-yevstifeyev-ftp-uri-scheme-05.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: Sun, 31 Jul 2011 19:42:19 -0000 --On Sunday, July 31, 2011 04:38 -0400 John Cowan wrote: > Mykyta Yevstifeyev scripsit: > >> Sorry for cross-posting to 6 addresses :-); please send >> all your comments to apps-discuss@ietf.org. Note to >> public-iri subscribers: please have a look at Section >> 6. Note to register@uri.arpa subscribers: please comment >> Appendix A of the document. (The link to HTML version: >> http://tools.ietf.org/html/draft-yevstifeyev-ftp-uri-scheme.) > It's inappropriate to say that the client SHALL request a > password from the user if none is supplied and the server > demands one (and likewise for accounts). The client must be > free to fail under such circumstances, as it may be a robot or > otherwise not have a user available. Likewise with SHALL > notify the user, etc. These should be changed to MAYs or > SHOULDs. In principle, this sort of thing could be addressed in the spec by adopting the model described in RFC 5321 for SMTP. That spec basically says that, independent of any other rules, the the client may abort the session at any time for any reason whatsoever. Then it defines what "abort" means. If one wanted to state the above that way, it would be, e.g., "if no password is supplied and the server demands one, then the client MUST either find a password and send it and send a QUIT to abort the session". However, this identifies two other issues: (1) FTP really is designed as an interactive protocol. If it had been designed for single-command-line or URI implementations, several things might be different. The IETF has rarely taken on UI designs directly and has a history of doing poorly when it does try. If the client hasn't spontaneously supplied a password but the server demands one, there are lots of ways (depending on the client and its operational environment) to obtain something password-like and respond to the request. Constraining those choices to "ask the user" when the client does not decide to just abort doesn't reflect either reality or reasonable design. Hence "must respond and send it" above, with the implication that the client MAY do anything it considers reasonable to satisfy that request. (2) More broadly, this is one of many special cases of why I continue to object to doing this as a URI without a lot of careful consideration. It seems to me that there are two logical possibilities for an FTP URI: (a) Do something absolutely minimal that satisfies a large number of cases. This is probably anonymous login only, stream and image transfer only, probably PASV only these days, maybe even a restriction to an ASCII command stream. If an email address is needed for login, a provision for picking that up from an environment variable rather than having it incorporated into the URI, would be important. (b) Fully-reflect the protocol and all of its standardized options. This would get fairly complex for a URI because one would not only want to supply a lot of information but might want to supply it conditionally. Between those two points, there isn't a lot other than slippery slope. john