On humanly-readable (printable) e-mail addresses

This started out as a reply to AMC, but ended up turning into an essay
on the printed representation of e-mail addresses, so I thought I
should post it as a new thread.

--------------------

I think that it's important to realize that there is a component of
the Internet e-mail architecture that is to my knowledge nowhere
explicitly codified, but is nonetheless vitally important.

Whilst, as far as the protocols go, e-mail addresses are abstract
constructs, humans also need to manipulate them in a variety of ways,
eg

	* print them on a business card or other printed document (1)
	* reference them in the body of an e-mail message or other
          electronic document (2)
	* read them out aloud, eg over the telephone, etc (3)

(1) and (2) imply that any e-mail standard needs to define a prefered
printable representation of an address in order to be useful.  X.400 [1]
actually explicitly defines a printed representation of O/R addresses [2]
for use on paper (though I think it's in an informational annex).

(3) is harder, and I don't intend to discuss it further [3]

Whilst UI issues are clearly at the discretion of the application
designer, applications are likely to want to adopt this same printable
representation for input and display, for consistency and ease of use
by non-technical users.  This also helps support (2), since the user
can then just cut and paste an address into the UI.

(This doesn't really apply to X.400, of course, since an O/R address
consists of a number of distinct fields, that might be entered and
displayed separately in the UI -- in the case of X.400 the printed
representation really was intended as just that. [4])

As far as I'm aware, the authors of the Internet mail standards never
thought to explicitly define any form of canonical humanly-readable
representation of e-mail addresses -- but that doesn't mean we don't
have one.

It seems clear from the design of RFC 822 that an 822 message was
intended to be suitable to be presented directly to the user in its
raw form, and all early MUAs do pretty much just that (the only nicety
being to suppress certain uniteresting header fields from display).

So the humanly readable form of an e-mail address -- the form of
address that the authors of the standards expected would be presented
to the user -- is the address as it appears in an RFC 822 header.

Of course, some confusion arises as a result of the failure to
explicitly define this concept.  Just which part of the header
corresponds to the prefered humanly-readable form?  Is it the mailbox
production or the addr-spec production?

However, I would suggest that the mailbox and addr-spec productions of
RFC 822 (in exactly the form they would appear in the header of an RFC
822 message) are, de facto, the two candidates for the notion of
prefered humanly-readable representation, and that most UIs expect the
user to enter the address in one or other of these two
representations.

The addr-spec is undoubtedly the more prevelent representation, and is
for example used almost universally on business cards, where space is
at a premium, and where the person's name will in any case appear
elsewhere on the card.

The more general form of the mailbox production is also occaisionally
used in other contexts; however I suspect that most non-technical
users, when they see the a construct such as

	Roy Badami <[email protected]>

would regard this as just a typographical convention, and would
instictively say that the e-mail address is [email protected].

So, I would posit that it is the addr-spec that constitutes the
Internet community's notion of the prefered humanly-readable form.
(And in any case, if you disagree with me and think that it should
really be a mailbox, I can still give you an addr-spec, since an
addr-spec is always a valid mailbox.)

So what's the point I'm making?  My concern is that internationalized
e-mail addresses must not be introduced onto the Internet in a way
that undermines the notion of a prefered humanly-readable or printable
representation of e-mail addresses, at least insofar as we have one at
the moment.

Currently, if a non-technical user receives a message telling them the
e-mail address of someone, they can just cut and paste it the address
into their e-mail client, and if it's a half-way sane client it will
just work.  A complete newbie might not even understand the
significance of the at-sign, but that doesn't matter.  The same
applies to a non-technical user typing in an address from printed
material.[5][6]

Granted, there are boundary cases, and we can debate them, and even
conclude that it is safe to ignore them.  Can we neglect quoting,
because it's used so rarely in practice?  Ditto unquoted whitespace?

Perhaps we can neglect the fullwidth character issues (users are no
doubt used to the fact that many contexts don't allow them) though by
symmetry with IDNA I think it should be addressed.[7]

I'm not sure exactly what this means for IMAA.  Perhaps we can assume
that implementors will just naturally adopt the internationalized form
of the addr-spec as the prefered humanly-readable form of an
internationalized e-mail address.  Or perhaps this issue needs to be
touched upon in an informational annex.[8]

	-roy

--------------------

[1] Don't be too quick to discount all mention of X.400.  As I
understand it, the X.400 committee gave us most of the terminology we
use today, including MUA, MTA and envelope.  (In X.400 there is an
actual data structure refered to as the envelope; the term has
subsequently been borrowed to refer to the corresponding concept in
other mail protocols, even where no concrete data sturcure embodies
it.)

[2] Originator/Recipient address -- the X.400 term for an e-mail address

[3] though I might add that people are probably used to (or at least
can learn to) verbally describing a sequence of printed characters
(should they need to in order to disambiguate an address), since doing
so is not unique to the domain of e-mail.

[4] for those not familliar with X.400, the Internet analogy would be
that an e-mail address consists of a localpart and a domain, which
(depending on the client) might typically be entered into two separate
fields in the UI. Instead of telling you that my email address is
[email protected], I would tell you that my localpart is 'roy' and my
domain is 'gnomon.org.uk'.  A possible prefered printed representation
might be

	L=roy; D=gnomon.org.uk

and you would be expected to know that this means that you should
enter 'roy' and 'gnomon.org.uk' into the appropriate fields in your
client.

[5] note that I'm assuming the user has familliarity with the script.
Obviously a user unfamilliar with the script (and its corresponding
input method) is unlikely to be able to transcribe the address.

[6] of course, in ASCII the mapping between a printed representation
and a sequence of code points is pretty much unambigous.  In the ISO
10646 world this is less true (even assuming familliarity with the
script).

[7] which (unless we're going to discount quoting as too rare to
matter) implies that fullwidth quote and fullwidth backslash must be
recognized.

[8] in an ideal world, I'd suggest that it would be highly desireable
to define an internationalized version of the mailbox production, too.
Unfortunately RFC 2047's support for multiple character encodings, and
its (consequent?) failure to attempt to address metacharacter quoting
probably makes this task rather intractable