Subject: Re: [EAI] Rechartering for Standards Track

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 14 Jan 2010 10:25:54 +0800

> ----- Original Message ----- 
> From: Shawn Steele 
> To: [email-masked] 
> Sent: Thursday, January 14, 2010 4:46 AM
> Subject: [EAI] Rechartering for Standards Track
> 
> 
> I’d like the WG to recharter for standards track ASAP. 

I hope it too.

I like some ideas in your following proposed recharter draft.
Standardize something that we can standardize or which are clear to us;
Experimental to something that we still need to more experimental tests.

so the suggestions we  have also discussed several times in this wg are reasonable.

------------------------------------------------------------------------------------
 RFCs that have been proven and need moved to standards track:
 
 * Internationalized Email Headers (RFC 5335)
 * Internationalized Delivery Status and Disposition Notifications (RFC 5337)
 * SMTP Extension for Internationalized Email Addresses (RFC 5336)
 * IMAP Support for UTF-8 (draft)
 * POP3 Support for UTF-8 (draft)

RFCs  or drafts need more efforts to have some tests:
 * Downgrading Mechanism for Email Address Internationalization (RFC 5504)
 * Mailing Lists and Internationalized Email Addresses (draft)
 * Displaying Downgraded Messages for Email Address Internationalization (draft)
 An additional document may be required clarifying the expectations
 around multiple Unicode and ASCII addresses for the same mailbox

--------------------------------------------------------------------------------------------
 
>Or charter a second effort for standards track if the WG still feels that experimentation is valuable in some areas.  Lack of a standard is blocking improvements in international email support for our products.
> 
> Several of our (Microsoft) product teams are interested in extending international support for email in markets like China.  Exchange and Live would like to develop to the standards, and it’d really help if we had a clearer standards >track RFC for guidance.  I think that the results of the experimental phase are fairly clear, at least in broad terms, and support the general UTF-8 approach.  Immediately standardizing UTF8SMTP, for example, would go a long >way toward allowing us to enable our products, even if it still took a while to finalized downgrade.
> 
> As a secondary benefit, if teams like Exchange start seriously trying to adopt UTF8SMTP, as a standard, then additional details may be revealed that would help the WG’s continued investigation.
> 
> It’s hard for me to get my company to invest in this area when there aren’t any standards L

Understood.

> 
> - Shawn
> 
> SSDE
> Microsoft
> Windows UX
> 
>  
> http://blogs.msdn.com/shawnste
> 
> To start the discussion, here’s something we could use to update the charter?
> Description of Working Group:
> Since early in the effort to internationalize domain names, which
> resulted in the standards associated with IDNA, it has been
> understood that internationalization of email address local parts is
> required. At the same time, email address internationalization poses
> a series of special problems. Constraints on the interpretation of 
> local-parts by any system other than the final delivery one make 
> address encoding nearly impossible. The need to use addresses in both 
> the email envelope and in header fields, and to do so in ways that are 
> at least compatible, suggests that this is not a simple and isolated 
> problem.
> 
> This working group’s previous experimental efforts investigated the
> use of UTF-8 as a general approach to email internationalization.
> That approach is based on the use of an SMTP extension to enable
> both the use of UTF-8 in envelope address local-parts and optionally
> in domain-parts and the use of UTF-8 in mail headers -- both in
> address contexts and wherever encoded-words are permitted today.
> Other protocols were similarly extended.
> 
> The initial set of experimental RFCs validated the general approach
> while revealing weaknesses in some areas such as downgrade.
> The investigation has reached the point where the usefulness to
> end users is blocked by the lack of adoption of the Experimental
> RFCs by major mail vendors.  Further progress requires formal
> Standardization of the core concepts.
> 
> Several of the WG’s experimental RFCs have been proven
> during the experimental phase and now need moved to standards
> track, which the WG will now do.  Additionally there are some 
> areas may need more effort or investigation.  The WG may 
> create either standards track or additional experimental RFCs
> as required for those areas.
> 
> Standards Track Documents:
> 
> RFCs that have been proven and need moved to standards track:
> 
> * Internationalized Email Headers (RFC 5335)
> * Internationalized Delivery Status and Disposition Notifications (RFC 5337)
> * SMTP Extension for Internationalized Email Addresses (RFC 5336)
> * IMAP Support for UTF-8 (draft)
> * POP3 Support for UTF-8 (draft)

+1

> 
> Downgrading has been tricky, so the updated RFCs should be
> revised to allow for, but not depend upon, a future downgrade
> standard.  Retransmission by legacy protocols should still be permitted.
> 

more work is necessary to downgrade before moving to next step.

> Unchanged Document:
> 
> Overview and Framework for Internationalized Email (RFC4952)
> is informational and the basic concepts still apply.

John may have more comments on this.

> 
> Additional Documents:
> 
> Other documents need further work or different approaches.
> The WG may continue experimental work in these areas, use
> a different experimental approach, or resolve the issues and
> agree to a standard track approach.

> * Downgrading Mechanism for Email Address Internationalization (RFC 5504)
> * Mailing Lists and Internationalized Email Addresses (draft)
> * Displaying Downgraded Messages for Email Address Internationalization (draft)
> An additional document may be required clarifying the expectations
> around multiple Unicode and ASCII addresses for the same mailbox.

more discussion is necessary.

> 
> Deliverables
> 
> The following deliverables are foreseen in this charter. The 
> WG chairs may (re)structure the deliverables into specific 
> documents or document sets as needed. Adding or removing
> documents outside of these deliverables will require a charter
> update.
> 
> 
> * UTF-8 SMTP Support (Standard)
> * UTF-8 POP Support (Standard)
> * UTF-8 IMAP Support (Standard)
> * Header format specification (Standard)

strongly agree.

> * Downgrade (Exp or Info)
> 
> Going forward, it is possible that the downgrading specification
> will go for Informational due to the difficulty of fully specifying
> all necessary behavior.
> 
> Additional possible documents suggested:
> * Advice for MUA implementors (Info)
> * Multiple Unicode and ASCII addresses for the same mailbox (Info or Standard?)
> Goals and Milestones:
> Feb 2010  Recharter for standards track
> Mar 2010  Headers & DSN (Standards)
> Apr 2010SMTP (Standard)
> Apr 2010Coexistence of Unicode & ASCII addresses (Info)
> May 2010  IMAP & POP3 (Standard)
> Jun 2010  Downgrade?
> ??

let's try our best to push it together.

:)

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