Re: Comments on and FWD: draft-klensin-emailaddr-i18n-02.txt

In <[email protected]> John C Klensin <[email protected]>=
 writes:

>--On Thursday, 12 February, 2004 21:34 +0000 Charles Lindsey=20
><[email protected]> wrote:

>>> Indeed. There are two extensions under discussion (though
>>> they might eventually be bindled together). So let us call
>>> them I18N-ENVELOPES
>>>     UTF-8-HEADERS

>Actually, there are a bunch of such extensions.  Another one is=20
>"get the trace fields out of the message headers, so we don't=20
>have the potential of different (relay and other) MTAs inserting=20
>things with different codings in the headers".

Sure. But first we decide what extensions we want, and give them names.
And then we bundle them into a package of just a few (hopefully one) name=
d
EHLO responses.

I am not so sure about the trace fields, though. The final recipient need=
s
to be able to look at the complete headers as received and deduce the
precise history of where that email has been and who has munged what en
route. Also, the average recipient is unaware of matters relating to the
envelope (heck, most of them can barely find the full headers given the
difficulty of finding them in OE :-( ). But care will be needed in the
final version to ensure that the trace headers/whatever survive the
encapsulation/decapsulation processes.

> And another one=20
>is the existing 8BITMIME.

That will probably be obligatory if you provide the new I18N stuff.


>I have my doubts that this is either necessary, or sufficient if=20
>it is necessary.  And I think it would be more realistic to=20
>write a gateway spec that says, more or less, "if you are going=20
>to inject your stuff into the public Internet, it needs to look=20
>like this; otherwise, it will probably be trashed beyond=20
>recognition" (there are, of course, some statements equivalent=20
>to that in 2821).

To which the Chinese will respond that "it won't get trashed so long as i=
t
remains in China, which will be true 99.99999999% of the time. Never
underestimate the obstinacy of the Chinese.

Which raises another point. Non-Native-English speaking users are
conspicuously absent from this list, which is supposed to be designing
I18N features for their benefit.


>>>> 3.4.2 Relay environment
>>>>
>>> No, I think bouncing to B=F8b is the best solution since it is,
>>> after all, B=F8b's problem.

>I think this analysis is precisely correct, and hope that others=20
>will study and understand it.  The text which you cite was not=20
>rethought and rewritten between -01 and -02 and obviously should=20
>have been. Encapsulation might help if Alice's MUA can do it=20
>locally for outgoing messages, but, since implementing UTF-8=20
>headers is probably less trouble, I wouldn't expect to see a lot=20
>of that option.

When preparing my previous response, I also sketched out a model which co=
uld
encompass all solutions of the type we are discussing. Maybe I should tid=
y
it up and publish it to this list.

>	* Those who believe that some judicious message-bouncing
>	in situations like this will cause software to be
>	upgraded and/or users to make other arrangements (of
>	software, providers, or the addresses they are using) in
>	fairly short order.

I think it is inevitable that those who particularly want to benefit from
the introduction of I18N to whqt has hitherto been a largely ASCII world
will have to bear some of the pain of implementing it. Having a few
messages bounce is less painful than having messages fail to be delivered=
,
or be delivered in an undecipherable form.

--=20
Charles H. Lindsey ---------At Home, doing my own thing------------------=
------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.u=
k/~chl
Email: [email protected]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU=
, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4=
 AB A5