Subject: Re: Is it good to publish a new RFC on SMTP without internationalisation?

From: Charles Lindsey <[email-masked]>
Date: Thu, 16 Mar 2000 14:46:20 +0000 (GMT)

On Thu, 16 Mar 2000 13:59:50 +0200
	Matti Aarnio <[email-masked]> said...

> 	You do.  You CAN'T introduce UTF-8 in ADDRESSES.
> 	You can (with similar means to 8BITMIME) do it in
> 	message BODY (and perhaps in headers).

Well getting it allowed in headers (via a suitable ESMTP extension, or
whatever) would be a useful start. You could not even contemplate it in
envelopes until that had been done. AFAIK sendmail is the only major
transport agent that would not support it already.
> 
> 	SMTP transport on  MAIL FROM / RCPT TO handles about
> 	ADDRESSES, those you can't modify to use UTF-8 encoded
> 	characters.

Indeed not. You need to get it accepted in DNS first. That may well
come, but it will be an even bigger upheaval than the move to IPv6, and
that is hardly roaring ahead at the moment :-( . It might be allowed in
the local part of an addr-spec before then, however.

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      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: Robert Elz <[email-masked]>
Date: Fri, 17 Mar 2000 05:33:50 +1100

Date:        Thu, 16 Mar 2000 14:46:20 +0000 (GMT)
    From:        Charles Lindsey <[email-masked]>
    Message-ID:  <[email-masked]>

  | Indeed not. You need to get it accepted in DNS first. That may well
  | come, but it will be an even bigger upheaval than the move to IPv6,

Not at all, anything is OK in the DNS, now and since day 1.   The only
thing that needs to be done for the DNS is to define how to interpret
the data that is there - which for now is "ascii or indeterminate".
Simply defining "It is UTF-8" or "If the first byte >= 0x80 then it
is a language tag, and what follows is interpreted as it defines" or
something like that.

The real problems with making international domain names are all in the
applications (like SMTP, etc) which use the things, not in storing them
in the DNS.

kre

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Mar 2000 14:51:38 -0500

> whatever) would be a useful start.

no it wouldn't.  because it implies having two forms of each email 
address (one ascii and one utf-8) and some sort of conversion at 
the boundaries, with the usual bitrot due to implementation errors.
and when addresses leak  across the boundaries (which they will)
chances are they won't be usable from the other side.  

also, the vast majority of user agents still can't get RFC 2047 right 
after 8 or so years (since the original version).  by which I mean that
they generate unencoded, unlabelled 8bit text (using random character
sets) in headers which are supposed to be pure ASCII; they include
encoded-words in places that they are not allowed (such as within
quoted strings); they generate headers that contain encoded-words but
are not legal syntax. etc.  the only reason email still works at all 
in the presence of so many implementation bugs, is that encoded words
only affect the display  of message headers and email addresses are 
still pure ascii (and thus not subject to translation).

and RFC 2047 is *much* easier to implement correctly than it would be to
do non-ascii characters in addresses.    

(for example, since RFC 2047 is only for displayable strings, not for 
addresses that need to be matched, there's no need to convert strings 
to any canonical form or charset before encoding in RFC 2047.)

Keith