Subject: Re: [idn] internationalized email addresses

From: William Morris <[email-masked]>
Date: Mon, 08 Jan 2001 01:55:59 -0800

On Mon, 8 Jan 2001, Adam M. Costello wrote:

> It just occurred to me that once people can put Unicode characters into
> domain names, they'll also want to put them before the @-sign in email
> addresses.  How is that going to work?
> 
> I'm not sure it makes sense to try to allow Unicode characters in
> domain names without simultaneously thinking about how to allow them
> in the other parts of email addresses and URIs.  Are there other
> name/address-like things that need to be considered as well?

Lets see... unix shell accounts, pop accounts, ftp accounts, anonymous ftp
password. contact management, the list covers almost everything.
Perhaps it would be better to consider what wouldnt be affected.

I dont see how breaking things can be avoided... does the username get
*ACE encoded as well?

-Bill

---

From: Jonathan Rosenne <[email-masked]>
Date: Mon, 08 Jan 2001 17:45:16 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> William Morris
> Sent: Monday, January 08, 2001 11:56 AM
> To: Adam M. Costello
> Cc: idn working group
> Subject: Re: [idn] internationalized email addresses
>
>
>
>

No - it should be everything. It should be possible to use computers and the
Internet without any English.

Jony

---

From: [email-masked]
Date: Mon, 08 Jan 2001 11:34:00 -0700 (PDT)

> I dont see how breaking things can be avoided... does the username get

It seems premature to consider such details until the solution on the right
hand side of the @ is nailed down. How can we answer the question of whether
or not an ACE is to be used until we know for sure there is an ACE?

				Ned

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 9 Jan 2001 00:32:59 +0000

[email-masked] wrote:

> It seems premature to consider such details until the solution on
> the right hand side of the @ is nailed down.  How can we answer the
> question of whether or not an ACE is to be used until we know for sure
> there is an ACE?

How can we decide whether or not there should be an ACE, or design a
good one, before we've considered whether or not it will be useful in
other contexts facing the same problem?

If we need to cook up some method to get Unicode characters into domain
names, and another method to get them into email address local parts,
and another method to get them into URI paths, it would be nice if we
could arrange for the same method (or at least very similar ones) to
work in all three places.  Maybe it will turn out to be impossible, but
it would be a shame to charge ahead with domain names only to realize
too late that some other solution could have covered all three cases.

AMC

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 8 Jan 2001 17:33:35 -0800

>other contexts facing the same problem?

Host names come first. They span all of the protocol elements you are 
concerned with.

As for whether ACE would be a good solution for email local parts if 
they are chosen for host names, all I can say is: of course they 
would. Any presentation layer change that works for the host part of 
an email address will work for the local part.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: [email-masked]
Date: Mon, 08 Jan 2001 23:52:42 -0700 (PDT)

> Host names come first. They span all of the protocol elements you are

Exactly. There is little point in considering local parts now unless they
additionally constrain the problem. (AFAIK they do not.) And even if they did,
the requirements for host names are already so onerous that adding additional
ones imposed by other identifier spaces seems like a really bad idea. We need
closure, not further muddying of the waters.

> an email address will work for the local part.

Yes, but there are some other facets to the local part problem. However, now
is not the time...

					Ned

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Jan 2001 03:49:01 -0500

--On Monday, January 08, 2001 11:52 PM -0700
[email-masked] wrote:

> Exactly. There is little point in considering local parts now
> unless they additionally constrain the problem. (AFAIK they do
> not.) And even if they did, the requirements for host names are
> already so onerous that adding additional ones imposed by other
> identifier spaces seems like a really bad idea. We need

While I agree, we do need to be a bit careful about this, e.g.,

(i) As we move functionality from DNS resolvers to the nameprep
function we need to remember that local-parts are case-sensitive
in ASCII while FQDNs are not.  Preserving that distinction may
require slightly different rules in the two situations.

(ii) While I don't see any obvious issues with local-parts that
would argue for either UTF-8 or ?ACE against the other, we again
will need to be careful:  the variety of conventions used in
local-parts around the world is such that a string that looks
like an ACE prefix is perhaps more likely to occur by accident in
a mail local-part than in a DNS name.   That said, we probably
have more experience with adverse impact of unexpected appearance
of 8bit strings in email clients than with other classes of
clients.  And much of that experience has been fairly horrifying.

Or is that what you meant by "other facets"?

    john

---

From: [email-masked]
Date: Tue, 09 Jan 2001 06:48:57 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internationalized Domain Name Working Group of the IETF.

	Title		: Internationalized Domain Names in URIs and IRIs
	Author(s)	: M. Duerst
	Filename	: draft-ietf-idn-uri-00.txt
	Pages		: 
	Date		: 08-Jan-01
	
This document is a first draft for the provisions necessary to
upgrade the definitions of URIs [RFC 2396] and IRIs (Internationalized
Resource Identifiers, [IRI]) to work with internationalized domain
names.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idn-uri-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idn-uri-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idn-uri-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 10 Jan 2001 00:27:14 +0000

> Filename  : draft-ietf-idn-uri-00.txt

This is interesting.  I'll give some comments after a very quick summary
for those who haven't read it:

URIs will continue to contain only ASCII characters, while IRIs will
allow Unicode characters.  IRIs can be converted to equivalent URIs by
converting each non-ASCII character to UTF-8 and then %hh encoding it.
If domain names are eventually allowed to include non-ASCII characters,
they will be represented in URIs using the same method.

There is a potential problem with host name comparisons.  When URIs
are compared, the comparison between the host parts is supposed to
be case-insensitive.  Software comparing IRIs presumably knows about
case-equivalence among non-ASCII characters, but software comparing URIs
might not.  That means IRIs might use mixed-case host names, but when
they are converted to URIs the non-ASCII characters must be forced to
lower case (in the host part only, not the path).

The draft tells how URIs can be converted back to IRIs.  It would be
nice if the case of the Unicode characters in the host names could
be recovered.  Fortunately, the UTF-8-%hh encoding of any non-ASCII
character always begins with C, D, E, or F.  Therefore I suggest
recording the original case of the non-ASCII character as the case of
the first letter of the %hh encoding.

By the way, if an ACE is adopted for IDNs, there are two very different
ways it could be viewed, which has implications for this URI proposal.
Perhaps domain names really contain non-ASCII characters, and the ACE
is merely a representation that's friendlier to existing software and
protocols.  In that case, this URI proposal applies.  On the other
hand, perhaps domain names do not really contain non-ASCII characters;
the *ACE* is the real name, and the Unicode is merely a representation
that's friendlier to humans.  In that case, this URI proposal would be
moot, because domain names would never contain non-ASCII characters.
I'm not advocating either viewpoint (yet), but it will have to be
decided.

AMC

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Jan 2001 03:06:34 -0000

Adam M. Costello writes:
> There is a potential problem with host name comparisons.

All the problems you describe go away if nameprep is handled in the way
I've been suggesting: registries prohibit bad names, users have whatever
software is needed to type good names, and most programs are left alone.

> Software comparing IRIs presumably knows about case-equivalence among
> non-ASCII characters, but software comparing URIs might not. 

Good names never include uppercase non-ASCII characters. Comparisons of
non-ASCII characters are bitwise comparisons.

> That means IRIs might use mixed-case host names, but when they are
> converted to URIs the non-ASCII characters must be forced to lower
> case (in the host part only, not the path).

All that complexity disappears. Converting IRI to URI is a simple matter
of converting Unicode to UTF-8.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Jan 2001 03:36:30 -0000

[email-masked] writes:
> There is little point in considering local parts now unless they
> additionally constrain the problem. (AFAIK they do not.)

Actually, they do. There are a huge number of mailing lists run by my
ezmlm software and its variants; these programs use

   Return-Path: <list-return-msgnum-user=userhost@listhost>

for deliveries to user@userhost. If your mail software has small limits
on address length, switching userhost from a UTF-8 IDN to an ACE IDN
will drastically increase your chance of hitting those limits.

---Dan

---

From: Keith Moore <[email-masked]>
Date: Wed, 10 Jan 2001 00:06:37 -0500

> Actually, they do.

agreed.  I'm not sure that IDN is the place to discuss it, but
there are several potentially hairy issues associated with using
ACE for local-parts.  including: 

- dots in local-parts (are they ACE encoded or do we just encode 
the atoms and leave the dots alone?) 
- quoted-strings, and the potential for multiple representations
- specials (other than ".") within a local-part which is ACE-encoded
- similarly for other Unicode characters that resemble specials

now it's quite possibly the case that all of these can be worked out
satisfactorily, and it Sure Would Be Nice if the same encoding
routine that is used for IDNs could also be used for local-parts
of an email address.  but it's a bit of a leap to say that whatever
ACE is chosen for IDNs will Just Work for local-parts.

Keith

---

From: [email-masked]
Date: Tue, 09 Jan 2001 22:00:45 -0700 (PDT)

Since this is entirely out of scope for the WG this will be my last posting
on the subject.

> I'm not sure that IDN is the place to discuss it,

It isn't. See the WG charter.

> but

> ...

> of an email address.

The constaints on local parts are a strict subset of those on parts of
domain names, so I don't see a problem here.

> but it's a bit of a leap to say that whatever

Given the constraints on ACEs I disagree, but again, even if I'm wrong I think
letting additional requirements from other identifier spaces leak in here is a
really bad idea.

				Ned

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 10 Jan 2001 09:30:57 +0000

"D. J. Bernstein" <[email-masked]> wrote:

> Good names never include uppercase non-ASCII characters.

That would solve the problem, but at a price.  ASCII names are allowed
to use mixed case.  It would be unfair to deny the same flexibility to
non-ASCII names.  Maybe it's worth sacrificing that flexibility for the
sake of simplicity, but it's something to consider.

> If your mail software has small limits on address length, switching
> userhost from a UTF-8 IDN to an ACE IDN will drastically increase your
> chance of hitting those limits.

UTF-8 gets less than 6 bits per octet on average for the non-ASCII
octets, and the ACEs generally use base-32, which is 5 bits per
character, so that's not much different.  And since some of the ACEs
employ compression techniques, they might even be shorter than UTF-8 for
many strings.

AMC