From robmcm@microsoft.com Fri Sep 16 10:49: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 3E0CA21F8AF4 for ; Fri, 16 Sep 2011 10:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.887 X-Spam-Level: X-Spam-Status: No, score=-6.887 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDKHFLWt1mkp for ; Fri, 16 Sep 2011 10:49:55 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id B6ABF21F8AED for ; Fri, 16 Sep 2011 10:49:55 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 16 Sep 2011 10:52:10 -0700 Received: from TX2EHSOBE006.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.1.339.2; Fri, 16 Sep 2011 10:52:10 -0700 Received: from mail63-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Fri, 16 Sep 2011 17:52:10 +0000 Received: from mail63-tx2 (localhost.localdomain [127.0.0.1]) by mail63-tx2-R.bigfish.com (Postfix) with ESMTP id 16FDD1240159 for ; Fri, 16 Sep 2011 17:52:10 +0000 (UTC) X-SpamScore: -35 X-BigFish: PS-35(zz9371K542M1432N111aLzz1202h1082kzz1033IL8275dhz31h2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:157.55.61.146; KIP:(null); UIP:(null); IPV:SKI; H:CH1PRD0302HT011.namprd03.prod.outlook.com; R:internal; EFV:INT Received-SPF: softfail (mail63-tx2: 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=CH1PRD0302HT011.namprd03.prod.outlook.com ; .outlook.com ; Received: from mail63-tx2 (localhost.localdomain [127.0.0.1]) by mail63-tx2 (MessageSwitch) id 131619548321274_13769; Fri, 16 Sep 2011 17:51:23 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.241]) by mail63-tx2.bigfish.com (Postfix) with ESMTP id A12EF1938126; Fri, 16 Sep 2011 17:48:39 +0000 (UTC) Received: from CH1PRD0302HT011.namprd03.prod.outlook.com (157.55.61.146) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 16 Sep 2011 17:48:36 +0000 Received: from CH1PRD0302MB131.namprd03.prod.outlook.com ([169.254.11.156]) by CH1PRD0302HT011.namprd03.prod.outlook.com ([10.42.118.189]) with mapi id 14.01.0225.069; Fri, 16 Sep 2011 17:48:35 +0000 From: Robert McMurray To: "alun@texis.com" , "ftpext@ietf.org" Thread-Topic: [ftpext] HOST back to FTPEXT2 WG for more review Thread-Index: AQHMSv0xR7qFJ/RaKUS0hZb/bMvAeJT9xMHQgABGaYCAUpCRYA== Date: Fri, 16 Sep 2011 17:48:34 +0000 Message-ID: <01AA9EC92749BF4894AC2B3039EA4A2C21E7202B@CH1PRD0302MB131.namprd03.prod.outlook.com> References: <01AA9EC92749BF4894AC2B3039EA4A2C194E2EA3@CH1PRD0302MB131.namprd03.prod.outlook.com> <09db01cc4b50$95226d30$bf674790$@texis.com> In-Reply-To: <09db01cc4b50$95226d30$bf674790$@texis.com> 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: CH1PRD0302HT011.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEXIS.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-OriginatorOrg: microsoft.com X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.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: Fri, 16 Sep 2011 17:49:56 -0000 Hi Alun, Sorry, I somehow missed your message amidst all of the discussions that hap= pened in July while I was on vacation. While I wouldn't think that it would be a best practice, I don't think that= there's a problem with a HOST command preceded by an AUTH command. As you = indicated, there may be reasons to hide the HOST command and use the AUTH->= HOST->USER->PASS syntax, but that does introduce some problems with certifi= cate matching. In general, I would think that if someone is trying to hide = their credentials or their data then HOST->AUTH->USER->PASS would normally = be used. Thanks again! --Robert > -----Original Message----- > From: Alun Jones > Sent: Monday, July 25, 2011 9:58 PM > To: Robert McMurray; ftpext@ietf.org > Subject: Re: [ftpext] HOST back to FTPEXT2 WG for more review >=20 > Calling HOST _after_ AUTH - is that deliberately undefined behaviour? >=20 > 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 considere= d > a good idea to publicise which server you're eventually connecting to. >=20 > Alun. > ~~~~ From evnikita2@gmail.com Sat Sep 17 21:08:17 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 C7CD621F854F for ; Sat, 17 Sep 2011 21:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfFjF0egfqyc for ; Sat, 17 Sep 2011 21:08:17 -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 D846721F84D7 for ; Sat, 17 Sep 2011 21:08:16 -0700 (PDT) Received: by fxd18 with SMTP id 18so3158547fxd.31 for ; Sat, 17 Sep 2011 21:10: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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QpKbQuZspev+9I848CrdnF9Px55tMm21mUXSSp8tA0s=; b=ZC5M+t2uNwtHOGxVfy5MybobfwC2LONHwD0m9Tn1hVCLiEq5/bHnpGUWWipwqe/0pF yd4mGN5x0fdnZGnb0iYX8h6c2VDpWUNNbZ0UF+g0PZbpVgj5jJP6BdgWD52w8C9/+Ay3 cJAhKI22+L+H7bwE//RfF0ebInumatLffw1Ro= Received: by 10.223.58.139 with SMTP id g11mr2378098fah.14.1316319034552; Sat, 17 Sep 2011 21:10:34 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id i5sm7876569fai.15.2011.09.17.21.10.32 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 21:10:33 -0700 (PDT) Message-ID: <4E756F5A.9010806@gmail.com> Date: Sun, 18 Sep 2011 07:11:06 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: ftpext@ietf.org References: <4E1F006F.8050102@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ftpext] 2640bis (was: 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: Sun, 18 Sep 2011 04:08:17 -0000 All, I actually support an idea to revise RFC 2640 and put all the parts of the puzzle together rather than scatter them into several documents. What these parts might be follows: (1) LANG command, taking into account syntactical provisions of RFC 5646; there also is a flaw in ABNF definition of in Section 4.3 that allows an asterisk to be present more than once (with several language tags).; (2) FEAT UTF8 in conjunction with OPTS UTF8. draft-ietf-ftpext-utf-8-option contains a great deal of discussion why we need such facility. I'll repeat briefly: to allow non-UTF8 implementations to inter-operate with those that support i18n and UTF-8. Correspondingly, a provision of the following content should be introduced: no OPTS UTF8 must be sent unless the server has sent FEAT UTF8, and no UTF-8 pathnames are to be sent unless the server has acknowledged OPTS UTF8. (3) I have no idea why RFC 2640 implied i18n of pathnames only. BNF production directs to , which should have been internationalized. This also applies to responses. 2640 contains vary vague mention thereof: > lang-ok = "200" [SP *(%x00..%xFF) ] CRLF > command-unrecognized = "500" [SP *(%x01..%xFF) ] CRLF > bad-argument = "501" [SP *(%x01..%xFF) ] CRLF > not-implemented = "502" [SP *(%x01..%xFF) ] CRLF > unsupported-parameter = "504" [SP *(%x01..%xFF) ] CRLF ... but no generic provision was made. (4) TYPE U extension. This is what FTPEXT2 currently works on. (5) CR LF and CR NUL. This is also described in length in draft-ietf-ftpext-utf-8-option. (6) Editorial work, of course. Any additions? Mykyta Yevstifeyev 07.08.2011 0:20, John C Klensin wrote: > > --On Saturday, August 06, 2011 13:46 -0400 "William F. Maton" > wrote: > >> On Thu, 14 Jul 2011, Mykyta Yevstifeyev wrote: >> >>> I've recently found the draft of FTPEXT WG: >>> http://tools.ietf.org/id/draft-ietf-ftpext-utf-8-option-00.tx >>> t. 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? >> All, >> I have spoken privately with Gregory Lundberg regarding this >> draft and has no problem haviong it revived. He'd say so >> himself were it not for him being preoccupied with other >> things of a personal nature. > Hmm. > > I had glanced at RFC 2640 when I started to put the typeu spec > (now draft-ietf-ftpext2-typeu) together and assumed that it was > adequate. This I-D makes a fairly persuasive argument that it > is not. Despite that, I caught a significant error or two in > this spec... but they are easily corrected. > > If we want to be parsimonious about extensions, it might be > worthwhile to fold the protocol parts of this in together with > typeu, creating a single i18n extension or at least a single > i18n document. That would probably make it useful to pull the > rationale for why 2640 is not adequate (IMO a nice piece of > work, fwiw) into a separate informational document. > > That leads to two questions for the WG: > > (1) Is there really justification for two separate extensions, > one to permit talking with file systems that use characters > outside the ASCII repertoire and one to permit canonical-form > transfer of UTF-8 text files? Or can we get away with a single > UTF-8 extension. > > (2) What is the actual implementation and deployment status of > either draft-ietf-ftpext-utf-8-option-00 and of unmodified RFC > 2640 implementations? In particular, would a single i18n > extension be a significant issue for the installed base? > > john > > > _______________________________________________ > ftpext mailing list > ftpext@ietf.org > https://www.ietf.org/mailman/listinfo/ftpext >