Re: Problems of Internationalized Mail Address eXtensions (IMAX)

Paul Hoffman / IMC <[email protected]> writes:

> At 8:53 PM +0100 2/24/03, Simon Josefsson wrote:
>>I'm saying that when implementing a MTA it is easier if I don't have
>>to implement punycode in order to support non-ASCII.
>
> And you don't have to. IMAA-ACE works with no changes to the MTA. IMAX
> forces changes, including changing the maximum line lengths for the
> MAIL FROM and RCPT TO commands. That's pretty non-trivial.

Perhaps IMAX can be modified so it doesn't require those changes?

>>How would an ESMTP extension with an ACE fallback (i.e., IMAX) involve
>>bouncing or dropping mail?
>
> The second paragraph of section 2.3 sure sounds like it would bounce
> things instead of doing an ACE fallback.

I don't get that impression.  It sounds to me that unless IMAX is
used, the interpretation and handling of the mail addresses is out of
scope of IMAX.  Perhaps it would be good to clarify that section so
whatever the intention was, it is made specific?

>>Punycode decoding is not optional if the MTA wants to support
>>non-ASCII.
>
> Where in the IMAA document does it say that? I believe you are
> completely wrong here.

Are you saying that if I implement a MTA and want to support non-ASCII
mail addresses in the places where MTAs use ASCII mail addresses
today, that MTA need not implement punycode decoding?

If so, how would you translate an incoming punycoded string into
non-ASCII data that is stored in the log file, for instance?

If you are saying that the MTA should put the IMAA encoded mail
address in the log file, I'd say then that MTA doesn't support
non-ASCII.  An essential feature of supporting non-ASCII is to make it
possible for the user of the application to actually see the
characters.  ASCII encoding them and displaying them to the user
doesn't make the application support non-ASCII in practice.  It would
be like claiming to support Unicode in a terminal emulator when it
only displayed Base64 encoding of the UTF-8 encoded Unicode code
points.

>>A punycode encoder is required if the MTA handle non-ASCII data in
>>decoded, normal, format.  Like in the user interface for /etc/aliases,
>>/etc/mail/virtusertable etc.
>
> Neither of those are controlled by the MTA. This is getting pretty silly.

That was not a generic example, it was an example for one MTA
implementation: Sendmail.  It uses and control those files.

>>   If it doesn't handle non-ASCII in normal
>>format, it might as well not support non-ASCII at all since the user
>>would never notice the different.
>
> You are mixing up the MTA and the MUA.

I wasn't clear.  I meant the user of the MTA, i.e., the administrator.
Administrators have non-ASCII requirements too.

>>   In theory, I agree that a
>>(probably) compliant MTA could be developed that didn't include a
>>punycode encoder, but it would be limited.
>
> You have mixed up compliance with marketability.

Perhaps.  I'd like to consider that as being open to what practical
requirements exists before designing a solution.

MTA implementations, nor internationalization solutions for MTAs,
exist in a vacuum.  If it is impossible to implement an
internationalized product and being compliant, the specification has a
problem.

>>  > In what way is using a new ESMTP extension more "easily maintained"?
>>>  That certainly is not the experience in the SMTP world so far.
>>
>>It appears easier to implement a MTA that handle non-ASCII data, than
>>to implement a MTA that handle non-ASCII data AND punycode
>>decoding/encoding of that data.
>
> But you keep talking about the need to handle fallback. Handling two
> protocols is not easier than handling one in any universe.

True.  Yes, the fallback is a problem.  Hm.  Perhaps those interested
in non-ASCII need to require the use of modern software at the
receiver and the sender, then implementations doesn't need to
implement the fall back case.

>>  > Clean is in the eye of the beholder. You and I like UTF-8, but many
>>  > people don't. Forcing them to use our preferred charset isn't a good
>>  > practice if it can be avoided.
>>
>>I agree completely.  This is one of my problems with IDNA and IMAA, it
>>forces Unicode on everyone.
>
> Unicode is not a charset.

I'm not sure if you genuinely missed my point due to this
misunderstanding, but assuming you did, let me correct myself: replace
"Unicode" with "Any charset encoding format of Unicode".  I'm sorry
that I cannot express this in any clearer way, perhaps someone who
manages to comprehend what I mean can formulate this in a more precise
way so my point gets through.

I note that IMAA talks about representing characters using the Unicode
"character set".  I use charset as a short-hand for character set, but
apparently that must be wrong if IMAA and what you say is consistent.
What distinct definitions of "character set" and "charset" do you use?