Subject: Ftp-WG: RE: draft-ietf-ftpext-intl-ftp-05.txt

From: "Curtin, William" <[email-masked]>
Date: Tue, 6 Oct 1998 11:41:01 -0400

I'm looking at the ADs comments to the I18n draft (see below). 
          
          It seems that Patrick is asking me to mandate UTF encoding of the
text 
          part of command responses (i.e. "error messages" per RFC 2130). I 
          assume this is for 100-500 command responses and not just the 400
- 
          500 command responses. While RFC 2130 page 21 does mention
language 
          tagging for banners and error messages (but doesn't really mention

          UTF8 encoding), I thought there was discussion of this on the list

          and that the decision was to continue to use ASCII. Also section
10 
          of the MLST draft suggests that the only encoding for protocol 
          responses is ASCII.
          
          It seems to me that based on section 10 of the MLST draft that the
encoding
          should not be UTF-8 but ASCII. I can address Patrick's suggestion
to include
          a Lang feature to negotiate a language that the banner and
protocol textual
          responses should be returned in. This too may be a slippery slope
as many 
          languages can not be expressed in ASCII. 
          
          Do I need to include UTF8 encoding for the text part of the
command 
          responses? If so I guess that Section 10 of MLST would have to be 
          changed.

          My inclination is to require that banners and the text part of
responses
          be encoded in utf-8, and that a Lang feature be added to negotiate
a language
          that they will be returned in.
          
                                        Any thoughts?

                                            bill

> -----Original Message-----
> From: Patrik FSltstr÷m [SMTP:[email-masked]] 
> Sent: Thursday, September 10, 1998 3:04 PM
> To: William Curtin; Paul Hethmon [SMTP:[email-masked]] 
> Cc: Harald Tveit Alvestrand 
> [SMTP:[email-masked]] ; Keith
> Moore [SMTP:[email-masked]] 
> Subject: draft-ietf-ftpext-intl-ftp-05.txt
> 
> 
> These are the issues that were brought up when discussing 
> this I-D in the IESG.
> 
> Question:
> 
> This document deals only with internationalization of file names.
> As identified by RFC 2130, internationalization is also 
> needed in error
> messages.
> 
> The WG may choose to:
> 
> - Explicitly defer the problem to another, later document
> - (Do the Right Thing and) declare that servers with UTF8 in 
> FEAT will also
>   use UTF8 in error messages, when appropriate
> - As above, but also add a LANG feature to let the client 
> select language
>   for error messages
> 
> Not mentioning it is not an option.
> 
> Nits:
> 
> - Section 1 needs to refer to 2277, not 2130
> - Section 3.2 hasn't indented "UTF8" in the example response, 
> even though
>   the very next sentence says the indentation is required.
> 
> 
> Please address these issues, and submit a new version of the 
> I-D to the
> repository. Also, please send answers (and questions) to this 
> mail to all
> persons on the To and Cc of this mail.
> 
>    Regards, Patrik Fältström
>    Area Director, Applications Area
>

---

From: "Martin J. Duerst" <[email-masked]>
Date: Tue, 6 Oct 1998 23:39:26 -0400

At 11:41 98/10/06 -0400, Curtin, William wrote:
> It seems that Patrick is asking me to mandate UTF encoding of the text 
> part of command responses (i.e. "error messages" per RFC 2130).

Patrick - Please don't use "UTF8" (as you did below), but use
"UTF-8". Otherwise, people will start to write "charset=UTF8",
and we have another useless alias.

William, please don't use "UTF". There are quite a few UTFs,
with very differing properties.

> I assume this is for 100-500 command responses and not just the 400 - 
> 500 command responses. While RFC 2130 page 21 does mention language 
> and that the decision was to continue to use ASCII. Also section 10 
> It seems to me that based on section 10 of the MLST draft that the encoding
> should not be UTF-8 but ASCII. I can address Patrick's suggestion to include
> a Lang feature to negotiate a language that the banner and protocol textual
> responses should be returned in. This too may be a slippery slope as many 

I think Patrick is expressing this already in his list of options:
It doesn't make sense to be able to negotiate language but to
be restricted to ASCII. There are extremely few languages that
can (decently) be expressed in ASCII only.

> Do I need to include UTF8 encoding for the text part of the command 
> My inclination is to require that banners and the text part of responses
> be encoded in utf-8,

I think we could define the "require" in the same way that we
currently require utf-8 for filenames. This would "semi-legalize"
the current practice of sending banners (and maybe error messages;
I don't know) in some legacy encoding.

> and that a Lang feature be added to negotiate a language

Language negotiation for banners would definitely be a very
valuable feature. Error messages in the protocol are usually
rather short, and in many cases not very interesting for the
human user. Banners, on the other hand, tend to get long, and
because they are addressed to the human user, what happens now
is that the whole banner is e.g. sent in two languages, which
can take up two screenfuls.

Regards,   Martin.

> > From: Patrik FSltstr$B�N(J [SMTP:[email-masked]] 
> >    Regards, Patrik F$BgM(Jtstr$B‹N(J