Re: Can we back up a bit and ask some basic questions? Analternate model

   The IETF has a long history of very bad outcomes when we release two 
   very different ways to do the same thing. In the email world, the 
   fact that S/MIME and PGP are both IETF standards has pretty much 
   prevented any sender from being able to assume what the recipient can 
   receive. The fact that there are two standardized PKIX certificate 
   enrollment protocols has caused it to be almost impossible to roll 
   out secure email or VPNs in a reasonable fashion. And so on.

I'm not sure that you understand what I was proposing.  A better
analogy would be to pose the question: would it have been a good thing
for ESMTP and 8BITMIME to have been defined concurrently with the base
MIME standards?  (That isn't intended as a loaded question; "No, it
wouldn't have made any difference" is a perfectly valid answer.)

I'm proposing that the two solutions are defined as part of an
encompassing IMA Architecture, not independently without regard to
interoperability.

This is what I imagine the world will be like a few years from now:

All IMA-aware systems will support IMAA (this will be a mandatory part
of some IMA Architecture standard).

Many systems, particularly those in parts of the world where IMAs are
popular, will use ESMTP extensions to exchange IMAs in native UTF-8,
and to exchange messages in an extended format that allows native UTF-8
addresses in the headers.

Systems that receive a message with UTF-8 addresses and need to relay
it to a system that doesn't support the requisite ESMTP extensions
will need to apply ToASCII to both the envelope and header addresses
before forwarding the message.  This is analogous to the (admitedly
inconsistently implemented) requirement that a system which receives
an 8BITMIME message converts it to a suitable 7-bit encoding if the
destination system doesn't support 8BITMIME.

Maybe defining a complete IMA Architecture is too much to tackle at
once.  As I envision it, IMAA will probably be the only manadatory
part of the IMA Architecture, so maybe there's a benefit in getting
that done quickly.

However, I think there may be benefits in putting some though into the
bigger picture of the IMA Architecture, even if we decide to
concentrate on IMAA for the present.

One example: if we were for sake of argument to decide that ILPs
should be case insensitive, but that it would be desirable (but not
absolutely essential) to make them case preserving, our decision as to
whether to put any effort into making IMAA preserve the case of
local-parts might be strongly influenced by whether we believe that
another component of the ultimate IMA Architecture would generally
carry e-mail addresses in ILP-aware and IDN-aware slots.

Only half jokingly, I propose that we repurpose the acronym IMAA to
mean IMA Architecture, and come up with a new name for the protocol
described in the base document.  Part of the reason for this is that I
don't actually think that IMAA is a good name for the base document
protocol, since it has consequences that go beyond end-user
applications.

      -roy