Subject: Query: Internationalization in addressing components?

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Aug 2000 13:59:44 +0200

Hello,
I just had reason to discover this quandary:

RFC 2846 (GSTN address elements) defines quite a number of elements that 
have names as their content, including, but not limited to:

- ATTN
- ORG
- OFNA
- STR
- ADDR

Yet their definition is done without specifying any mechanism for encoding 
non-ASCII characters.
This makes them useless for specifying a large percentage of the person 
names in the world, for one thing.

Could I have a few words from the group on the logic behind this choice?

                  Harald A

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: "Lucien Lumbroso" <[email-masked]>
Date: Wed, 16 Aug 2000 08:43:01 +0200

Do you know some fax machine with T44 features for interoperability testing.
Thanks

Lucien LUMBROSO
[email-masked]
web: www.affixcce.com
CCE: 33 1 39 35 48 80

---

From: Dan Wing <[email-masked]>
Date: Fri, 18 Aug 2000 18:52:43 -0700 (PDT)

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?

-d

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 19 Aug 2000 09:33:19 -0700

>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.

                Harald

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 21 Aug 2000 12:18:37 +0100

> It's a good idea.

No, its a standard violation, if I still remember correctly after vacations!
(I need to check the appropriate RFC).

> > Yet their definition is done without specifying any mechanism for encoding 

They are "inside the e-mail address LHS", i.e. inside the <...> angle 
brakets which RFC822 specifies for "machine-usable" addresses.

   RFC822

     mailbox     =  addr-spec                    ; simple address
                 /  phrase route-addr            ; name & addr-spec

     route-addr  =  "<" [route] addr-spec ">"

     route       =  1#("@" domain) ":"           ; path-relative

     addr-spec   =  local-part "@" domain        ; global address

     local-part  =  word *("." word)             ; uninterpreted
                                                 ; case-preserved

     word        =  atom / quoted-string

     atom        =  1*<any CHAR except specials, SPACE and CTLs>

     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                                 ;   quoted chars.

     qtext       =  <any CHAR excepting <">,     ; => may be folded
                     "\" & CR, and including
                     linear-white-space>

     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)

> > names in the world, for one thing.

Exactly... the same problem existing for any "local-part" string. 

As I'm just back from holidays, I do not remember if and which is the 
correct mechanism (if existing) to specify a non CHAR character in 
local-part.

If ANY of these mechanisms is specified, the the same rules apply also to 
the elements (any of them) in RFC 2846... 

but I'm sure Harald remembers the specification, is any... is it?

ciao!
Claudio

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 24 Aug 2000 10:44:30 +0200

>(I need to check the appropriate RFC).

The user needs to get ÆØÅ and other weird stuff onto the cover page of a fax.
The RFC-822 standards insist that the LHS of an email address contain only 
ASCII characters.

We need to resolve the conflict somehow - and I don't find the resolution 
that says you can put ASCII on the cover page and not ÆØÅ (or Chinese) 
terribly satisfactory.

                Harald

---

From: Claudio Allocchio <[email-masked]>
Date: Thu, 24 Aug 2000 11:24:55 +0100

> that says you can put ASCII on the cover page and not ÆØÅ (or Chinese) 

Being an "address element" in local-part that's the current only thing 
which the standard allows. It is NOT completely satisfactory at all...
(remember the same problem in X.400 ?)

Of course there is work in progress on how to specify and generate
full fax cover pages, including not only non-ASCII chars, but anything.

However, I'd not suggest a "special solution" just for this case... if we 
want to allow non-ASCII in local-part, the solution must be global and 
unique... some work for DRUMS WG?

ciao!
Claudio

---

From: Graham Klyne <[email-masked]>
Date: Thu, 24 Aug 2000 11:00:49 +0100

At 09:33 AM 8/19/00 -0700, Harald Alvestrand wrote:
>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
([email-masked])