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

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

> At 7:53 PM +0100 2/24/03, Simon Josefsson wrote:
>>  > What is the actual deployment advantage of a ESMTP extension over just
>>>  plain IMAA-ACE?
>>
>>It makes SMTP support non-ASCII for email addresses.  Compared to
>>using IMAA-ACE, the advantage is that an ESMTP extension doesn't
>>require the use of a punycode encoder/decoder.
>
> Are you saying that using a punycode decoder when writing to a message
> store is *harder* than doing an ESMTP extension that might involve
> bouncing or dropping mail? That seems kind of extreme, given that the
> punycode decoding is completely optional. And I don't understand why
> you talk about a punycode encoder; that is never needed by the SMTP
> server in IMAA-ACE.

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.

How would an ESMTP extension with an ACE fallback (i.e., IMAX) involve
bouncing or dropping mail?

Punycode decoding is not optional if the MTA wants to support
non-ASCII.  If the MTA doesn't want to support non-ASCII (for logging,
for aliases, for routing, etc), none of this is relevant anyway and
the MTA can continue to live in the old 7bit world and noone would
notice or care.

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.  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.  In theory, I agree that a
(probably) compliant MTA could be developed that didn't include a
punycode encoder, but it would be limited.

>>   What would the actual
>>deployment advantage of using IMAA-ACE over an ESMTP extension with an
>>ACE fallback be?
>
> That there would be no required change to the deployed base of SMTP
> servers out there, some of which are in hardware and cannot be
> upgraded. Internet mail is already deployed; forcing a change when it
> isn't needed is just plain bad design. Localizing the protocol change
> to one place makes it easier to deploy and makes it more predicable
> for end users.
>
> Do I need to go on?

Yes, please.  Why would an ESMTP extension with an ACE fallback (e.g.,
IMAX) require any changes to the deployed base of SMTP servers?

>>If you want to deploy as fast as possible and only require changes in
>>transport end points, yes.  If you want to upgrade to a clean and
>>easily maintined design in the long-term, no.
>
> 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.

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