Network Working Group J. Yao
Internet-Draft X. Lee
Intended status: Informational X. Wu
Expires: April 24, 2009 CNNIC
October 21, 2008
EAI Deployment Practices
draft-yao-eai-deployment-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2009.
Abstract
This document captures experience in implementing systems based on
the EAI protocols. Its aim is to help the engineers to implement
these protocols. This document gives some suggestions about
implementaions and reports on the prototype implementation and the
inter-operability test results, as well as the lessons and insights
gained from this test.
Yao, et al. Expires April 24, 2009 [Page 1]
Internet-Draft EAI Deployment Practices Oct. 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of this specification . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Sending Server . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Relay Server . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Receiving Server . . . . . . . . . . . . . . . . . . . . . 4
2.4. MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Full Support of EAI Protocols . . . . . . . . . . . . . . 5
3. Formation of the Alternate Address . . . . . . . . . . . . . . 5
4. Converting Local Character Codes To UTF-8 encoding . . . . . . 5
5. Restrictions on Characters in Local Part . . . . . . . . . . . 6
6. Local part interpretations . . . . . . . . . . . . . . . . . . 6
7. Lookup in DNS . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Test Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Test Results and Experiences . . . . . . . . . . . . . . . . . 7
9.1. Test Results . . . . . . . . . . . . . . . . . . . . . . . 7
9.2. Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.3. Experiences . . . . . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . . 8
13.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Yao, et al. Expires April 24, 2009 [Page 2]
Internet-Draft EAI Deployment Practices Oct. 2008
1. Introduction
IETF EAI WG has published 4 RFCs [RFC4952] [RFC5335] [RFC5336]
[RFC5337]. These RFCs specifie a protocol for internationalized
email address. The goal of this document is to clarify the EAI
protocols, give some suggestions and guide the implementations. It
highlights areas where EAI implementers may think it is valuable. As
well as clarifications to standards text, this document also mentions
potential choices that can be made, in an attempt to help to foster
interworking between components that use this protocol. EAI extends
the current base email standards [RFC2821] [RFC2822]. It is
important for EAI implementers to carry out a thorough analysis of
all of the existing EMAIL standard documents to understand the
relationships between the base email standards and the current EAI
protocols. A great deal of the advice for making the protocol more
practical is available to those who want to deploy the EAI protocols.
1.1. Role of this specification
The framework document specifies the requirements for, and describes
components of, full internationalization of electronic mail. The EAI
SMTP extension document [RFC5336] specifys the SMTP extension to use
the internationalized email address. The EAI header document
[RFC5335] allows the internationalized email address headers. A
thorough understanding of the information in all these documents and
in the base Internet email specifications [RFC2821] [RFC2822] is
necessary to understand and implement this specification.
This document clarifys some points in the EAI protocols and gives
some suggestions and advice for the usage, implementation and
deployment of internationalized email address.
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
All the specialized terms used in this specification are defined in
the framework document [RFC4952], the EAI SMTP extension document
[RFC5336], the EAI header document [RFC5335] and the base Internet
email specifications [RFC2821] [RFC2822]. In particular, the terms
"ASCII user", and "i18mail user" are used in this document according
to the definitions in the framework one.
[[anchor3: NOTE TO RFC EDITOR: Please remove the following text
before publication.]]
Some ideas of this specification is being discussed on the EAI
Yao, et al. Expires April 24, 2009 [Page 3]
Internet-Draft EAI Deployment Practices Oct. 2008
mailing list. See https://www1.ietf.org/mailman/listinfo/ima for
information about subscribing. The list's archive is at
http://www1.ietf.org/mail-archive/web/ima/index.html.
2. Deployment
2.1. Sending Server
An i18mail user normally uses the EAI-capability sending server which
his internationalized email address resides in. It is very unlikely
that the i18mail user use the non-EAI-capability server to send his
i18mail message. If that situations occures, the sending server will
reject the message or report it as an error. EAI Protocols are used
to exchange the message between at least 2 SMTP servers. If only one
SMTP server supports the EAI protocols, that is meaningless. When
one email service provider implements the EAI service, it can provide
registration of EAI account. The EAI user can exchange the email
within the domain. When another email service provider supports EAI
protocols, the EAI users within these 2 domains can exchange the
message. When the demands for internationalized email address
increase, more and more email service providers will support EAI.
Although it is not possible to support EAI protocol within one night,
it is very possible that the EAI protocol will become more popular
with the time being.
2.2. Relay Server
It is very possible that the relay server does not support EAI
protocols. If EAI server sends the message to the non-EAI-capability
server, the EAI server should adopt one of the 4 methods specified in
RFC 5336[RFC5336]. If the relay server is under the control of one
organization which is in charge of both the sending servers and relay
servers, it is suggested that this organizaiton should update all his
servers to support EAI protocols to make smooth operation.
2.3. Receiving Server
If the reciving server does not support EAI protocols, it will be
unlikely to accept the EAI message. If the EAI-capability server
receives the EAI message, the serve will distribute the message to
the message store.
2.4. MUA
The EAI WG has clearly defined the protocol about how to exchange the
message between 2 SMTP servers. If you want to use the
internationalized email address, it is very vitail that the other
Yao, et al. Expires April 24, 2009 [Page 4]
Internet-Draft EAI Deployment Practices Oct. 2008
parts such as MUA (Mail User Agent) of the email system support EAI
protocols. Since most MUA do not support internationalized email
address, MUA can not send the internationalized email address and
fetch the EAI message from the server. For better use of EAI, MUA
should be upgraded to support EAI protocols.
2.5. Full Support of EAI Protocols
The email system is very complex. Many parts of the email system
will use the email address. It is suggested that all parts of the
email system should be upgraded to support EAI protocols.
3. Formation of the Alternate Address
There are millions email servers and clients, which can not be
updated to support EAI protocols within a night. EAI protocols
designs a transitional method, which allows the eai-capability smtp
server to talk with the non-eai-capability smtp servers. During the
deployment of EAI, it is impossible to make all of SMTP servers to
upgrade to support EAI. The SMTPext document designs an alt-address
parameter for use when downgrading is needed. Only EAI user may want
to use the alt-address. ASCII user has no need to use the alt-
address. The current email protocol also prohibits the use of alt-
address used by ASCII user. The email service provider is suggested
to build both the internationalized email domain and the ASCII email
domain while creating the internationalized email domain. ASCII
domain is regarded as the alias of internationalized domain. Both
domains's MX record in DNS are resolved to the same MX record. When
the email user apply the internationalized email account, it is
better that the system automatically binds it with an ASCII email
account. This email account's name may be selected by email account
applicant. This ASCII email address is regarded as the alt-address
name; it can be an alias aacount of the EAI account. Both
internationalized email address and ASCII email address refer to the
same email store. This method has an advantage: When the EAI user
sending an email to other user using his own EAI account need not
fill in his own alt-address when the receiver does not support EAI
capability. The EAI-capablity server who creats the
internationalized email account will help to fill the ALt-address.
4. Converting Local Character Codes To UTF-8 encoding
Some systems, operating in local environments, will use local
character codes no matter what we specify. On the other hand, having
an application presented with an octet (or bit) string and not
knowing what charset is involved would block the attempt to
Yao, et al. Expires April 24, 2009 [Page 5]
Internet-Draft EAI Deployment Practices Oct. 2008
intelligently display local parts: if one cannot know the character
coding being used, then it is not possible to accurately decode the
characters and display appropriate character glyphs. In many
countries, there are local national standards for character encoding.
For example, in China, GB2312 and GB18000 is the national standards.
Japan has also its own national character encoding standards. So
there are some reasons for permitting local-parts to be written in
locally-used character codes other than the UTF-8 encoding of
UNICODE. The EAI protocol allows only UTF-8 encoding in the local
part in the email header and envelop. The MUA may display the
message information with the local character codes. But when the
email address information is transferred on the wire, it must use the
UTF-8 encoding other than local character encodings. Use of local
coding also implies an encoding for the local part different from
that for the domain part. The domain part of the internationalized
email address will support IDNA[RFC3490] and uses the UTF-8
encodings. If local codings can be avoided entirely, it will
considerably reduce complexity and "opportunities" for systems to not
interoperate.
5. Restrictions on Characters in Local Part
The EAI specification is extremely liberal about what can be included
in a UTF-8 string that represents a local-part. It prohibits the use
of quoted strings, or quoted characters, in non-ASCII local parts.
Quoted strings and characters in local parts have, in general, been
nothing but trouble and there appears to be no reason to carry that
trouble forward into an internationalized world. It is suggested
that applying restrictions by use of a stringprep [RFC3454] profile
that would eliminate particularly problematic characters is
suggested. IDNAbis label check may be used for local parts. Some
languages characters has some special features. For example, Chinese
characters has some varants. When registering the email account, the
technique specified in the RFC 3743 may be used for the possible
confusion. ASCII local-parts are inherently case sensitive. The
local systems are encouraged to not take advantage of that feature.
All internationalized email local part are suggested to be case
insensitive.
6. Local part interpretations
In the Internet email context, the interpretation and permitted
syntax for an email local-part is entirely the responsibility of the
receiving system. The general advice to system designers still
include "treat addresses in a case-independent fashion" and "do not
use addresses that require quoting". Senders should continue to be
Yao, et al. Expires April 24, 2009 [Page 6]
Internet-Draft EAI Deployment Practices Oct. 2008
conservative about what they send, and relays should continue to
avoid presumptions about their understanding of the content of local-
parts. Receiving systems that have reason to adopt more restricted
syntax rules, or interpretations of matching, should continue to be
able to do so.
7. Lookup in DNS
The domain part of the email address is used to route the message to
the proper destination. The domain part must be processed into the
punycode form specified in RFC 3490 before DNS lookup.
8. Test Scenarios
We have test some scenarios described in scenario documents
[Secnarios]. Testing between EAI system with the same implementation
(postfix)
1. Scenario 1:Two i18mail users
2. Scenario 2:Three i18mail users
3. Scenario 3:An i18mail user sends to one ascii user
Testing between EAI systems with different implementations
1. Test with NIDA (own implementation with python )
2. Test with JPRS (own implementation with C )
3. Test with AFILIAS (implementation based on sendmail)
4. Test with TWNIC (implementation based on sendmail)
9. Test Results and Experiences
9.1. Test Results
From these tests, we get the following results: The implementation
based on the EAI protocol is workable. We need more email service
providers to implement and deploy EAI protocols.
9.2. Firewall
During the test, we find that some firewall will block the EAI
message and cut off the SMTP connection. It is suggested that the
firwall should be updated to support EAI protocols too.
Yao, et al. Expires April 24, 2009 [Page 7]
Internet-Draft EAI Deployment Practices Oct. 2008
9.3. Experiences
During the test, we find that many users are interested in using the
internationaliezed email address. They prefer more email service
providers to provide such services. During the implementation,
different implementer may encounter different problems. If the
implementers try to analysed the EAI protocols and the base protcols
of RFC 2821 and RFC 2822 throughtly, it is still easy to implement
it. Since many implementers have implemented EAI protocols based on
different email source code such as Postfix and Sendmail and done a
lot of inter-operating, it has already proved that the EAI protocols
can be implemented and workable.
10. IANA Considerations
There is no IANA consideraton.
11. Security Considerations
See the extended security considerations discussion in the framework
document [RFC4952].
12. Acknowledgements
Many ideas are from the discussion in the list ima@ietf.org. John C
Klensin has done a lot of reasearch on ASCII email address and
internationalized email address. I got many significant words or
ideas from him. Many friends and experts in the EAI WG help us to
produce the valuable ideas. Many organizations including
CNNICGBP[not]TWNIC, JPRS, NIDA, AND AFFLILIAS have implemented EAI
systems. These organizations have already done a lot of inter-
operating testing.
13. References
13.1. Normative References
[ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968.
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994.
Yao, et al. Expires April 24, 2009 [Page 8]
Internet-Draft EAI Deployment Practices Oct. 2008
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, January 2003.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007.
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008.
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email Addresses", RFC 5336, September 2008.
[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications", RFC 5337,
September 2008.
13.2. Informative References
[EAI-downgrading]
YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading
mechanism for Internationalized eMail Address",
draft-ietf-eai-downgrade-07 (work in progress), 3 2008.
[RFC2821bis]
Klensin, J., "Simple Mail Transfer Protocol",
Yao, et al. Expires April 24, 2009 [Page 9]
Internet-Draft EAI Deployment Practices Oct. 2008
draft-klensin-rfc2821bis-10 (work in progress), 4 2008.
Authors' Addresses
Jiankang YAO
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813007
Email: yaojk@cnnic.cn
Xiaodong LEE
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813020
Email: lee@cnnic.cn
Xiaodong WU
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813229
Email: wuxiaodong@cnnic.cn
Yao, et al. Expires April 24, 2009 [Page 10]
Internet-Draft EAI Deployment Practices Oct. 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Yao, et al. Expires April 24, 2009 [Page 11]