Subject: Re: [EAI] ideas for new work

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 01 Apr 2010 11:02:03 +0100

On Thu, 01 Apr 2010 04:49:42 +0100, YAO Jiankang <[email-masked]> wrote:

> ----- Original Message -----
> From: "Chris Newman" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, March 30, 2010 12:55 PM
> Subject: [EAI] ideas for new work

>> We'll need to revise the downgrade spec.  The new one never attempts to
>> preserve UTF-8 addresses in a separate header (except maybe received),
>> doesn't have to deal with <utf8@utf8 <alt@alt>> syntax, and for the
>> POP/IMAP case where the alt-addresses are unavailable, we simply choose
>> some corruption of the address.
>
> based on my understanding to the last ietf conlcusion, we propose no  
> downgrade solution, so the downgrade document will be dropped rather  
> than being revised.

I don't think the downgrade should be dropped. But with the disappearance  
of the alt address sites will have less encouragement to downgrade. But  
the downgrade document should be revised so it can be used by sites which  
so choose (as I believe many will until such time as the whole world is  
using EAI). But it might well remain as Experimental. But our charter  
should allow us to continue to work on it.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 2 Apr 2010 14:04:47 +0800

----- Original Message ----- 
From: "Charles Lindsey" <[email-masked]>
To: "IMA" <[email-masked]>
Sent: Thursday, April 01, 2010 6:02 PM
Subject: Re: [EAI] ideas for new work

>should allow us to continue to work on it.

I think that this version of charter will focus on the standard track documents.

Discoverable fallback addresses may be investigated independently  
of the core documents.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] 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
_______________________________________________
IMA mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ima

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 02 Apr 2010 10:43:18 +0100

> Discoverable fallback addresses may be investigated independently
Indeed, we should be chartered to move the main documents to standards  
track status as out first priority. But we should also be permitted to  
pursue downgrading at some lower priority.

There are two reasons for this.

First, the likelihood of a downgrading method may affect the way the main  
documents are written. For example, the SMPT upgrade document might say:
    "If the destination server does not advertise the UTF8SMTP capability,  
the message SHOULD be rejected (aka bounced up the return path), but it  
MAY alternatively, if the server has a suitable capability, be downgraded  
into some equivalentRFC 5322 message and sent to some equivalent ASCII  
address. This document does not describe any such capability, but there is  
work in progress .....".

Note that if the equivalent address turns out to be undeliverable, it will  
simply bounce in the usual manner, so no harm has been done beyond some  
extra delay.

Second, there may be messages with all-ASCII To:, From:, Reply-To:, etc  
but with UTF-8 in other headers (e.g Subject). For these, transport is not  
a problem, and our existing downgrading would be fine. This might be  
especially useful for mailing lists with both EAI and non-EAI members.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Apr 2010 22:40:41 +0100

YAO Jiankang wrote:

>From: "Alexey Melnikov" <[email-masked]>
>To: "YAO Jiankang" <[email-masked]>
>Cc: "Chris Newman" <[email-masked]>; <[email-masked]>
>Sent: Thursday, April 01, 2010 1:32 PM
>>YAO Jiankang wrote:
>>>>--On March 29, 2010 12:16:47 -0400 Joseph Yee <[email-masked]> wrote:
>>>>        
>>>>
>>>>>Re-charter discussion
>>>>>- new SMTP-extension name needed
>>>>>          
>>>>>
>>>>RFC 5336 Specification changes:
>>>>* new extension name
>>>>        
>>>>
>>>how about
>>>"Standardized Email Address  Internationalization" ?
>>>      
>>>
>>I think Chris was talking about the capability string returned in EHLO.
>>    
>>
>
>I think that you are right.
>
>at first glance, I think it should be the keyword for EHLO.
>
>but after looking at the section 3.1,  RFC 5336,  I think it might refer to the sentence "  1.   The name of the SMTP service extension is "Email Address
>        Internationalization". "
>
>or both  two sentence should be renamed?
>
I think you are right, both names should be changed. In particular the 
name of the SMTP service extension should be changed to avoid confusion 
between the experimental version and the standard track version.

>for the name of the SMTP service extension, I suggest "Standardized Email Address  Internationalization"
>
Right. We can also can rename the old name to be something like "Email 
Address Internationalization (Experimental)".

>for the EHLO keyword value,  we use "UTF8SMTP-std"? or we creat more candidates and poll it?
>
Maybe UTF8MIME (similar to 8BITMIME/BINARYMIME).
But this is not a big deal for me, I can live with whatever people 
prefer. I am hoping we don't have to have a long debate on this ;-).

>---------------------------------------------------------------------------------------------------------------
>in section 3.1,  RFC 5336:
>
>"
>
>3.1.  Framework for the Internationalization Extension
>
>
>   The following service extension is defined:
>
>   1.   The name of the SMTP service extension is "Email Address
>        Internationalization".
>
>   2.   The EHLO keyword value associated with this extension is
>        "UTF8SMTP".
>
>"
>
>
>
>>
>

-- 
IETF Application Area Director, <http://www.ietf.org/IESGmems.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address