What is IMAA: some scenarios for deployment

The goal of this group is clearly to make IMAs (internationalized mail
addresses) usable on the Internet, and a subgoal that has been
inherited from the IDNA work seems to be to try and do that in a way
that eliminates (or at least minimises) the impact in terms of
requiring changes to existing infrastructure.

But I'm not sure we're all clear exactly what we expect from this
subgoal, so I'd like to analyse it further with a few example
scenarios.

Scenario 1a

A user of a POP/IMAP service from an ISP.  The user has no
control over the domain, but can choose their local mailbox name when
they sign up for the service.  The service has not been upgraded to
contain any support for IMAs.

The user wishes to use an address containing an internationalized
local-part, and wishes to be able to conveniently send mail to and
receive mail from other users of IMAs.

IMAA will work here with just an upgrade to an IMA-aware MUA, as long
as the user is able to register the ACE-encoded mailbox name within
any syntax and length restrictions imposed by the ISP.

Clearly the sign-up process will be cumbersome, but this can be
assisted by an ACE-conversion tool bundled with the IMA-aware MUA.

The ISP could choose to provide an IMA-aware sign up process at a
later date, and this would be a relatively minor upgrade to their
systems.  All it would require is for the sign-up form to perform the
ToASCII transformation for the user; it wouldn't require changes to
the ISPs core e-mail infrastructure.  In fact, in cases where sign-up
is performed by means of an application provided to the user on CD-ROM
(rather than by means of a web form), it wouldn't necessarily require
any changes to the ISP's infrastructure at all, just an enhancement to
the ISP's sign-up application.

If we care about supporting this scenario, then we need to be
sympathetic towards the kinds of restrictions on mailbox names that
are likely to exist in this context.  Anyone know what the
restrictions on hotmail addresses are, for instance?

Scenario 1b

Same user, same requirements, but the user prefers to use the ISP's
web mail interface rather than a POP/IMAP client.  Whilst the user can
still advertise an address containing an internationalized local-part,
the user will have to work with ACE-encoded addresses within the
web-mail interface.  There is nothing we can do to fix this; the ISP
must upgrade their web mail system to one which is IMA aware, and this
is likely to be a major project for a large ISP.

This is one way in which IMAA deployment is going to be more
problematic than say, the deployment of IDNs in URLs.  Virtually every
ISP that provides end-user e-mail services operates a web mail
service, which is essentially a large, centralized MUA.  Requiring all
MUAs to be upgraded therefore *does* require a major infrastructure
upgrade on the part of virtually every ISP.  This is not the fault of
IMAA, of course -- any IMA solution will have this consequence.


Scenario 2a

An small organization runs its own Unix mail server.  The organization
has registered their own domain name, and the best preference MX
record points to their own mail server.  A second MX record points to
their ISP, who will queue mail for them if their server is down.
Neither the organization's mail server not the ISPs mail
infrastructure is IMA-aware.

Users pick up mail from the organizations internal mail server using a
variety of clients, including local Unix clients and POP/IMAP clients.

The organization wishes to register an IDN, and to use fully
internationalised e-mail addresses (ie both the local-part and the
domain contain international characters).

Clearly this can be solved in the same way as scenario 1a.  All that
is needed is to upgrade the client software to be IMA-aware.
Administering the mail server will be cumbersome (but not impossible)
since all local-parts and domains will have to be entered in
ACE-encoded form.

Upgrading to an IMA-aware version of the MTA software that provides
tools to allow the administrator to work with the internationalized
local-parts and domains directly is beneficial, but not required.


Scenario 2b

Same organization as the above scenario, but some of the power users
who were used to using the subaddressing facilities of their MTA (and
perhaps other functionality relying on structured local-parts) are
finding that IMAA doesn't really meet their needs, and are staying
with ASCII e-mail addresses.

The organization expedites their upgrade to an IMA-aware MTA (which
they had been planning anyway for the reasons described in scenario 2a
above).  The new MTA parses structured addresses only after applying
the ToUnicode operation, and the users who want IMA-aware
subaddressing are happy.  Granted, these subaddresses are not humanly
readable to correspondents using non-IMA-aware software, but this
isn't perceived by the users to be a major problem, since
correspondents aren't expected to manipulate the subaddresses
themselves, and in any case the users maintain alternate ASCII
addresses for use when corresponding with people who don't use
IMA-aware MUAs.

Note that whilst the organization had to upgrade their MTA to support
subaddressing in IMAs, this has no impact on the backup MX service
which is provided by their ISP, which remains IMA-unware.


Is scenario 2b really that bad?  I don't think so, particularly if
IMAA contains some informational matter on this issue and suggests
that MTA authors wishing to allow subaddressing consider doing
subaddressing after ToUnicode.

So actually, I'm now sitting on the fence again on the issue of
splitting the domain at anything that might locally be used as a
separator.  Particularly if the increase in length of the encoded
local-part impacts the ability to support scenario 1a above.  (But
note that if we encode the local-part as a single opaque object, we
need to fix the consecutive dots issue as this will probably impact on
the ability to support scenario 1a.)

	  -roy