[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems of Internationalized Mail Address eXtensions (IMAX)


At 1:50 PM +0100 2/25/03, Simon Josefsson wrote:
> 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?

You are (again) confusing the protocol with the implementation. The protocol does not require these things; the implementation might.

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

MTA implementations that want to write into log files already need Punycode decoding for the host names. Your complaint here is invalid.

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.

You are free to say that. Others would disagree. In the case of IMAX, what would you want in your log file. All UTF-8? That means you need converters from every accepted charset to UTF-8. Careful sysadmins would probably want to know *exactly* what came in, not some converted form, but that means that their log file would have multiple charsets in it, which would make display a mess. A reasonable option is to store the addresses as ACE and to have a log-file viewer that converts on display (and has an option for not converting).

Again, this is an implementation issue, not a protocol issue.

  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.

IMAA describes in detail when and how to display the Unicode form to the user; IMAX mostly glosses over this.

>>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.

And, again, you are mixing up protocols with implementations.

>> 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.

Correct, and IMAA describes when and how to convert for display.

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.

Of course. Nothing in IMAA makes it "impossible to implement an internationalized product".

> 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.

That's not what the IMAX document says. If you want to propose a ESMTP extension with no fallback, either change IMAX or create your own Internet Draft. In either case, you will have to say explicitly how this will interact with SMTP servers that do not support the new protocol, how bounces would be handled, how users would know if they could send a message, and so on. I think when you write that, if you do so honestly, you will see that it would be silly to propose such a solution.

>> > 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 think I hear you saying that you think that the protocols should allow any repertoire and any encoding of those repertoires. If so, we certainly disagree. The IETF is not very keen on creating protocols for which there would be limited and unpredictable interoperability. Other standards group might not be so picky.

--Paul Hoffman, Director
--Internet Mail Consortium