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

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 18 Sep 2011 07:11:06 +0300

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"
> <[email-masked]>  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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ftpext
>