Subject: Re: [EAI] AD review of draft-ietf-eai-rfc5336bis-04.txt

From: Shawn Steele <[email-masked]>
Date: Tue, 30 Nov 2010 01:24:58 +0000

My comments may be late:

> 2.  Overview of Operation

>   token "UTF8SMTPbis".  In order to provide information that may be
>   needed in downgrading, an optional alternate ASCII address may be
>   needed if an SMTP client attempts to transfer an internationalized
>   message and encounters a server that does not support this extension.

> I think the last sentence no longer applies and need to be deleted.

Seems fine to me, but I wonder if the idea is now to allow resending with a different ASCII address using normal SMTP?  Probably not worth mentioning there.

>   A UTF8SMTPbis aware MUA/MSA sending to a legacy SMTP server [RFC5321]
>   and [RFC5322] MAY convert the ASCII@non-ASCII
> Native speakers: should the "the" be replaced with "a" here?

Addresse should be address, and "an" would work a bit better maybe than "the".

>  Otherwise, surprising downgrades can happen
>   during temporary failures, which users might perceive as a serious
>   reliability issue.

> The last sentence: I think this needs to be reworded or deleted,
> as "surprising downgrades" are no longer an issue.

I'd be happy with "unexpected failures or disparities".  The core idea that mismatched servers causing confusing behavior is probably worth pointing out.

- Shawn

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Nov 2010 23:14:35 -0500

--On Tuesday, November 30, 2010 01:24 +0000 Shawn Steele
<[email-masked]> wrote:

> My comments may be late:
> 
>> 2.  Overview of Operation
> 
>>   token "UTF8SMTPbis".  In order to provide information that
>>   may be needed in downgrading, an optional alternate ASCII
>>   address may be needed if an SMTP client attempts to
>>   transfer an internationalized message and encounters a
>>   server that does not support this extension.
> 
> Seems fine to me, but I wonder if the idea is now to allow
> resending with a different ASCII address using normal SMTP?
> Probably not worth mentioning there.

Likely worth mentioning in one of the "advice" documents.
Doesn't belong here, IMO, unless we intend to require it.

>...
>>   during temporary failures, which users might perceive as a
>>   serious reliability issue.
> 
>> The last sentence: I think this needs to be reworded or
>> deleted, as "surprising downgrades" are no longer an issue.
> 
> I'd be happy with "unexpected failures or disparities".  The
> core idea that mismatched servers causing confusing behavior
> is probably worth pointing out.

See my earlier comments.   "Unexpected rejections" is closest in
tone to the original, although certainly not the only possible
text.  The real question is how far one wants to go in
explaining the nature of the problem rather than just advising
against getting into the situation where different servers have
different capabilities.  Should you decide that more explanation
is in order, I won't object as long as the explanation is
completely clear, but that is a personal opinion and others in
the WG may disagree.

I would, however, like to see an updated version that reflects
these comments well before the end of this week.

    john

---

From: Shawn Steele <[email-masked]>
Date: Tue, 30 Nov 2010 07:03:21 +0000

> Doesn't belong here, IMO, unless we intend to require it.

Fine by me :)

> text... I won't object as long as the explanation is

Unexpected rejections is fine to me.  I was thinking end-to-end where a user might send to an EAI address, it works, then send to EAI & it fails, then resend to ASCII.  Or the sender may fail to send and their client falls back to the sender's ASCII address.  It seems like there are a lot of possible ways that mismatched capabilities could differ, so I favor vague "this is bad" over "this is bad because of A, B, C, C1,... Z :)"

- Shawn

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Nov 2010 04:46:25 -0500

--On Tuesday, November 30, 2010 07:03 +0000 Shawn Steele
<[email-masked]> wrote:

>...
>> See my earlier comments.   "Unexpected rejections" is closest
>> in tone to the original, although certainly not the only
>> possible text... I won't object as long as the explanation is
> Unexpected rejections is fine to me.  I was thinking
> end-to-end where a user might send to an EAI address, it
> works, then send to EAI & it fails, then resend to ASCII.  Or
> the sender may fail to send and their client falls back to the
> sender's ASCII address.  It seems like there are a lot of
> possible ways that mismatched capabilities could differ, so I
> favor vague "this is bad" over "this is bad because of A, B,
> C, C1,... Z :)"

Our reasoning about that is very similar, actually.  Hence my
inclination to say "unexpected rejections" rather than something
about downgrade behavior and then move on.

   john

---

From: Shawn Steele <[email-masked]>
Date: Tue, 30 Nov 2010 15:56:42 +0000

I'd thought my previous suggestion avoided the word "downgrade" :)

-Shawn

 
http://blogs.msdn.com/shawnste

________________________________________
From: John C Klensin [[email-masked]]
Sent: Tuesday, November 30, 2010 1:46 AM
To: Shawn Steele; [email-masked]; Alexey Melnikov ([email-masked])
Cc: YAO Jiankang
Subject: RE: [EAI] AD review of draft-ietf-eai-rfc5336bis-04.txt

   john

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Nov 2010 16:07:19 -0500

> I'd thought my previous suggestion avoided the word

It did.  Mostly just a matter of taste.  At this point, I'm
looking forward to seeing a pair of new drafts.  If those are
not going to be up in the next 24 hours or less, I'd appreciate
updated statements from the various authors about when we can
expect them.

   john