From wmaton@ottix.net Sat Aug 6 10:46: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 1624821F86BC for ; Sat, 6 Aug 2011 10:46:31 -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 O6I7bz4Qeq1g for ; Sat, 6 Aug 2011 10:46:30 -0700 (PDT) Received: from iskra.ottix.net (iskra.ottix.net [IPv6:2001:410:90ff::2]) by ietfa.amsl.com (Postfix) with ESMTP id 01F5321F8588 for ; Sat, 6 Aug 2011 10:46:29 -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 p76HkiAF029174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 6 Aug 2011 13:46:45 -0400 Received: from localhost (wmaton@localhost) by iskra.ottix.net (8.14.4/8.14.3/Submit) with ESMTP id p76HkgUD029171 for ; Sat, 6 Aug 2011 13:46:44 -0400 Date: Sat, 6 Aug 2011 13:46:42 -0400 (EDT) From: "William F. Maton" To: "ftpext@ietf.org" 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 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: Sat, 06 Aug 2011 17:46:31 -0000 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.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? 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. wfms From john-ietf@jck.com Sat Aug 6 14:20:16 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 671D421F862F for ; Sat, 6 Aug 2011 14:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.63 X-Spam-Level: X-Spam-Status: No, score=-102.63 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 yZ3Qpi85EvW5 for ; Sat, 6 Aug 2011 14:20:14 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 37C6521F863C for ; Sat, 6 Aug 2011 14:20:13 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1QpoIG-0006Ot-Iq; Sat, 06 Aug 2011 17:20:28 -0400 X-Vipre-Scanned: 006A974A002766006A9897-TDI Date: Sat, 06 Aug 2011 17:20:27 -0400 From: John C Klensin To: "William F. Maton" , ftpext@ietf.org Message-ID: In-Reply-To: References: <4E1F006F.8050102@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] 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: Sat, 06 Aug 2011 21:20:16 -0000 --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 From cowan@ccil.org Mon Aug 8 18:13: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 82BC721F8BCD; Mon, 8 Aug 2011 18:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6OB9kvQxeNr; Mon, 8 Aug 2011 18:13:16 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id BD6C521F8BA8; Mon, 8 Aug 2011 18:13:16 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.69) (envelope-from ) id 1Qqat4-0006kQ-A8; Mon, 08 Aug 2011 21:13:42 -0400 Date: Mon, 8 Aug 2011 21:13:42 -0400 From: John Cowan To: John C Klensin Message-ID: <20110809011342.GA24628@mercury.ccil.org> References: <4E34DC83.30504@gmail.com> <20110731083853.GB30568@mercury.ccil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Sender: John Cowan X-Mailman-Approved-At: Mon, 08 Aug 2011 19:31:34 -0700 Cc: ftpext@ietf.org, Apps-discuss list 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: Tue, 09 Aug 2011 01:13:17 -0000 John C Klensin scripsit: > 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. The third possibility is to describe what actually works on the browsers and other URI-basec clients that are actually in use, which I believe is what is being done. > Between those two points, there isn't a lot other than slippery > slope. A slippery slope is where people actually live. -- One Word to write them all, John Cowan One Access to find them, http://www.ccil.org/~cowan One Excel to count them all, And thus to Windows bind them. --Mike Champion From barryleiba.mailing.lists@gmail.com Tue Aug 9 11:51:39 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 29CD011E80BE; Tue, 9 Aug 2011 11:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.881 X-Spam-Level: X-Spam-Status: No, score=-102.881 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YggvyH1YIt9i; Tue, 9 Aug 2011 11:51:38 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E46911E80A4; Tue, 9 Aug 2011 11:51:38 -0700 (PDT) Received: by gwb20 with SMTP id 20so232055gwb.31 for ; Tue, 09 Aug 2011 11:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BjukpvIBi1IqkTd79W97aCE7eAG9hfMDEynrW/5m7FI=; b=g2KN92toUusfRq2oY3BWMet7MppYDqxpoXz6/l/zOTOzL1/ptOE/RN0oTmSY76kTsi ltcOMgwU+k8OTjanPrZxSR7ZfSiPXhlU5v9GglArNJcvIwib0yHGM5HUt9ra/68VdoWA xcxkCJX5YfT6t2SXDZiUuWp/5zOm+cx5oJL+8= MIME-Version: 1.0 Received: by 10.236.135.129 with SMTP id u1mr3768767yhi.246.1312915927525; Tue, 09 Aug 2011 11:52:07 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.181.13 with HTTP; Tue, 9 Aug 2011 11:52:07 -0700 (PDT) In-Reply-To: <4E34DC83.30504@gmail.com> References: <4E34DC83.30504@gmail.com> Date: Tue, 9 Aug 2011 14:52:07 -0400 X-Google-Sender-Auth: U7MXy8AiQIdzWs1-sJp10q6wsfk Message-ID: From: Barry Leiba To: Apps-discuss list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: register@uri.arpa, "public-iri@w3.org" , "uri-review@ietf.org" , URI , "ftpext@ietf.org" Subject: Re: [ftpext] [apps-discuss] 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: Tue, 09 Aug 2011 18:51:39 -0000 It's been a week and a half since the original message was posted, but I had to discuss this with the other appsawg chairs, the ftpext2 chairs, and the Applications ADs. On Sun, Jul 31, 2011 at 12:39 AM, Mykyta Yevstifeyev wrote: > Sorry for cross-posting to 6 addresses :-); please send all your comments= to > apps-discuss@ietf.org. No, please do not. This document is NOT to be discussed on apps-discuss. 1. It will not be processed in the appsawg. 2. The ftpext2 chairs have told me that it will not be processed in ftpext2. It is not in their charter, and the WG is not interested in rechartering to add it. 3. The Apps ADs have told me that they will not sponsor it as an individual submission. In other words, as an IETF document, this is dead. There is insufficient energy and interest in the IETF to hash this document out. Please do not continue work on this document. In any case, please do not discuss it on the apps-discuss mailing list. Barry Leiba, appsawg chair >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : The'ftp' URI Scheme >> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Mykyta Yevstifeyev >> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-yevstifeyev-ftp-uri-schem= e-05.txt >> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 29 >> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-07-24 >> >> =A0 =A0This document specifies the'ftp' Uniform Resource Identif= ier >> (URI) >> =A0 =A0scheme, which is used to refer to resources accessible via File >> =A0 =A0Transfer Protocol (FTP). =A0It 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 From hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com Wed Aug 10 04:26:01 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 E69F721F877B for ; Wed, 10 Aug 2011 04:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK8er2iSCaZi for ; Wed, 10 Aug 2011 04:26:01 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1D97621F876F for ; Wed, 10 Aug 2011 04:26:01 -0700 (PDT) Received: by pzk33 with SMTP id 33so3483241pzk.18 for ; Wed, 10 Aug 2011 04:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=MCmsWPN6H5SsVlIhiG9223+UMk+/4mJUQsd/HbkVH1g=; b=t8xQhjDaEjELeocieNndPWA4KMdSXEMyW9PZhZKwrS3bRj5z2952My9/lAJVM9705F dL132zyFKftm0FxZ4q+Q0qcFkuBGHRzMFNEUs6tYxAAuSvYAeuDUGFSQIQgQKAzHgjh7 xAHVvPLWfWLsD2ubiA4OH4I9URfIbv2CN3dHw= Received: by 10.143.20.12 with SMTP id x12mr3801505wfi.105.1312975592144; Wed, 10 Aug 2011 04:26:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.157.2 with HTTP; Wed, 10 Aug 2011 04:26:12 -0700 (PDT) From: Frank Ellermann Date: Wed, 10 Aug 2011 13:26:12 +0200 Message-ID: To: ftpext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: john+ietf@jck.com Subject: [ftpext] ftpext2-typeu-02 X-BeenThere: ftpext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 11:26:02 -0000 Hi, I've read the "hash" and "typeu" drafts. The former only looking for any new MD5 examples for a test suite; no luck, no problem. Some of the links did not work for me, but maybe that was in a section to be removed. For the "typeu" draft I hope that section 1.3 will NOT be removed. If it could be a distraction for implementors maybe move this to an appendix, but please keep it, same idea as for the appendices in RFC 5198. I'm surprised that TYPE became "less used" by the late 1980s, because all troubles I ever had with FTP were caused by a missing "binary" or similar command, when the default TYPE A turned out to be unsuited for binaries, and from my POV unnecessary for text files -- my favourite text editor is an XEDIT-clone and can handle any input line end or tab style. Of course I recall only miserable "missing TYPE I" failures, and not any cases were it worked automatically (as mentioned in section 1.3). In section 2.1 TYPE L was news for me: So the "typecode" in FTP URIs does not only add a somewhat obscure D, it also removes an obscure L. RFC 959 says it stands for "LOCAL TYPE", and the draft says "logical", is that as it should be? The next surprise was that my recipe "always use binary" could fail for servers, which MAY reject any TYPE excluding A. Checking RFC 959 that's the case, but RFC 959 also "recommends" (lower case in old RFC) to offer TYPE I in 3.1.1.3. It would be clearer if the draft translates this to the current style of "mustard" (SHOULD or RECOMMENDED). There is no logical difference between "MAY reject" and "SHOULD support, and MAY reject", but for readers the latter is hopefully clearer -- and I think the "recommended" in RFC 959 would back it. The next interesting point for me was the RFC 5198 profile in section 3, I didn't know (back when RFC 5198 was a draft) that there would be any "profiles", I considered it as the final word of the IETF wrt UTF-8 in Internet protocols. Now it turns out to be not as simple as I thought. And I'm not sure that I understand it correctly: Some characters are discouraged in RFC 5198, but now permitted for FTP in the draft. That (mostly) affects most control codes in RFC 5198 section 2 clause 3, and "SHOULD be avoided" matches "discouraged". The exception for SPace was fixed in an erratum, leaving CR or LF or FF as exceptions in RFC 5198. Appendix B explains the discouraged BEL, BS, HT, VT, and FF (again). The "bare LF" barely escapes the "SHOULD be avoided" in RFC 5198, and I guess that 0x00..0x0C + 0x0E..0x1F + 0x7F are now on the "permitted" side wrt the "typeu" draft. If I got this wrong it might be only me, or an issue in section 3 of the draft. Apparently 0x0D (CR) is still only permitted in CRLF and still MUST NOT occur outside of CRLF or CR+NUL, because the draft does not say that it overrules a "MUST NOT" in RFC 5198. That leaves 0x80..0x9F, first listed as "SHOULD be avoided" like other control codes in RFC 5198. Two statements later and still in section 2 clause 3 0x80..0x9F are caught by a "MUST NOT appear". That's not only discouraged, that's verboten: Does the "typeu" draft stick to RFC 5198 wrt C1 controls, or are they now permitted? I'm not sure if it helps, but IIRC C1 conrols have 7bit representations ESC+d2c(c2d(x)-128+64), e.g., CSI (0x9B) can be given as ESC+'[' (0x5B) in some 7bit encodings -- but that's of course ancient ISO 2022 history and not the topic of "typeu". Maybe permit C1 controls explicitly in the draft, if there is no good reason to treat NEL and CSI completely different from BEL and ESC. RFC 5198 discusses the telnet IAC character. The only case where I met this beast is in FTP, getting rid of an (erroneous) file or directory with 0xFF in its name required to send 0xFF twice. I had to hardcode this oddity in (and the very similar classic REXX ftpsynch.cmd), but can't tell when I last needed this -- years ago, both REXX FTP scripts would never create such names. If that is as it should be (= not only bad luck with an odd FTP server) please mention it somewhere in the draft. RFC 1123 lists it in section 3.2.6 (with a reference to RFC 854 page 13), and maybe RFC 1123 should belong to the normative references in the draft. -Frank From evnikita2@gmail.com Thu Aug 11 20:35:21 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 6B31521F86B9; Thu, 11 Aug 2011 20:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 GvuIM5U4hjss; Thu, 11 Aug 2011 20:35:20 -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 44A6E21F8686; Thu, 11 Aug 2011 20:35:20 -0700 (PDT) Received: by fxe6 with SMTP id 6so2311960fxe.31 for ; Thu, 11 Aug 2011 20:35:55 -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=30weRZ82ideR9RCpOHC6AAarjkBJ0ZDjSgMqOcbIJiU=; b=Fd91rDicXHxcF5UX1ENQVyoC/3hJeNx+gHx5LsSjTnCH3eHstAI/ruhRHB9bcYT9FT MI0mtCxkP/9hva3U3x/dNNJJX6nEB2IEPffNbPqTwpSUM1CnAxRLtOFl+omUD/Xg6X+z xxYV0b9YQa8VvtVRtGb66HnPmgbvHrYjIH/Yo= Received: by 10.223.156.80 with SMTP id v16mr589771faw.11.1313120155471; Thu, 11 Aug 2011 20:35:55 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id f27sm2065051fak.31.2011.08.11.20.35.53 (version=SSLv3 cipher=OTHER); Thu, 11 Aug 2011 20:35:54 -0700 (PDT) Message-ID: <4E449FBF.8050807@gmail.com> Date: Fri, 12 Aug 2011 06:36: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: Barry Leiba References: <4E34DC83.30504@gmail.com> In-Reply-To: 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] [Uri-review] [apps-discuss] 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: Fri, 12 Aug 2011 03:35:21 -0000 09.08.2011 21:52, Barry Leiba wrote: > It's been a week and a half since the original message was posted, but > I had to discuss this with the other appsawg chairs, the ftpext2 > chairs, and the Applications ADs. > > On Sun, Jul 31, 2011 at 12:39 AM, Mykyta Yevstifeyev > wrote: >> Sorry for cross-posting to 6 addresses :-); please send all your comments to >> apps-discuss@ietf.org. > No, please do not. This document is NOT to be discussed on apps-discuss. > 1. It will not be processed in the appsawg. > 2. The ftpext2 chairs have told me that it will not be processed in > ftpext2. It is not in their charter, and the WG is not interested in > rechartering to add it. > 3. The Apps ADs have told me that they will not sponsor it as an > individual submission. > > In other words, as an IETF document, this is dead. There is > insufficient energy and interest in the IETF to hash this document > out. Please do not continue work on this document. In any case, > please do not discuss it on the apps-discuss mailing list. Barry, I'm very unlikely to stop working on the document. Anyway, nothing in your message disallows me to wait for better times, when the situation changes. Mykyta > > Barry Leiba, appsawg chair > >>> 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 > _______________________________________________ > Uri-review mailing list > Uri-review@ietf.org > https://www.ietf.org/mailman/listinfo/uri-review >