Re: Problems of Internationalized Mail Address eXtensions (IMAX)

At 12:38 PM +0100 2/26/03, Simon Josefsson wrote:
>My question was sincere.  IMAX appears to be a solution for
>internationalization of MTAs, at the SMTP layer.  It does not propose
>solving the internationalization problem for MUAs.

Yes, it does. It shows exactly how an MUA should display ACE names.

>   SMTP is an
>interactive protocol between two end-entities, and can therefor
>negotiate non-ASCII support, which is different from RFC (2)822 where
>all entities that will handle the stored data is not able to interact
>with the creator of that data to negotiate non-ASCII.  IMAX takes
>advantage of this difference.  I believe it would be possible to
>design a internationalization solution for RFC (2)822 that would be
>distinct from a SMTP internationalization solution.

We did that with IMAA. If you have a different proposal, please write 
an Internet Draft for it.

>   Those two
>distinctions could be investigated in parallel and evaluated on their
>own merits.

Yes, but we need Internet Drafts before we can do that.

>   If you think this is ludicrous and want this to be a
>productive discussion, please take the question seriously and explain
>in technical terms why your proposal is better.

How many times should this be done? IMAA is certainly going to be 
simpler than any proposal that requires changes to both MTAs and MUAs 
because it localizes the changes to one place (the MUA). It allows 
other entities in the Internet Mail system to easily use the 
internationalized email addresses without having to know anything 
about multiple charsets and repertoires.

>(If you are thinking
>  > of a protocol that doesn't require punycode but would instead simply
>>  bounce or lose mail that was sent to MTAs that didn't understand the
>>  new protocol, please don't bother writing an Internet draft...)
>
>Why not?

Because no one who cares about Internet mail wants to start bouncing 
mail messages unpredictably.

Seriously, if you want to do that, don't do it here. Start your own 
mailing list. I'm quite willing to have folks who propose different 
solutions that are as reliable as IMAA-ACE discuss them here, because 
then we can pick just one. But people proposing to make Internet mail 
unreliable aren't welcome.

>I can only interprete your dismissal of alternative solutions without
>a serious analysis that you either have done this analysis already and
>know the answers or that you don't want to see alternative ideas
>discussed.

The former.

>   In the former case, I think it would be useful to read
>your analysis.

No analysis needed. A "new and improved" mail system that is less 
reliable is a non-starter.

>  >>I would want the log file to contain...
>>
>>  Fine. Ask your vendor to include that feature. This is not part of a
>>  protocol specification.
>
>I'm the vendor, and I'm here to understand how to implement it.  If
>the protocol specification doesn't give guidance or have considered
>how it will be implemented, I fear it will not work.

Then you're not a useful vendor. Others will be able to easily figure 
out where they want to write raw ACE blobs and where they want to 
convert them into Unicode characters (and, hopefully, which encoding 
to use for the Unicode characters).

>I note that punycode is a encoding scheme, and thus IDNA and IMAA
>violates this by lacking an ability to use UTF-8.

Right.

>  > You should take this up with Harald Alvestrand, the author of RFC
>>  2277. Note that IDN chose not to use UTF-8, and Harald (as chair of
>>  the IESG) approved it to be on standards track.
>
>Perhaps he is busy with other things,

He posted 152 messages to the IDN WG mailing list, some of which were 
on this very topic. It seems likely that he was paying attention...

>  but I will ask if the policy in
>RFC 2277 doesn't apply any more, or where the variance procedure steps
>for the IDN working group are documented.  Thanks for the suggestion.

Let us know what you find out.

--Paul Hoffman, Director
--Internet Mail Consortium