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

----- Original Message -----
From: "Martin Duerst" <[email protected]>
To: "Roy Badami" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Monday, February 17, 2003 12:33 AM
Subject: Re: Can we back up a bit and ask some basicquestions?Analternate
model


>
> At 13:48 03/02/16 +0000, Roy Badami wrote:
>
> >Sorry, there was a typo in my comment above.  I meant to say:
> >
> >    we will move to a _message_ which (by default) is just a block of
UTF-8
> >Having thought about it further, the kind of solution I was
> >envisioning would have to wait for a new message format to be defined,
> >in which the headers were 8-bit.  Making this change just for
> >addresses doesn't make sense, and defining the native UTF-8 message
> >format is clearly outside the scope of the present discussions.
>
> 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.

I assume UTF8ADDRESS refers to 2821 level email addresses and UTF8HEADER
refers to email addresses within 2822 headers. What happens if an
intermediate legacy smtp server cannot handle UTF8ADDRESS, and a receiver's
MUA cannot handle messages with UTF8HEADER?

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.

jeffrey j zahari