Subject: Re: Normalizing Unicode (Re: [EAI] silly states and header label)

From: "Mail Delivery System" <[email-masked]>
Date: Wed, 29 Mar 2006 12:15:42 +0100

On Tue, 28 Mar 2006 20:35:40 +0100, Chris Newman <[email-masked]>
wrote:

> While the tests you describe can not be discounted, there is one much  
> more important test: the gateway test.
>
> When a local part passes through an 8-to-7 (or 7-to-8) gateway, I  
> believe any transformation to the local-part must be 99.99% reversible  
> and our specifications have to make this very clear.  Things in the  
> middle are permitted to alter the syntax used to represent the local  
> part (for this down-conversion scenario), but are not permitted to alter  
> the contents or semantics in any way.  I consider this critical to  
> minimize the risk of partitioning the network.

That is a fine goal, but may not be achievable. Better to have a
guaranteed bounce when that cannot be achieved than to have no I18N at all.

The one case of a change that will not be reversible is when an address in
some headed contains both a UTF-8 form and an alternate (ASCII) form. Only
the ASCII form will be present when the message is delibered to a strict
RFC2822-only destination.
>
> The recipient domain is permitted to perform any normalization on the  
> recipient local part that it chooses, just as many sites today choose a  
> case-insensitive normalization of US-ASCII local parts.

I think the point of my two tests was that recipient domains need to be
aware that they can make no assumptions regarding the normalization state
of the local parts they receive (because the whole address may have
previously been passed through one of those telephone or fax channels,
this losing any of the content which cannot be conveyed by voice or by
handwriting). Our documents should make it clear that no such reliance may
be placed. But yes, normalization by the recipient domain would be a wise
precaution.

>  Recipients who wish to pass the telephone and fax test to the degree  
> you describe will choose to perform more normalization.  But our  
> specifications do not need to mandate anything in that area for  
> interoperability.

There is a general principle within the Unicode community known as "early
normalization" (which Martin can explain in more detail, since he wrote
the document) which says that it is better to normalize stuff at the point
where it is generated than for every subsequent stage to repeat the
process. One can argue about the robustness of that principle, but it is
probably safer, and better practice, to encourage normalization at the
outset  (MUST or SHOULD).

But hopefully John's "Net UTF-8" proposal is going to set at least some
minimal standard for that.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   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

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