Re: A couple of comments on the open issues...

Roy Badami <[email protected]> wrote:

> there may be sites that wish to allow the creation of
> internationalized mailboxes without being in a position to upgrade to
> IMAA-compliant software.
>
> In some cases, it may be adequate simply to create mailboxes within
> the legacy system corresponding to the ACE-encoded local part.

Indeed, one of the primary design goals of IMAA, like IDNA, is that
it not be necessary to upgrade any infrastructure, but only end-user
applications.

> I'm particular keen that the use of a tag or suffix with a local
> username in not broken by IMAA.  Many MTAs provide the functionality
> that all mail addressed to <user><delimiter><suffix> will be delivered
> to <user>, either by default, or as a configuration option.
>
> This effectively allows a user of such an MTA (that has been suitably
> configureed) to have multiple e-mail addresses without requiring any
> action on the part of the mail administrator, and allows the user to
> run scripts that process their mail according to the suffix.

So if IMAA operates on the entire local part, this multiple-address
feature will be unavailable to users with internationalized local parts.
This is a good argument in favor of having IMAA operate independently on
subparts of the local part.

(Of course, there are arguments on the other side too, and I'm sure
we'll hear them.  I haven't yet chosen a side in this debate.)

> I would urge the list to ensure that as far as possible local parts
> generated by any IMAA specification adhere to a far more conservative
> character set than that mandated by RFC822/2822, namely the set of
> characters that has historically been commonplace in local parts.  I
> would personally regard this as being alphanumerics, period, hyphen
> and underscore.
>
> It is unfortunately still the case that there are systems in
> widespread use which have difficulty in accomodating RFC822 addresses
> that contain valid but unusual characters.
>
> there may be MTAs in use which ascribe special meaning to unusual
> characters in a way which is not easily configurable (if it is
> configurable at all).

I think that's also a good argument.  I have a strong gut feeling that
we wouldn't want dots in the prefix, for any number of reasons.

AMC