standardized local-part structuring

Folks,

AMC> Therefore, although IMAA is designed to allow the creation of
AMC> internationalized local parts without upgrades of MTAs, there could be
AMC> a few domains in which users will in fact have to wait for an upgrade
AMC> of their MTA before creating internationalized local parts.  This
AMC> inconvenience can arise only in domains that use letters or digits or
AMC> positions as delimiters.


IMAA attempts to deal with internal structure of the local-part, by segmenting
the encoded string into multiple sub-parts. Internal structure is a local
matter, except for some very constrained IETF standards. That is why there are
so many different conventions for the internal structure of local-parts.

Internal structure is, in fact, an MUA/MTA convention, for the target system.
To the extent that IMAA feels compelled to produce an IETF standard that
purports compatibility with local conventions for local-part structure, it is
fundamental that the IMAA specification deal with the MUA/MTA interaction.

It would be quite a bit simpler if the IMAA spec did _not_ attempt to juggle
local convention issues, but instead tried to avoid dealing with them
explicitly.

This becomes quite easy, if IMAA uses the perspective of data encoding, in the
same sense as MIME content-transfer-encoding. This is, after all, all that
IMAA is attempting to do: Put fat characters into a space only designed for
thin characters. (IE, encoding characters that use more bits, into a character
space that uses fewer.)

IMAA should list a set of reserved ASCII characters. TOAscii translation
should never create a string that uses any of those characters, and ToUnicode
should simply pass those characters unchanged.

As a starting point, I'll suggest that the set of reserved characters be all
ASCII graphic characters.  If folks feel compelled to be more clever than
that, then I suggest:

      ,./\;'":[]{}=+-()*&$#@!|?`~

I believe every one of those has gotten used in local convention structuring
or global email syntactic standards. (And from what I can tell, this turns out
to be the full set of ascii graphics...)

d/

ps. the use of an infix, rather than prefix, "signal" string, seems pretty
strange.  As I understand it, the claimed reason for using it is specifically
to deal with segmentation.  This requirement goes away if translation simply
uses the "reserved character" model, thereby having IMAA essentially simplied
into ignoring local convention issues.

--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>