Subject: Re: [ftpext] OPTS UTF8 needs work (...probably in FTPEXT2)

From: "William F. Maton" <[email-masked]>
Date: Sat, 6 Aug 2011 13:46:42 -0400 (EDT)

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 C Klensin <[email-masked]>
Date: Sat, 06 Aug 2011 17:20:27 -0400

--On Saturday, August 06, 2011 13:46 -0400 "William F. Maton"
<[email-masked]> wrote:

>> 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