Re: Comments on and FWD:

In <[email protected]> Charles Lindsey <[email protected]=
.uk> writes:

>------- Forwarded message -------
>From: [email protected]
>To: [email protected]
>Subject: failure notice
>Date: 12 Feb 2004 16:01:48 -0000

Ooops! I didn't edit enough out of this bounce to leave just a resend of
the failed message. I am sure you managed to fathom out what I said but,
here, for the record is a clean copy of the message:

-------------------------------------------------------------------------=
----

 In <4.2.0.58.J.20040202150018.079b6770@localhost> Martin Duerst=20
 <[email protected]> writes:

> I have read your draft. Congratulations, I think it is
> extremely well written and well argued.

 Yes, I too have read this (though it was a long time before I had an
 opportunity to sit down and study it carefully - hence this delayed
 response). And I agree that it makes a most persuasive case for solving
 several problems, not just the local-part one, by allowing UTF-8 into
 headers. And that is is really the only viable way to proceed. So I have
 just a few niggles and issue to raise below. Of course, there is still
 much detail to be filled in.

> I have the following comments:

> - Name of the extension: Something a little bit more specific
>   than just "I18N" would probably be better.

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


> - Regarding point 3. in 4.1, and point 7.2, I think allowing
>   anything else but UTF-8 should not only be strongly discouraged,
>   it should be forbidden.

 Absolutely so! No doubt about it! The eventual standard will contain
 wording like "the use of UTF-8 is REQUIRED", "it is FORBIDDEN to use=20
 other
 charsets".

 The bad news is that this will not stop people (especially the Chinese,=20
 but
 the French can be a bit awkward too) from doing it. The trick is to make
 sure that the people who insist on violating the standard all do so in a
 consistent manner, and one that can be distinguished from the real thing=
=20
 -
 at the same time without admitting in the standard that such a thing=20
 might
 be possible.

 So the way to do that is to ensure that there is a header somewhere that
 could have contained a "charset=3D..." parameter, and then to point out =
in
 very strong terms that there is NO such parameter in that header, and=20
 that
 it is FORBIDDEN to include one. That should give them the hint to do the
 "right thing".

 Anyway, now to some specific points:

> 2. Three Models for Transition
>
>   1.  Avoid any more infrastructure changes than are absolutely
>       necessary.  ................
>
>   2.  Use a transport-level negotiation model of some variety to ensure
>       that the recipient machine can and will accept the format and
>       structure of the message and options being sent.  ........
>
>   3.  Start a conversation about discarding more or less everything and
>       moving toward a "next generation" of Internet mail in the hope of
>       a huge gain in elegance, capability, or other functions.

 I think there are a couple more strategies to add:

     4.  Do it as an "experimental protocol" (this is not exclusive with
 	the others, of course, and it is not an excuse for not designing
 	it properly). The advantage of this approach is that you can
 	ignore the naysayers and nit-pickers on the grounds that "it is
 	only for those who want to try it out"; it is more easily
 	forgotten if it fails ignominiously; and you can afford not to be
 	backward compatible, especially in areas where you believe that no
 	current software implements (or ever implemented) that obsolete
 	feature, or that 99.999% of existing implementations already allow
 	what you want.

     5.  "Just do it". This, of course, is an extremely bad strategy from
 	an IETF point of view. Indeed, it is not a strategy at all (so let
 	us call it a "pseudo strategy").

         But the point is that this pseudo-strategy is already in
 	widespread use. Indeed, I would think that 50% of innovations were
 	first introduced because "people tried it and it worked", and
 	then it was perhaps standardized later, but reluctantly so because
 	the feature had been poorly designed but was now too entrenched to
 	change.

         But the danger is that this is just what will happen in the case
 	of 8-bit headers of any form UNLESS we step in soon to provide a
 	"respectable" way of doing it. Indeed, it is already happening,
 	and maybe it is already too late.

> 3.4.2 Relay environment
>
>   .....  If internationalized addresses are important to the
>   destination host, its administrators will chose lower-preference MX
>   hosts or other relays that can support internationalized addresses.

 Here you make an argument why the receiving MTA needs, and can be=20
 expected
 to have, I18N capability.

> 3.4.3 Internationalizing the Sender

 But here you seem to say that you do not expect the sending MTA to need
 that capability. I find this odd.

 Now this difference might make good sense if all you have is the
 I18N-ENVELOPE extension, but if you have the UTF-8-HEADERS extension as
 well, then it is not so simple.

 Suppose that Alice communicates with B=F8b (observe the 'funny' spelling=
 of
 B=F8b, and assume that his email address is also 'funny', as in
 [email protected]).

 Since B=F8b advertises an I18N address, we may assume that he has an
 I18N-enabled MUA, and is reached through an I18N-enabled MTA. Even if
 Alice is not so enabled, there may be means she can use to get her mail=20
 to
 him (even telnetting to Port 25 on his MTA if there is nothing better,
 although using some alternative address facility in the protocol might b=
e
 easier).

 But if B=F8b has I18N-ENVELOPE capabilities locally, then he probably ha=
s
 UTF-8-HEADERS capabilities as well, in which case he will surely want to
 use them, and so his emails to Alice will surely contain

     From: B=F8b <[email protected]>

 If Alice has similar capabilities, there is no problem (ignore the=20
 problem
 of intermediate MTAs for now - there are ways around that). She can
 receive his From header (or an equivalent Reply-To) and generate an emai=
l
 to send back to him.

 But if Alice does not have those capabilities, then either

      she will see gobbledegook in that header and be unable to respond,=20
 or

      the message will get bounced back to B=F8b (who might then try agai=
n
      with all-ASCII headers)

 Note that Address-Map headers would be of no assistance in this scenario.
 Neither would encapsulation (NAIUI), nor would the "friendly gateway"
 suggested in 3.4.3 (though it might be fine in the Alice->B=F8b directio=
n).

 No, I think bouncing to B=F8b is the best solution since it is, after al=
l,
 B=F8b's problem.

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