One document matched: draft-lee-jet-ima-00.txt
Internet Draft Jiankang Yao, Editor
Draft-Lee-JET-IMA-00.txt CNNIC
June 27, 2005 Jeff Yeh Editor
Expires: December 27,2005 TWNIC
Internationalized eMail Address (IMA)
< draft-lee-jet-ima-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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft expires on December 27, 2005.
Abstract
An email address has two parts - local part and domain part -
separated by "@" sign. This document describes a basic solution to
internationalized email address (IMA) and includes some preliminary
survey results. The proposed solution enables SMTP servers to support
IMA. The solution discussed in this document is immediately
deployable by interested parties without affecting or breaking any
other existing systems.
Document Conventions
JET Expires - December 2005 [Page 1]
Internet draft IMA June 2005
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].
1. Introduction to IMA
In order to use internationalized email addresses, we need to
internationalize both domain part and local part of email address.
Domain part of email addresses had been internationalized through
IDNA [RFC3490]. But the local part of email address still remains as
non internationalized.
At present, the use of Internet email address is restricted to a
subset of 7-bit ASCII [RFC2821][RFC2822]. The MIME extensions
provides a mechanism for the transmission of non-ASCII data that were
previously unsupported in Internet mail. But it does not provide the
mechanism for internationalized email address. [RFC2047] defines the
message header extension for non ASCII 8-bit MIME messages. However,
it does not address the issue if email addresses include non-ASCII
characters. Anticipating the need to use the internationalized email
address, the SMTP protocol should be extended to provide the
transport mechanism for the internationalized email address. The
length restrict to the local part in the section of RFC 2822 may need
to be updated.
2. Problem statement
Internationalized Domain Name (IDN) was standardized 2 years ago
(2003) and several registries started to accept IDN registrations and
the name resolutions. While the take-up of IDN varies, there is a
strong demand for IDN in the regions where English is not their
native language.
Particularly in the CJK community, we noticed that registrants of IDN
often enquired about if they could use Internationalized eMail
Address (IMA) too. Unfortunately, while the domain name portion of
the Email address could use IDN standards, there are no standards to
internationalize the local-part (left hand side of the "@" mark).
On the other hand, we envisage strong demands for IMA when IDN
becomes popular. IMA will also promote the deployment of IDN.
Several solutions for IMA have been deployed, e.g.,in China (35.com,
zzy.cn, bizcn.com, ce.net.cn, dns.com.cn and topbiz.cn), but the lack
of open and interoperable standards means that users of one system
could not (reliably) communicate with users of another system.
Therefore, the Internet community would benefit from the development
of an open and interoperable IETF IMA standard.
JET Expires - December 2005 [Page 2]
Internet draft IMA June 2005
3. Requirements
Any IMA solution should qualify the following requirements:
3.1 Short term (2-5 years) solution
The solution should not extend too long, so that IMA can be adopted
as soon as possible by interested companies. The solution also should
be easily deployable, so that IMA can be easily deployed by most
interested organizations during 2-5 years if they wish to.
3.2 Backward compatible with the existing standards
The email service is one of the most important Internet services. Any
updating to Internet protocols should not interfere with the
operation of the Internet. The IMA solution should not break the base
of the email service and be backward with the existing email
standards.
3.3 Internationalized solution (over localized solution)
The solution should be an internationalized one rather than localized
one.
4. Architecture
Solving the problem of IMA is not easy. We should divide it into two
phases. In the first phase, we consider the ACE@ACE solution, which
is easy to implement, backward compatible, short-term and
internationalized solution. In the next phase, we may consider other
mechanisms such as UTF-8@ACE. In the ACE@ACE solution, the local part
of the IMA will be converted to ASCII Compatible Encoding; IDNA
(RFC3490) will be applied to the domain part of the IMA. In this
draft, we mainly focus on the ACE@ACE solution.
4.1 Encoding
A good ACE converting algorithm should be considered according to the
following criteria:
Popularity
Length of the encoded name
Implementation easiness
Produce valid email address
Case sensitivity
Impact on existing protocol
4.2 Normalization (IMAprep)
JET Expires - December 2005 [Page 3]
Internet draft IMA June 2005
There are profiles for Stringprep such as Nameprep[RFC3491] dealing
with the IDN preparation and Nodeprep[RFC3920] for internationalized
node identifiers. IMAprep is introduced to prepare the local part of
IMA. IMAprep is a profile of Stringprep [RFC3454]. IMAprep [Appendix
A] is used to process only the local part of IMA, not the whole email
address. In IMAprep, no normalization and no case folding are needed.
And there must be a prohibited list, but we will not discuss details
of IMAprep in this draft.
4.3 Mail Delivery Agent (MDA)
MDA is a part of mail servers, which are responsible for delivery of
mails to local mail spool or sending out to another mail server.
Usually, IMA is represented in the format of UTF-8 in a host while it
should be converted into ACE format while being transported over the
wire. There are various unofficial conventions for structured local
parts, like owner-listname, user+tag, sublocal.local, path!user, etc.
When internationalized local part being converted into ACE format, it
actually causes some problems. Therefore, MDA may need to convert
internationalized local part back to UTF8 (or original encoding) for
further mailing processing.
4.4 Prefix
Since the prefix "xn--" had been used for IDNA, it is better that
other prefix such as "bq--" is used for the local part of IMA to
avoid of potential confusion.
5. Deployment
Email is an important and popular internet service. Any new
deployments of SMTP servers which support IMA should not disturb the
running of current email system. Since all the SMTP servers around
the world can not support IMA immediately, ACE@ACE solution would be
the most harmless solution to implement and deploy.
6. Potential problems
6.1 Impact to IRI
The mailto: schema in IRI [RFC3987] may need to be modified when IMA
is standardlized.
6.2 POP and IMAP
While SMTP takes care of the transportation of messages and the
header fields correspond to the display management by the clients,
POP essentially handles the retrieval of mail objects from the server
by a client. In order to use internationalized user names based on
IMA for the retrieval of messages from a mail server using the POP
JET Expires - December 2005 [Page 4]
Internet draft IMA June 2005
protocol, a new capability should be introduced following the POP3
extension mechanism [RFC 2449].
IMAP uses the traditional user name which is based on ASCII. IMAP
should be updated to support the internationalized user names based
on IMA for the retrieval of messages from a mail server
7. Security Considerations
There have been discussions on so called "IDN-spoofing". IDN
homograph attacks allow an attacker/phisher to spoof the domain/URLs
of businesses. The same kind of attack is also possible on the local
part of internationalized email addresses.
IMA can also introduce new email spamming. Many local parts of IMA
will be the names of the person or company, which could easily be
used by email spammer to guess the email address to produce the
rubbish emails.
Email spamming may combine with email spoofing and homograph attacks,
making it more difficult to determine who actually sent the email.
Any solution that meets the requirements in this document must not be
less secure than the current Email Service. Specifying requirements
for internationalized email addresses does not itself raise any new
security issues. However, any change to the email service may affect
the security of any protocol that uses the email address. A thorough
evaluation of those protocols for security concerns will be needed
when they are developed.
8. References
[RFC1869] Klensin,J., Freed, N., Rose, M., Stefferud, E., Crocker, D.,
"SMTP Service Extensions", RFC 1869, November 1995.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[RFC2449] R. Gellens, C. Newman, L. Lundblade, "POP3 Extension
Mechanism" RFC2449 November 1998
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC3454] P. Hoffman, M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")" RFC3454 December 2002
[RFC3490] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",RFC 3490,
March 2003.
[RFC3491] P. Hoffman , M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names" RFC3491 March 2003
JET Expires - December 2005 [Page 5]
Internet draft IMA June 2005
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications (IDNA)", RFC 3492,
March 2003.
[RFC3629] Yergeau, F.,"UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
[RFC3920] P. Saint-Andre, "Extensible Messaging and Presence Protocol
(XMPP): Core", RFC3920 October 2004
[RFC3987] M. Duerst, M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC3987 January 2005
9. Authors
Xiaodong LEE (lee@cnnic.cn)
China Internet Network Information Center (CNNIC)
Nai-Wen Hsu (snw@twnic.net.tw)
Taiwan Network Information Center (TWNIC)
Yoshiro YONEYA yone@jprs.co.jp
Japan Registry Services, Co. Ltd
YangWoo Ko (yw@mrko.pe.kr)
Korea Network Information Center
James Seng (james@seng.cc)
Former co-chair of IETF IDN Working Group
Editors
Jiankang YAO (yaojk@cnnic.cn)
China Internet Network Information Center (CNNIC)
Jeff Yeh (jeff@twnic.net.tw)
Taiwan Network Information Center (TWNIC)
10. Acknowledgments
Authors gratefully acknowledge the contributions of:
* John C Klensin for his discussion with us in 62nd IETF meeting and
his internet draft about IMA
* Paul Hoffman and Adam M. Costello for their internet draft about
IMA
JET Expires - December 2005 [Page 6]
Internet draft IMA June 2005
Appendix A: IMAprep
Conclusion: no normalization, but there still prep needed, define our
own prep for the email local part
our own prep:
no normalization
no case folding
prohibited list - ..... (discussed later after meeting )
local part ??problem:
No RFC standards define this part
The MDA must support internationalized local part, anyway
No use of ACE deals the mail processing, so it should be
converted back to UTF8, then be dealt with the mail processing
JET Expires - December 2005 [Page 7]
Internet draft IMA June 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
JET Expires - December 2005 [Page 8]
| PAFTECH AB 2003-2024 | 2024-04-20 02:16:15 |