Subject: [EAI] EAI minutes at IETF 77

From: Joseph Yee <[email-masked]>
Date: Mon, 29 Mar 2010 12:16:47 -0400

All,

Below is the minutes from the Anaheim meeting.  Please comment.

Thanks!
Joseph Yee

------------
Meeting

Email Address Internationalization (EAI) WG minutes

Meeting: IETF 77, Monday, March 22, 1740 - 1940
Chair: Xiaodong Lee
Minutes: Joseph Yee

Blue Sheet, Scribe
	- scriber: Joseph Yee

Agenda Bashing
	- none

Doc Status update
	- draft-ietf-eai-pop became RFC 5721 in February 2010
	- draft-ietf-eai-umap-utf8 became RFC 5738 in March 2010
	- draft-ietf-eai-downgrade-display in RFC Ed Queue
	- draft-ieft-eai-mailinglist in AD Evaluation
		- need proto write up by non editor
		- Pete Resnick volunteered to shepherd the document to last call

Downgrade Discussion
	- Downgrade Design Team (DDT) formed, and made recommendation to group
	- results and presentation by Jiankang Yao
	- The principle of DDT results is to rule out the declared address  
pairs and propose the “no fallback” address
	- fall back mechanism, if discussed, will be discussed independently  
from the core standard track documents.
	- discussion on encoding, scenarios on submission end and delivery end

Discussion and Vote of Downgrade Design Team report
	Original
	- That we immediately recharter EAI to focus on the core standards  
track documents, i.e., RFC4952bis, RFC5335bis, RFC5336bis, RFC5337bis,  
RFC5721bis, and the in-progress drafts.
	- RFC5504 should be deprecated. The core documents will not rely on  
fallback or downgrade techniques, particularly by relays.
	- Discoverable fallback addresses may be investigated independently  
of the core documents. Any such work would be part of, or connected  
to, an optional MUA/submission protocol, independent of the core  
transport documents.
	
	Reworded
	- "Does the WG support moving forward on the standards track with the  
core documents (4952bis, 5335bis, 5336bis, 5337bis, 5721bis and the in- 
progress drafts) while dealing with necessary end-point 7-bit header  
interoperability, but omiting support for in-transit downgrading or  
alt-addresses?"
	
	Result
	- most say yes, no visible objections in the room
	
	** Anyone who disagrees should note that on the mailing list and  
explain why ASAP **

New Chairs
	- many thanks to Harald Alvestrand and Xiaodong Lee
	- new chairs: John Klensin, Joseph Yee

Re-charter discussion
	- new SMTP-extension name needed
	- may need new MIME type for 'message/global'
	- Chris Newman recommended a submission protocol extension, can be  
experimental
	- Re-charter wording and deliverables reviewed	
	- New charter draft to be posted for review

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 30 Mar 2010 11:34:51 +0900

Hello Joseph,

Many thanks for the minutes (for taking them, and for sending them out 
so quickly). Just one comment: In the context of the IETF, the term 
'voting' should be avoided. I wasn't in the meeting room, so I don't 
know exactly what happened, but from what I remember from previous IETF 
meetings that I have attended, these things are usually done by humming.

Regards,    Martin.

On 2010/03/30 1:16, Joseph Yee wrote:
> - The principle of DDT results is to rule out the declared address pairs
> and propose the “no fallback” address
> - That we immediately recharter EAI to focus on the core standards track
> documents, i.e., RFC4952bis, RFC5335bis, RFC5336bis, RFC5337bis,
> - Discoverable fallback addresses may be investigated independently of
> the core documents. Any such work would be part of, or connected to, an
> optional MUA/submission protocol, independent of the core transport
> documents.
>
> Reworded
> core documents (4952bis, 5335bis, 5336bis, 5337bis, 5721bis and the
> in-progress drafts) while dealing with necessary end-point 7-bit header
> ** Anyone who disagrees should note that on the mailing list and explain
> why ASAP **
>
>
> New Chairs
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 30 Mar 2010 10:46:54 +0800

----- Original Message ----- 
From: ""Martin J. Dürst"" <[email-masked]>
To: "Joseph Yee" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 30, 2010 10:34 AM
Subject: Re: [EAI] EAI minutes at IETF 77

>so quickly). Just one comment: In the context of the IETF, the term 
'>voting' should be avoided. I wasn't in the meeting room, so I don't 
>meetings that I have attended, these things are usually done by humming.

Normally, we use humming. but this time, we raised hands for it.

what kind of word can be used for raising hand?

---

From: Joseph Yee <[email-masked]>
Date: Mon, 29 Mar 2010 23:05:54 -0400

> what kind of word can be used for raising hand?

Hi Martin,

As mentioned by Yao, we didn't hum but raise hand in meeting, would  
"poll" works?

So that it will read:

"Discussion and Poll of Downgrade Design Team report"

Thanks
Joseph

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 30 Mar 2010 12:08:15 +0900

Hello Jiankang, Joseph,

On 2010/03/30 11:46, YAO Jiankang wrote:
> From: ""Martin J. Dürst""<[email-masked]>
> To: "Joseph Yee"<[email-masked]>
> Cc:<[email-masked]>

What about 'raising hands'?

Regards,   Martin.

---

From: Joseph Yee <[email-masked]>
Date: Mon, 29 Mar 2010 23:29:34 -0400

I will change it to

"Discussion and Raising hands on Downgrade Design Team report"

Thanks
Joseph

---

From: Joseph Yee <[email-masked]>
Date: Tue, 30 Mar 2010 01:48:18 -0400

All,

Revised minutes below.  Thanks.  Joseph

------------
Meeting

Blue Sheet, Scribe
	- scriber: Joseph Yee

Agenda Bashing
	- none

Doc Status update

Downgrade Discussion

Discussion and Raising Hands on Downgrade Design Team report
	Original
	
	Reworded
	
	Result

New Chairs

Re-charter discussion

------

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 30 Mar 2010 16:09:47 +0800

pls give the comments by the end of next week.

after that, I will try to upload the minutes to the IETF website.

----- Original Message ----- 
From: "Joseph Yee" <[email-masked]>
To: <[email-masked]>
Cc: ""Martin J. Dürst"" <[email-masked]>; "YAO Jiankang" <[email-masked]>
Sent: Tuesday, March 30, 2010 1:48 PM
Subject: Re: [EAI] EAI minutes at IETF 77

All,

------------
Meeting

Blue Sheet, Scribe
- scriber: Joseph Yee

Agenda Bashing
- none

Doc Status update

Downgrade Discussion

Reworded

Result

New Chairs

Re-charter discussion

------

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Mar 2010 09:37:50 -0400

> what kind of word can be used for raising hand?

Normally, one says "a show of hands".  The key point, I think, is that
decisions in IETF WGs are not made by majority rules.  They're made by
rough consensus.  The rough consensus is determined by the Chair(s).
In principle, that consensus is supposed to be evaluated on the
mailing list, as well as in WG meetings.

One important factor to note is that "rough consensus" is not normally
determined by stacking up those in favour and those opposed.  If just
one person is opposed, but has strong architectural or other such
technical arguments in his or her favour, then in principle the
Chair(s) could rule that the consensus is too weak & is not therefore
acceptable.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Chris Newman <[email-masked]>
Date: Mon, 29 Mar 2010 21:55:50 -0700

> 	- new SMTP-extension name needed

RFC 5336 Specification changes:
 * new extension name
 * remove ALT-ADDRESS parameter section 3.4, 3.5
   (actually move it to experimental Submission extension)
 * drop maximum line length change
 * Remove section 3.2 option 4
 * drop mention of ALT-ADDRESS section 3.6
 * Change X.6.7 response code -- it now means UTF-8 addresses not permitted
   for that sender/recipient.
 * Change X.6.9 response code -- it now means UTF-8 header message can't be 
transferred
   to one or more recipient so the message must be bounced
 * Mail transmission types -- may or may not choose to rename these.  If we 
do rename
   them, then need to deprecate old values in IANA registry
 * Drop A.5

That's about it.

> 	- may need new MIME type for 'message/global'

Yuck.  Has the experiment revealed any data about use of the "message" top 
level type given that was controversial?  Absent concrete data (e.g. X 
implementation worked, Y did not), we should not revisit previous rough 
consensus to use a "message" top level type.

experimental

The submission-only extension would be layered on top of the new SMTP 
extension and seems like it should be experimental (since it is tricky).  I 
suggest it should:
 * include the ALT-ADDRESS parameter
 * add a DGRADE=<pref> RCPT parameter.  The <pref> can be:
    YES     The server SHOULD attempt a downgrade for this recipient
    NO      The server MUST NOT downgrade for this recipient
    SERVER  The server MAY downgrade for this recipient.  It is a valid 
implementation
            for this to operate the same as either "YES" or "NO".  This is 
the default if
            the parameter is not specified.

Downgrade succeeds if both:
 * The server can find an alt-address for every UTF-8 address in every 
address header in
   the message.  Valid sources include:
    1. The ALT-ADDRESS parameters in the envelope
    2. A to-be-defined vCard mechanism to specify both UTF8 and ALT address 
for a
    recipient, presuming the vCard has been fetched from the personal 
address book owned
    by the user who authenticated to the submission server (perhaps via 
CARDDAV).
 * The server can successfully down-convert to 2047/2231/IDNA2 encoding all 
other headers
In which case all recipients with DGRADE=YES (or DGRADE=SERVER where the 
server decides to downgrade) will receive the downgraded version and the 
downgraded subset of the envelope and other recipients will receive the 
original version and the non-downgraded subset of the envelope.

If downgrade fails and any recipients have DGRADE=YES (or DGRADE=SERVER and 
the server decides YES), then the entire transmission should fail after the 
DATA with appropriate error.

I think that's implementable and useful...

> 	- Re-charter wording and deliverables reviewed	

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.  I suggest utf8@utf8 addr becomes 
2047-encoded-"("utf8@utf8")" followed by ":;".  Another option for ":;" 
would be "unrepresentable-international-recipient@current-server's-domain" 
or "upgrade-your-mail-client-to-reply@current-server's-domain" (local-part 
likely configurable).

This would unfortunately have to be normative to the POP/IMAP specs.  A 
UTF8=ONLY IMAP implementation could get away without this, but POP 
implementations have to do it (either at deliver or access time) to be 
standards compliant.

		- Chris

---

From: Joseph Yee <[email-masked]>
Date: Tue, 30 Mar 2010 15:10:35 -0400

> --On March 29, 2010 12:16:47 -0400 Joseph Yee <[email-masked]>  

[snip]

> Yuck.  Has the experiment revealed any data about use of the  
> "message" top level type given that was controversial?  Absent  
> concrete data (e.g. X implementation worked, Y did not), we should  
> not revisit previous rough consensus to use a "message" top level  
> type.

My personal interpretation is change on 'global' level instead of  
'message' level. Message type defined in RFC 5335 allows pair address  
in headers, and we may need new one for IANA registration.  I agreed  
that we do not need to revisit the "message" level.

Joseph

[snip]

---

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 1 Apr 2010 11:31:07 +0800

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

> RFC 5336 Specification changes:

how about
"Standardized Email Address  Internationalization" ?

---

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 1 Apr 2010 11:49:42 +0800

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

> extension and seems like it should be experimental (since it is tricky).  

what is the aim or reason to have this experimental submission protocol?

after experimental, we move it to standarad track?

> 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.

We revise the downgrade spec for the usage of POP/IMAP case or other cases?

Jiankang Yao

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 01 Apr 2010 06:32:58 +0100

>"Standardized Email Address  Internationalization" ?
I think Chris was talking about the capability string returned in EHLO.

---

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 1 Apr 2010 14:02:50 +0800

----- Original Message ----- 
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
Subject: Re: [EAI] ideas for new work

> 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?

for the name of the SMTP service extension, I suggest "Standardized Email Address  Internationalization" 
for the EHLO keyword value,  we use "UTF8SMTP-std"? or we creat more candidates and poll it?

---------------------------------------------------------------------------------------------------------------
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".

"