POP3 mailbox names and IMAP userids

POP3 mailbox names (the argument to the POP3 USER or APOP command) are
not local-parts.  They identify a mailbox on the POP3 server, but are
significant only to the POP3 server.  (RFC 1939 section 7).

In practice, they often are the same as the local-part of the e-mail
address with which the mailbox is associated, but this is neither
required by the standards, nor is it universally true.

It is not uncommon, for instance, for the POP3 mailbox name to be the
entire RFC-822 address, possibly with some other character (such as
percent) substituted for at-sign, presumably to accomodate broken
clients that believe that a POP3 mailbox name cannot contain an
at-sign.

Would it be a reasonable design decision for an IMA-aware POP3 client
to apply ToASCII to mailbox names that contain international
characters?  This would do the right thing for mailbox names that
corresponded to local parts (probably the most common case?).

But what about mailbox names that correspond to an entire e-mail
address (but possibly with the at-sign replaced by some other
punctionation character)?  Is the user going to be on their own here?
The MUA could have explicit support for this kind of structured
mailbox name, but it's going to be cumbersome: the user is going to
have to enter the ILP, the delimiter and the IDN into three separate
fields in the client, or at least tell the client what the delimiter
is, so that the client can apply the correct transformations to the
local part and domain labels embedded within the mailbox name.  Is
this going to be too confusing for users?

As a side note (and I'm not suggesting this would be a good idea): if
we were to split at all non-LDH ASCII characters (and perhaps
full-width dot as well), and we use nameprep, and we use the same
ACE-prefix as IDNA, and the domain happens to obey hostname rules,
then it appears to me that if the client chooses to apply the IMAA
ToASCII function to the mailbox name, it would generally Do The Right
Thing -- ie it would correctly transform the IDN as a side effect,
without having to know what the delimiter was between the local part
and the domain -- as long as it isn't hyphen). 

On to IMAP clients.  I'm not very familliar with IMAP, but as I
understand it the corresponding concept is the IMAP user name or
userid (not the IMAP mailbox, which is more akin to a folder on an
MUA).  Although RFC 2060 has some words to say on internationalized
mailbox names, it appears to say very little that I could find about
userids.  Notably, the grammar allows userids to be unrestricted 8-bit
strings with the restriction that they can't contain NUL.

Does it make sense for an IMAP MUA to choose to apply ToASCII to IMAP
userids?  Or perhaps there are circumstances where a client might want
to send UTF-8 as the userid?  Since IMAP appears to be defined to be
8-bit-clean, it's possible that there are clients that already send
UTF-8 for userids.

So perhaps IMAP MUAs will have to have a user preference to enable ACE
encoding of userids?  Yet another setting for the user to come to
grips with.

The ultimate problem here with both POP and IMAP is that local parts
are being carried in protocol elements that are defined to be opaque,
so it's not clear (to me) what IMAA can or should do about this.

	-roy