Subject: Ftp-WG: Re: draft-ietf-ftpext-mlst-10 comments

From: "Bryan Starbuck" <[email-masked]>
Date: Thu, 5 Jul 2001 13:11:45 -0500

I'm the owner for the graphical FTP support in Internet Explorer and I
found the same problem.  I found from extensive backward compatibility
tests that the server and client can't start using UTF8 by default.
Therefore, I need the client and server to handshake before they can
safely start using UTF8.

I do this by having the server advertise that it can handle UTF8 by
returning "UTF8" for the FEAT command.  The client will then send "OPTS
UTF8 ON".  If the server returns a successful reply value, both sides
know that everything from then on is in UTF8.

I know that doesn't fully comply with RFC 2640 but it solves the
backward compat issue.  It also works well with FEAT/OPTS.

I would love to hear how other people solved this problem.

-Bryan
(Sorry the reply is so late...)

======================================
Bryan Starbuck - [email-masked]
Software Design Engineer
Windows XP Shell 

-----Original Message-----
From: Brad Clements [mailto:[email-masked]] 
Sent: Thursday, March 09, 2000 5:40 AM
To: FTPEXT Working Group
Subject: Ftp-WG: Re: draft-ietf-ftpext-mlst-10 comments

With respect to Sergey's recent post.

I can't comment on the internationalization issues.

I do think that the pathname format being sent by the server, or the 
client, should be un-ambigious. 

The client should be able to tell the server "I'll accept UTF-8, I can
send 
UTF-8" and the server should be able to say "I can send UTF-8, I can 
receive UTF-8". 

I know the LANG option was mentioned as a way to do some of this, 
but I think it would be good to eleminate "guess" and path-type 
determination based on inspection.

Brad Clements,                [email-masked]   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               AOL-IM: BKClements