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

[Martin Duerst <duerst@xxxxxx>]

At 12:51 03/02/19 +0900, Jeffrey J Zahari wrote:

> ----- Original Message -----
> From: "Martin Duerst" <duerst@xxxxxx>

> > Well, I agree that we should concentrate on addresses here,
> > but looking ahead is part of good engineering. So even if
> > this happens in two steps (UTF8ADDRESS and UTF8HEADER),
> > we can think about the interactions. And if we find
> > out that it would be almost as easy to do both at the same,
> > and maybe just as one extension, then I don't think we
> > should feel restricted to not do it.
> >
> > Actually, my current guess is that it's almost as much
> > effort to do both things in one extension as to do them
> > separately:

> What you're envisioning is something brought up previously, that IMAA should
> update 2821/2822.

Well, as far as I understand, defining an SMTP service extension
does not constitute an update to 2821/2822 itself.


> I assume UTF8ADDRESS refers to 2821 level email addresses and UTF8HEADER
> refers to email addresses within 2822 headers.

Well, overall, there would actually be three things:
- 2821 email addresses
- 2822 email addresses
- 2822 other text (where encoded words are used currently)
[there may also be 2821 other text, but I'm not aware of such]

So overall, we might need three different extensions. But as I said,
I don't think it makes too much sense to allow 2822 email addresses
in UTF-8 but to restrict other text to encoded words (although
I have heard others think about such proposals). Of course, because
our main focus is on email addresses, it also doesn't make much
sense to solve the problem for 2822 other text, but not for 2822
email addresses.

I understand less about the relationship between 2821 and 2822
functionality, but it may also turn out that they are related
enough that it doesn't make sense to define two different extensions.


> What happens if an
> intermediate legacy smtp server cannot handle UTF8ADDRESS, and a receiver's
> MUA cannot handle messages with UTF8HEADER?

In the scenarios we are discussing here, that would be negotiated
as any other SMTP extension. The only problem may be that there is
not really a negotiation between the last MTA and the receiving MUA.


> With the IMAA-ACE approaches ( or until 2821/2 is altered/implemented ),
> unless the MTA requires non opaque lhs, this seems like the most efficient
> path to internationalised emails.

Well, adding another layer of encoding such as proposed in IMAA-ACE
can in some way be quite efficient, but it complicates things
forever if there is no alternative. Also, it's not clear how
quickly we will arrive at a solution.

If I think about IDNS, then my original proposal was published in
December 1996, and it took overall more than six years to come to
the point where actual deployment can now start. So I'm not so
confident that this one will be so very quick.

Regards,    Martin.