Re: Query: Internationalization in addressing components?

[Graham Klyne <GK@xxxxxxxxxxxxxx>]

At 09:33 AM 8/19/00 -0700, Harald Alvestrand wrote:
> At 18:52 18/08/2000 -0700, Dan Wing wrote:
> > It's a good idea.
> >
> > But how would a receiver decide if the following three forms are supposed
> > to be equal?
> >
> >   /ATTN==?ISO-8859-1?Q?Patrik.F=E4ltstr=F6m?=
> >   /ATTN==?US-ASCII?Q?Patrik.Faltstrom?=
> >   /ATTN=Patrik.Faltstrom
> >
> > Perhaps we could just require that text after ATTN, ORG, OFNA, STR, and
> > ADDR shouldn't be matched exactly?
>
> The most common reason for ATTN is to print on fax cover pages; there is 
> no standard way to transfer the ATTN information across a T.4/T.20 fax call.
> So the important thing is to make sure the offramp (fax sender) 
> understands the character set; exact matching isn't that important.
>
> IMHO.

I think this opens a can of worms about just how far it is sensible to take 
the RFC2403/2504/et.seq. addressing framework.

When used as part of an e-mail local address, the normal expectation is 
that exact matching is required to select a mailbox.  But as interpretation 
is defined to be under control of the receiving server, some flexibility is 
theoretically possible.

Personally, I think that putting this kind of non-addressing information in 
an e-mail address is going to lead to problems.  I think there has been a 
desire to carry all of X.400 addressing elements into some kind of e-mail 
format.   I would say that it may be reasonable to map all the _addressing_ 
elements in this way, but that non-addressing elements should be treated in 
some other way.

PS:  As an additional point, I think that RFC 204x explicitly disallows the 
use of =?...?= encoding forms in address fields.

#g
--

------------
Graham Klyne
(GK@xxxxxxx)