A couple of comments on the open issues...

[Roy Badami <roy@xxxxxxxxxxxxx>]

[I'm not a subscriber to the list, so it would be helpful to cc me on
any reply, though I do intend to review the archives periodically]

By way of background, I should say that I became interested in IDNs
late on in the process.  I followed much of the later part of the
process on the idn list via the archives, but never really felt the
need to post, since my opinions tended to be well represented by many
other long-standing members of the WG.

However, I hope you won't mind my voicing my opinions on a couple of
the open issues raised in the IMAA document.

I shan't get into the obvious big issue of case (in)sensitivity, since
this is not an issue I have strong opinions on, and I have confidence
that this forum (and any subsequent WG) will do something sensible in
that respect.  But a couple of other issues in the document seemed
worthy of comment:

    Rather than transform the entire local part as a single unit, another
    approach is to pick out smaller pieces of the local part, and
    transform each piece independently, analogous to the way labels are
    picked out of a domain name and transformed independently.  The
    tradeoff is complexity versus compatibility with various unofficial
    conventions for structured local parts, like owner-listname, user+tag,
    sublocal.local, path!user, etc.

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.
(Delimiter is to my knowledge typically either '+' or '-', though it's
possible that there are others in use).

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.  There
are several software packages available to users of Unix and Unix-like
machines that make use of this functionality, and I think it is
important that users of IMAs (if that's the right term) are not
excluded or seriously inconvenienced in the use of such packages.

Secondly:

    Should we consider using punctuation other than hyphens in the ACE
    prefix?  Then we could use the same letters as IDNA.  For example, if
    the IDNA ACE prefix were bq--, the IMAA ACE prefix could be bq== or
    bq##

I'm not going to voice an opinion on the specific question posed, but
I would like to counsel against using either the equals sign or the
hash sign for this purpose.

In particular, 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.  In general, I suspect that
this is most likely to be the case when a local non-RFC822 mail system
is gatewaying into the RFC822 world.  For instance, I am aware that
Lotus Notes systems running release 4 have problems sending mail to
RFC822 addresses containing plus signs, at least in the default
configuration.

Whilst such restrictions in Internet e-mail addressing are clearly
undesirable, and whilst some such gateways may have mechanisms for
escaping unusual characters in order to represent them within local
constraints, it remains a fact of life that systems such as these are
currently deployed on the Internet in significant numbers, and I think
it is desirable that IMAA does not exacerbate the deficiencies of such
legacy systems to the point of rendering them incapable of
communicating with users of IMAs.

A second argument for not straying outside the traditional character
set I define above is the danger that 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).  We all know that
there are deployed systems that ascribe special meaning to the
characters '%' and '!', despite the fact that these characters have no
special meaning in RFC822.  There may be systems out there that
ascribe special meaning to other unusual characters, too, and use of
these characters may make adoption of IMAA problematic for sites which
depend on such systems.

These are just my initial thoughts on a couple of the issues that
seemed important.

       -roy