[ftpext] 2640bis (was: OPTS UTF8 needs work (...probably in FTPEXT2))

Mykyta Yevstifeyev <evnikita2@gmail.com> Sun, 18 September 2011 04:08 UTC

Return-Path: <evnikita2@gmail.com>
X-Original-To: ftpext@ietfa.amsl.com
Delivered-To: ftpext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CD621F854F for <ftpext@ietfa.amsl.com>; 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 <ftpext@ietfa.amsl.com>; 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 <ftpext@ietf.org>; Sat, 17 Sep 2011 21:08:16 -0700 (PDT)
Received: by fxd18 with SMTP id 18so3158547fxd.31 for <ftpext@ietf.org>; 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 <evnikita2@gmail.com>
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> <Pine.LNX.4.64.1108061345320.25266@iskra.ottix.net> <D6B99CDD0BACD162D52A2C1D@[192.168.1.128]>
In-Reply-To: <D6B99CDD0BACD162D52A2C1D@[192.168.1.128]>
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: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 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 <lang-fact> 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. 
<pathname> BNF production directs to <string>, 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"
> <wmaton@ottix.net>  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
>