Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM?

From: Shawn Steele <[email-masked]>
Date: Wed, 19 Jan 2011 17:41:19 +0000

Nothing requires UTF-8, but we certainly strongly suggest that EAI messages are entirely UTF-8.  IMO you'd be a pretty ugly EAI implementation if that wasn't your default.

------------------------------

Message: 5
Date: Tue, 18 Jan 2011 13:49:00 -0500
From: John C Klensin <[email-masked]>
Subject: Re: [EAI] Consensus Issue #1:  parameter on MAIL FROM?
To: [email-masked]
Cc: IMA Discussion <[email-masked]>
Message-ID: <744A7809405397D2C4D8CB4F@[192.168.1.6]>
Content-Type: text/plain; charset=us-ascii

...

First, nothing in the EAI work, with  or without parameters,
requires that the _message_, and its various body parts, be in
UTF-8.  That is why we have content-types and, for some text/
types, charset parameters (which deliberately and explicitly
specify both a CCS and a particular encoding rather than a cell
in a matrix).  While some of us believe that gradually retiring
everything on the wire other than Unicode-in-UTF-8 (even its
ASCII subset) would be a good idea, making that a requirement
would be well outside EAI's scope as well as implausible for the
near future.

...

---

From: [email-masked]
Date: Wed, 19 Jan 2011 11:01:48 -0800 (PST)

> Nothing requires UTF-8, but we certainly strongly suggest that EAI messages
> are entirely UTF-8.  IMO you'd be a pretty ugly EAI implementation if that
> wasn't your default.

I think this is a very good point worthy of a separate consensus call - the
format document needs to say something like:

    Media types that support multiple charsets SHOULD employ either
    utf-8 or us-ascii.

As Shown wells knows, the continued use of charsets other than utf-8,
especially some of the multibyte ones whose definitions vary depending
on the software you're using, represent a significant ongoing interoperability
problem for email. Given that you have to support utf-8 to support EAI, there
is absolutely no reason for EAI to condone this nonsense.

				Ned

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 20 Jan 2011 13:44:55 -0000

>     Media types that support multiple charsets SHOULD employ either

Not necessarily. If the body of the message cotains some long text in
Chinese, then using some charset encoding other than UTF-8 might make good  
sense because than encoding may be more compact. UTF-8 can often use 3  
(even 4) bytes to encode a character that other charsets can encode in 2  
bytes. In headers, one can tolerate those extra bytes, but not so in long  
bodies.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Claudio Allocchio <[email-masked]>
Date: Fri, 21 Jan 2011 10:48:00 +0100 (CET)

>    Media types that support multiple charsets SHOULD employ either

+1 +2 +3 !!

> is absolutely no reason for EAI to condone this nonsense.

just go back to the messages on the EAI ML where the "Rene'" :-) example 
was done, and you will see how many nonsense variations occured just in 
reporting the accented character. My old, and strict, PINE v4.64 client 
was continuosly struggling to undestand each variation :-) Of course other 
less primitive implementations always showed the accented "e" correctly, 
accepting many variants.

>
> 				Ned
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca