Comments on and FWD:

[Charles Lindsey]

------- Forwarded message -------
From: MAILER-***@lon-mail-1.gradwell.net
To: ***@clerew.man.ac.uk
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
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
208.184.76.43 does not like recipient.

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.

- 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
other
charsets".
The bad news is that this will not stop people (especially the Chinese,
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
-
at the same time without admitting in the standard that such a thing
might
be possible.
So the way to do that is to ensure that there is a header somewhere that
could have contained a "charset=..." parameter, and then to point out in
very strong terms that there is NO such parameter in that header, and
that
it is FORBIDDEN to include one. That should give them the hint to do the
"right thing".

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.

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
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øb (observe the 'funny' spelling of
Bøb, and assume that his email address is also 'funny', as in
Since Bøb 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
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øb has I18N-ENVELOPE capabilities locally, then he probably has
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
If Alice has similar capabilities, there is no problem (ignore the
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 email
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,
or
the message will get bounced back to Bøb (who might then try again
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øb direction).
No, I think bouncing to Bøb is the best solution since it is, after all,
Bøb's problem.

[Charles Lindsey]

Post by Charles Lindsey
------- Forwarded message -------
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:

-----------------------------------------------------------------------------

Post by Charles Lindsey
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.

Post by Charles Lindsey
- 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

Post by Charles Lindsey
- 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
other
charsets".

The bad news is that this will not stop people (especially the Chinese,
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
-
at the same time without admitting in the standard that such a thing
might
be possible.

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

Post by Charles Lindsey
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.

Post by Charles Lindsey
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
expected
to have, I18N capability.

Post by Charles Lindsey
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øb (observe the 'funny' spelling of
Bøb, and assume that his email address is also 'funny', as in
bø***@some.domain).

Since Bøb 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
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øb has I18N-ENVELOPE capabilities locally, then he probably has
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øb <bø***@some.domain>

If Alice has similar capabilities, there is no problem (ignore the
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 email
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,
or

the message will get bounced back to Bøb (who might then try again
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øb direction).

No, I think bouncing to Bøb is the best solution since it is, after all,
Bøb's problem.