Subject: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC

From: The IESG <[email-masked]>
Date: Fri, 12 Jan 2007 10:30:08 -0500

The IESG has received a request from the Email Address 
Internationalization WG (eai) to consider the following document:

- 'Overview and Framework for Internationalized Email '
   <draft-ietf-eai-framework-04.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-01-26. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14701&rfc_flag=0

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: Randall Gellens <[email-masked]>
Date: Tue, 16 Jan 2007 18:44:56 -0800

(1) This version still has some editor's notes.  Are these intended 
for publication?

(2) In section 1.3:
    An "i18mail user" has one or more non-ASCII email addresses.  Such a
    user may have ASCII addresses too; if the user has more than one
    email account and corresponding address, or more than one alias for
    the same address, he or she has some method to choose which address
    to use on outgoing email.  Note that under this definition, it is not
    possible to tell from the address that an email sender or recipient
    is an i18mail user.  There is no such thing as an "i18mail message";
    the term applies only to users and their agents and capabilities.

Does the second-to-last sentence refer to an ASCII address, or any 
address?  The wording implies any address, but if an address is 
non-ASCII, surely that is a good sign that the owner of that address 
is an i18mail user?

(3) In section 4.3:
     the risk should be
    minimized by the fact that the selection of submission servers are
    presumably under the control of the sender's client and the selection
    of potential intermediate relays is under the control of the
    administration of the final delivery server.

    [snip]

    For situations in which a client encounters a server that does not
    support UTF8SMTP, there are basically two possibilities:

    o  Reject the message or generate and send a non-delivery message,

    [snip]

    o  Figure out a way to downgrade the envelope or message body in

I apologize if this has already been discussed, but in light of the 
first quoted sentence, the two possible actions can be augmented by 
another approach: try an alternate MX host and/or requeue the message 
and try later.  That is, because the mail path is normally under 
administrative control of the end points or their organizations, it 
may be reasonable to conclude that UTF8SMTP is normally supported 
along this path, and if a system is encountered which doesn't support 
it, this may be a temporary failure.  Obviously, if this is tried but 
persistently fails, one of the other two methods must be used.

(This could also be mentioned in the smtpext document.)

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Truth resides in every human heart, and one has to search for it
there, and to be guided by truth as one sees it.  But no one has
a right to coerce others to act according to his own view of the
truth.                                                  --Gandhi

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Jan 2007 09:45:12 -0500

--On Tuesday, 16 January, 2007 18:44 -0800 Randall Gellens
<[email-masked]> wrote:

> (1) This version still has some editor's notes.  Are these
> intended for publication?

No.  I had intended to change the xml2rfc parameters to shut
them off when I submitted the draft and forgot.  My apologies.
If they are significantly confusing to anyone, let me know and
I'll post a new version of the draft.

     john

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 Jan 2007 09:42:02 -0800

>  I'll post a new version of the draft.

I don't think they're confusing, but some of them suggest unresolved issues.

-------------- Randomly-selected tag: ---------------
The curse of all Art is that the devotee or disciple is always more
certain than the Priest.                          --Rudyard Kipling

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Jan 2007 20:44:27 +0100

> (1) This version still has some editor's notes.  Are these intended 
No. The writeup didn't get copied into the Last Call, but as WG chair, I 
believe that the document is complete if all the editor's notes are 
deleted. Some of them point to areas that might be improved, but, in my 
opinion, such improvements are not a requirement for publication.
> non-ASCII, surely that is a good sign that the owner of that address 
Right. The situation that is being warned against is taking an ASCII 
address as a clear sign that the address owner is not an i18mail user.
> (This could also be mentioned in the smtpext document.)
I haven't seen that possibility raised. I'm somewhat skeptical that it 
would be an improvement (it makes the delay before error reporting 
variable), but it's worth a discussion. WG?

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 Jan 2007 12:12:05 -0800

At 8:44 PM +0100 1/17/07, Harald Alvestrand wrote:

>> non-ASCII, surely that is a good sign that the owner of that 
>> address is an i18mail user?
>  Right. The situation that is being warned against is taking an 
> ASCII address as a clear sign that the address owner is not an 
> i18mail user.

I'd like to see the text improved to make this more clear.  As a 
suggestion, replace:

      Note that under this definition, it is not possible to tell from
      the address that an email sender or recipient is an i18mail user.

with:

       Note that under this definition, it is not possible to tell from
       an ASCII address if an email sender or recipient is an i18mail
       user or not.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
We have met the enemy, and he is us.
                       --Walt Kelly

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 Jan 2007 12:25:29 -0800

At 8:44 PM +0100 1/17/07, Harald Alvestrand wrote:

>>  I apologize if this has already been discussed, but in light of 
>> the first quoted sentence, the two possible actions can be 
>> augmented by another approach: try an alternate MX host and/or 
>> requeue the message and try later.  That is, because the mail path 
>> is normally under administrative control of the end points or 
>> their organizations, it may be reasonable to conclude that 
>> UTF8SMTP is normally supported along this path, and if a system is 
>> encountered which doesn't support it, this may be a temporary 
>> failure.  Obviously, if this is tried but persistently fails, one 
>> of the other two methods must be used.
>>
>  I haven't seen that possibility raised. I'm somewhat skeptical that 
> it would be an improvement (it makes the delay before error 
> reporting variable), but it's worth a discussion. WG?

If it is a temporary failure, and the message is sent successfully 
after retrying, then it was a good thing to do.  If there is always 
an ASCII-only SMTP server in the path, then retrying only adds delay 
to the failure.  So: is it advisable for a system to be optimistic 
that the message will be able to be sent?  I think so, as the 
document says:

    the fact that the selection of submission servers are
    presumably under the control of the sender's client and the selection
    of potential intermediate relays is under the control of the
    administration of the final delivery server.

This makes the most sense when sending non-ASCII to non-ASCII, I 
think.  It also makes sense when sending ASCII to non-ASCII and the 
sender's submission server is UT8SMTP compliant.  I'd probably not do 
it when sending non-ASCII to ASCII.

In any event, I think this is a quality-of-implementation thing: it 
should be suggested by the documents but certainly not required for 
compliance.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Arguments are to be avoided; they are always vulgar and often convincing.                                     --Oscar Wilde

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Jan 2007 15:59:41 -0500

--On Wednesday, 17 January, 2007 12:12 -0800 Randall Gellens
<[email-masked]> wrote:

>>>  Does the second-to-last sentence refer to an ASCII address,
>>>  or any  address?  The wording implies any address, but if
>>> an address is  non-ASCII, surely that is a good sign that
>>> the owner of that  address is an i18mail user?
>>  Right. The situation that is being warned against is taking
>>  an  ASCII address as a clear sign that the address owner is
>> not an  i18mail user.
> 
> I'd like to see the text improved to make this more clear.  As
> a suggestion, replace:
> 

Hmm.   One still  can't tell from a non-ASCII address that the
recipient is an i18mail user or not, one can only tell that the
sender thinks that user is.

I'm happy to make the change Randy suggests unless others object
(I think it improves things).  But, if we are going to do so,
let's figure out text to be sure things are completely right.
In that context, it seems to me as if the suggested replacement
sentence needs an additional few words.  Suggestions welcome.

   john (editor)

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Jan 2007 16:02:24 -0500

--On Wednesday, 17 January, 2007 12:25 -0800 Randall Gellens
<[email-masked]> wrote:

>....
>>  I haven't seen that possibility raised. I'm somewhat
>>  skeptical that  it would be an improvement (it makes the
>> delay before error  reporting variable), but it's worth a
>> discussion. WG?
> 
> If it is a temporary failure, and the message is sent
> successfully after retrying, then it was a good thing to do.
> If there is always an ASCII-only SMTP server in the path, then
> retrying only adds delay to the failure.  So: is it advisable
> for a system to be optimistic that the message will be able to
> be sent?  I think so, as the document says:
> 
> This makes the most sense when sending non-ASCII to non-ASCII,
> I think.  It also makes sense when sending ASCII to non-ASCII
> and the sender's submission server is UT8SMTP compliant.  I'd
> probably not do it when sending non-ASCII to ASCII.
> 
> In any event, I think this is a quality-of-implementation
> thing: it should be suggested by the documents but certainly
> not required for compliance.

Speaking for myself only, I'd prefer to see this mentioned in
the downgrade document, and maybe in the SMTPext one, but not in
Framework.  In any event, I'd recommend/request that you specify
text and where it should go.

    john

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 Jan 2007 14:31:31 -0800

>  sentence needs an additional few words.  Suggestions welcome.

How about:

Replace:

with:

       Note that under this definition, it is not possible to tell from
       an ASCII address if an email sender or recipient is an i18mail
       user or not.  (A non-ASCII address implies that the owner of
       that address is an i18mail user.)
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There is no human problem which could not be solved if people would
simply do as I advise.                                -- Gore Vidal

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Jan 2007 17:40:12 -0500

>        that address is an i18mail user.)

Hmm.   Because of my concern that some of the non-ASCII
addresses we will see floating around will result from guessing,
how about

   ... (A non-ASCII address implies a belief that the...

if you can live with that, and no one else objects strenuously,
I'll make the substitution.

    john

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 Jan 2007 14:46:10 -0800

>  I'll make the substitution.

Sounds good to me.
-------------- Randomly-selected tag: ---------------
Newton's Fourth Law:  Every action has an equal and
opposite satisfaction.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 Jan 2007 14:44:39 -0800

At 4:02 PM -0500 1/17/07, John C Klensin wrote:

>  In any event, I'd recommend/request that you specify

I'm thinking a brief mention in the Framework document, with more 
discussion in the SMTP extension document, and maybe a mention in the 
downgrade document.  I'll suggest text for those documents later, but 
for the Frameworks document, immediately following the two bullets in 
Section 4.3, add a new paragraph:

-----------------------
(The client can also try an alternate next-hop host or requeue the 
message and try later, on the assumption that the lack of UTF8SMTP is 
a transient failure; since this ultimately resolves to success or 
failure, it doesn't change the discussion here.)
-----------------------

-------------- Randomly-selected tag: ---------------
Seduced, shaggy Samson snored.
She scissored short.  Sorely shorn,
Soon shackled slave, Samson sighed,
Silently scheming,
Sightlessly seeking
Some savage, spectacular suicide.
                 --Stanislaw Lem

---

From: Yangwoo Ko <[email-masked]>
Date: Thu, 18 Jan 2007 09:53:57 +0900

>       that address is an i18mail user.)

Replaced text looks a lot better, I am a little bit concerned that the 
relation between "an ASCII address" and "an sender / recipient" is 
looser than I want it be. /* As a non-native, I feel always nervous when 
word-smithing */

Can we me make the relation clearer if we changed it a little bit? For 
instance;

Note that under this definition, it is not possible to tell
whether an email sender or recipient is an i18mail user or not
if his/her address is an ASCII address.

Regards

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 Jan 2007 17:23:56 -0800

At 9:53 AM +0900 1/18/07, Yangwoo Ko wrote:

>  Replaced text looks a lot better, I am a little bit concerned that 
> the relation between "an ASCII address" and "an sender / recipient" 
> is looser than I want it be. /* As a non-native, I feel always 
> nervous when word-smithing */
>
>  Can we me make the relation clearer if we changed it a little bit? 
> For instance;
>

How about:

       Note that under this definition, it is not possible to tell
       from an ASCII address if the owner of that address is an
       i18mail user or not.  (A non-ASCII address implies a belief
       that the owner of that address is an i18mail user.)

This incorporates John's change ("a belief") as well as your desire 
to tighten the link between the address and the owner.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There is so much to be said in favor of modern journalism.
By giving us the opinions of the uneducated, it keeps us in touch
with the ignorance of the community.                --Oscar Wilde

---

From: "Yao Jiankang" <[email-masked]>
Date: Thu, 18 Jan 2007 09:45:58 +0800

----- Original Message ----- 
From: "Randall Gellens" <[email-masked]>
To: "John C Klensin" <[email-masked]>; "Harald Alvestrand" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, January 18, 2007 6:44 AM
Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC

> Section 4.3, add a new paragraph:

If no one else objects it,  I will update it in SMTPext document according to your suggestions.

Thanks.

YAO Jiankang
CNNIC

> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 19 Jan 2007 02:34:37 +0100

Randall Gellens wrote:

  [TempError]

>     administration of the final delivery server.

I'd think that a mixed setup  - some routes work with UTF8SMTP as is,
others don't - is a bug that has to be fixed manually.  And "manual
intervention needed" is more like PermError than TempError.  
 
> should be suggested by the documents but certainly not required for

Yes.  Normally I'd prefer a consistent behaviour, but in that case
it's impossible, getting the "wrong" route is an intermittent issue,
some non-UTF8SMTP secondary MX or similar.

Frank

---

From: Randall Gellens <[email-masked]>
Date: Thu, 25 Jan 2007 20:33:58 -0800

Section 2.2 of the smtpext draft says:

    If
    the UTF8SMTP SMTP extension is not offered by the Server, the SMTP
    Client MUST NOT transmit an internationalized address and MUST NOT
    transmit a mail body which contains internationalized mail headers
    [EAI-utf8header].  Instead, it MUST either return the message to the
    user as undeliverable or replace it with the alternate ASCII address.
    If it is replaced, the replacement MUST be the ASCII-only address
    specified with the ALT-ADDRESS parameter.[EAI-downgrading].

I think there should be a mention of requeuing here.  I'd like to add 
new text following paragraph above:

--------------------------------
When an MSA or MTA encounters a server that doesn't support UTF8SMTP 
while relaying a message that requires such support (because either 
the forward or reverse paths lack an ALT-ADDRESS), it is RECOMMENDED 
that an alternate MX be tried, and/or the message is requeued for a 
later attempt, rather than immediately downgrading or bouncing.  If 
the message is requeued, the total elapsed time before bouncing or 
downgrading SHOULD be smaller than the value used for other SMTP 
error conditions such as host unreachable or persistent 4xx response 
codes.

This alternate-MX-or-retry-later technique SHOULD NOT be used when 
the message's return path is a non-ASCII address and the specific 
forward path being attempted is an ASCII address.  The technique also 
SHOULD NOT be used when both the forward and reverse paths contain an 
ALT-ADDRESS.

The selection of submission servers is presumably under the control 
of the sender's client, while the selection of potential intermediate 
relays is under the control of the administration of the final 
delivery server.  Hence, there is a presumption, at least when the 
recipient address is non-ASCII, that the delivery path servers 
normally support UTF8SMTP (if the sender's client or MSA didn't 
support UTF8SMTP, the message would not have been accepted for 
delivery in the first place).  Thus, a lack of UTF8SMTP support is 
likely to be a temporary situation, such as a normal inbound server 
being down and a cooperating site acting as a backup MX.
--------------------------------

(Sorry for the run-on sentence in the first new paragraph.  This can 
be cleaned up later.)

If the lack of UTF8SMTP in the delivery path of a message is a 
temporary situation, and the message is sent successfully after 
retrying, then it was a good thing to do.  Of course, if there is 
always an ASCII-only SMTP server in the path, then retrying only adds 
delay to the failure (bounce or downgrade).

As I understand the assumptions and goals of this group, we're trying 
to avoid making downgrading a normal action, and planning for an 
environment where UTF8SMTP has wide deployment.

-------------- Randomly-selected tag: ---------------
It is much easier to suggest solutions
when you know nothing about the problem.