internationalization of email addresses
submitted by Stephane Bortzmeyer to the Governance List: Since we often talk about internationalization... Three new RFCs have been published on friday. They (almost) finalize the standards for the internationalization of email addresses (email content in Unicode is standard since 1992). Soon :-) I'll be able to use stéphane@bortzmeyer.fr with the accent. Congratulations for the EAI Working Group. Now, we can say that almost all the IETF standards are Unicode-able. (The main missing one is FTP, which has an option TEXT which is only for ASCII. An Unicode version is under work.) RFC 5335 Title: Internationalized Email Headers Author: Y. Abel, Ed. Status: Experimental Date: September 2008 Mailbox: abelyang@twnic.net.tw Pages: 14 Characters: 27945 Updates: RFC2045, RFC2822 I-D Tag: draft-ietf-eai-utf8headers-12.txt URL: http://www.rfc-editor.org/rfc/rfc5335.txt Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Email Address Internationalization Working Group of the IETF. RFC 5336 Title: SMTP Extension for Internationalized Email Addresses Author: J. Yao, Ed., W. Mao, Ed. Status: Experimental Date: September 2008 Mailbox: yaojk@cnnic.cn, maowei_ietf@cnnic.cn Pages: 22 Characters: 48110 Updates: RFC2821, RFC2822, RFC4952 I-D Tag: draft-ietf-eai-smtpext-13.txt URL: http://www.rfc-editor.org/rfc/rfc5336.txt This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952This memo defines an Experimental Protocol for the Internet community. This document is a product of the Email Address Internationalization Working Group of the IETF. RFC 5337 Title: Internationalized Delivery Status and Disposition Notifications Author: C. Newman, A. Melnikov, Ed. Status: Experimental Date: September 2008 Mailbox: chris.newman@sun.com, Alexey.Melnikov@isode.com Pages: 18 Characters: 36324 Updates: RFC3461, RFC3464, RFC3798 I-D Tag: draft-ietf-eai-dsn-06.txt URL: http://www.rfc-editor.org/rfc/rfc5337.txt Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Email Address Internationalization Working Group of the IETF.
It is worth noting that these are *experimental*, not standards track RFCs. The proposed design is a bit of an experiment, and adds some significant complexity to the e-mail infrastructure. It remains to be seen how successful these specifications will be. -- Thomas Roessler <roessler@does-not-exist.org> On 2008-09-08 04:39:45 -0700, Danny Younger wrote:
From: Danny Younger <dannyyounger@yahoo.com> To: at-large@atlarge-lists.icann.org Date: Mon, 8 Sep 2008 04:39:45 -0700 (PDT) Subject: [At-Large] internationalization of email addresses Reply-To: At-Large Worldwide <at-large@atlarge-lists.icann.org> List-Id: At-Large Worldwide <at-large_atlarge-lists.icann.org.atlarge-lists.icann.org> X-Spam-Level: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
submitted by Stephane Bortzmeyer to the Governance List:
Since we often talk about internationalization...
Three new RFCs have been published on friday. They (almost) finalize the standards for the internationalization of email addresses (email content in Unicode is standard since 1992). Soon :-) I'll be able to use stéphane@bortzmeyer.fr with the accent. Congratulations for the EAI Working Group.
Now, we can say that almost all the IETF standards are Unicode-able.
(The main missing one is FTP, which has an option TEXT which is only for ASCII. An Unicode version is under work.)
RFC 5335
Title: Internationalized Email Headers Author: Y. Abel, Ed. Status: Experimental Date: September 2008 Mailbox: abelyang@twnic.net.tw Pages: 14 Characters: 27945 Updates: RFC2045, RFC2822
I-D Tag: draft-ietf-eai-utf8headers-12.txt
URL: http://www.rfc-editor.org/rfc/rfc5335.txt
Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements. This memo defines an Experimental Protocol for the Internet community.
This document is a product of the Email Address Internationalization Working Group of the IETF.
RFC 5336
Title: SMTP Extension for Internationalized Email Addresses Author: J. Yao, Ed., W. Mao, Ed. Status: Experimental Date: September 2008 Mailbox: yaojk@cnnic.cn, maowei_ietf@cnnic.cn Pages: 22 Characters: 48110 Updates: RFC2821, RFC2822, RFC4952
I-D Tag: draft-ietf-eai-smtpext-13.txt
URL: http://www.rfc-editor.org/rfc/rfc5336.txt
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952This memo defines an Experimental Protocol for the Internet community.
This document is a product of the Email Address Internationalization Working Group of the IETF.
RFC 5337
Title: Internationalized Delivery Status and Disposition Notifications Author: C. Newman, A. Melnikov, Ed. Status: Experimental Date: September 2008 Mailbox: chris.newman@sun.com, Alexey.Melnikov@isode.com Pages: 18 Characters: 36324 Updates: RFC3461, RFC3464, RFC3798
I-D Tag: draft-ietf-eai-dsn-06.txt
URL: http://www.rfc-editor.org/rfc/rfc5337.txt
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.
This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. This memo defines an Experimental Protocol for the Internet community.
This document is a product of the Email Address Internationalization Working Group of the IETF.
_______________________________________________ At-Large mailing list At-Large@atlarge-lists.icann.org http://atlarge-lists.icann.org/mailman/listinfo/at-large_atlarge-lists.icann...
At-Large Official Site: http://atlarge.icann.org
Danny Younger <dannyyounger@yahoo.com> writes:
Now, we can say that almost all the IETF standards are Unicode-able.
This is a _very_ optimistic thing to say, as it suggests that "we are almost done". Bottom line: Internationalization of application protocols is a case-by-case issue. Each applications needs to do a self-evaluation to see whether it can handle internationalized characters. It's not just a a simple "they can use UTF-8". There are plenty of application protocols that forbid non-ascii to be used (or where the deployed base chokes if non-ascii appears). So it takes real work and thinking to transition to a system where those protocols are fully internationalized. Email is just a rather prominent example. See the thread with a subject of "IETF.org does its part on internationalization" at http://www.ietf.org/mail-archive/web/ietf/current/thrd2.html for a timely message that adds detail to this. Thomas
At 14:27 10/09/2008, Thomas Narten wrote:
Danny Younger <dannyyounger@yahoo.com> writes:
Now, we can say that almost all the IETF standards are Unicode-able.
This is a _very_ optimistic thing to say, as it suggests that "we are almost done". Bottom line: Internationalization of application protocols is a case-by-case issue. Each applications needs to do a self-evaluation to see whether it can handle internationalized characters. It's not just a a simple "they can use UTF-8". There are plenty of application protocols that forbid non-ascii to be used (or where the deployed base chokes if non-ascii appears). So it takes real work and thinking to transition to a system where those protocols are fully internationalized. Email is just a rather prominent example.
See the thread with a subject of "IETF.org does its part on internationalization" at http://www.ietf.org/mail-archive/web/ietf/current/thrd2.html for a timely message that adds detail to this.
Also, add to what Thomas says that Internationalisation (the equivalent of everyone using International English and quoting large chunks in his/her own language) is not the multilingualisation that people expect (that every language and scri^pt is supported the same way as ASCII English is). There is a very limited practical difference between Internationalization and Multilingualisation for en English thinker, what does not make them easy to understand, analyse, systemize, and document Multilingualisation. This is one of the reason of my yesterday appeal on the matter to the IESG (http://ml-dns.org/ml-dns-appeal.pdf). We need to find a good solution to enhance IETF to the systemic complexity of the world diversity support. This is true for languages, but for many other issues as well. This is vital when one starts (as we currently do more an more, based on the DNS and its problems like security) working at the Semantic strata. jfc
participants (4)
-
Danny Younger -
JFC Morfin -
Thomas Narten -
Thomas Roessler