Re: Comments on and FWD:

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

> Hi. This is the qmail-send program at lon-mail-1.gradwell.net.
> I'm afraid I wasn't able to deliver your message to the following=20
> addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.
>
> <[email protected]>:
> 208.184.76.43 does not like recipient.
> 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 hav=
e
> 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 bindled 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 mak=
e
> 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 thin=
g=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 tha=
t
> 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 th=
e
> "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 ensur=
e
>>       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 an=
d
>>       moving toward a "next generation" of Internet mail in the hope o=
f
>>       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 fro=
m
> 	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 cas=
e
> 	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' spellin=
g 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 =
be
> easier).
>
> But if B=F8b has I18N-ENVELOPE capabilities locally, then he probably h=
as
> UTF-8-HEADERS capabilities as well, in which case he will surely want t=
o
> 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 ema=
il
> 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 aga=
in
>      with all-ASCII headers)
>
> Note that Address-Map headers would be of no assistance in this scenari=
o.
> Neither would encapsulation (NAIUI), nor would the "friendly gateway"
> suggested in 3.4.3 (though it might be fine in the Alice->B=F8b directi=
on).
>
> No, I think bouncing to B=F8b is the best solution since it is, after a=
ll,
> B=F8b's problem.
>



--=20
Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--=
----------------------
Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0=A0=A0Web=
:=A0http://www.cs.man.ac.uk/~chl
Email:[email protected]=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A=
ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K.
PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0=
A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5