Network Working Group
Internet-Draft
Expires:
TWNIC
April 1, 2005
I18N extension for I-Email delivery
Abstract
Currently IDN has been launched in many ccTLDs and gTLDs, since the IDN relevant
standards [RFC3490-3492, RFC3454] had been published. The CNNIC, JPNIC, KRNIC,
and TWNIC also adopt JET Guidelines [RFC 3743] for Chinese, Japanese and Korean
IDN registration and administration. It would estimate more than 1 million IDNs have
been registered since 2000.
The widespread IDN users would like to use IDN to apply Internet Applications. Such
like: web page, email, telnet, ftp, etc. For web page, there are some browsers have
support IDN. Some registries/registrars also offer their registrants the IDN plug-in for
browser. The more the users use IDN, the more they requiring use IDN on other Internet
Applications, especially use the I-Email.
This document intend to express the framework of extend the SMTP to construct the
environment for delivering I-Email smoothly. This framework also include the
consideration of backward compatible mechanism.
Document Conventions
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].
Table of Contents
1. Introduction
2. I18N extension SMTP server
3. I-Email delivery minimum criteria
for SMPT server
4. I18N extension SMTP server handshaking
5. I18N extension SMTP server and backward compatible mechanism
6. I18N eMail address handling diagram
7. Other requirement for a well I-Email environment
8. Comment
1. Introduction
An Email address is constructed sequentially by the left side “ASCII local part”, “@”
sign and the right side “ASCII domain name”. An “I-Email” means the Email could be
properly delivered of which address is constructed sequentially by the left side, “@” sign
and right side in any one of following combination form: “internationalized local
part(ILP)”, “@”,“IDN” or “ASCII local part”,“@”,”IDN” or “ILP”,”@”,”ASCII domain
name” .
Currently, the SMTP [RFC2821, RFC2822] do not aware of I-Email. In order to let
I-Email delivery through SMTP servers, we need upgrade SMPT server to be I18N eMail
address aware—I18N extension SMTP server. However, it obviously is an extremely
difficult task if we expect the worldwide SMTP servers to be upgraded in one night. It
will face to the situation of a part of SMTP servers are upgraded and the other part are not.
Then an I-Email would delivery through among the I18N/Non-I18N extension SMTP
servers. Thus, how to let an I-Email be delivered smoothly and successfully is one of the
important issue.
This document is highly reference RFC2821, RFC2822 and the two documents:
Internationalization of Email Addresses <draft-klensin-emailaddr-i18n-02.txt> (by John
Klensin) and Internationalizing Mail Addresses in Applications (IMAA)
<draft-hoffman-imaa-00.txt> (by Paul Hoffman & Adam M. Costello)
2. I18N extension SMTP server
An I-Email address is constructed sequentially by the left side “internationalized local
part”, “@” sign and the right side “IDN”. A SMTP server MUST be extension to aware
I18N eMail address in order to recognize and process I-Email address.
The right side of “@” sign is “IDN”, the “IDN” is already be defined by IDNA
[RFC3490]. And, the left side of is “internationalized local part”, the SMTP need extend
to aware I18N eMail address. The I18N eMail address aware SMTP server MUST
support IDNA [RFC 3490] and I18N extension SMTP (defined in this document).
3. I-Email delivery minimum criteria for SMPT server
The purpose of delivering an Email is let the Email been send from the sender to the
destination receiver. The basic delivery route for an Email is basically from sender’s
SMTP server, SMTP relay or gateway servers and destination SMTP server. During the
period of upgrade and deploy the current SMTP servers from non-I18N extension to the
I18N extension SMTP servers, the duration is not to be planning and controlled in one
night or a very short of time. Thus, the backward compatibility has to well considering.
This document will propose a backward compatible mechanism to overcome the
problems which will happen during the upgrade and deploy duration (this will be
expressed in later paragraph). The important thing is to find the “minimum criteria” for
an I-Email could be properly send out at the I18N extension SMTP server upgrade and
deploy duration. With the backward compatible mechanism proposed in this document,
the minimum criteria for delivery an I-Email are:
(1) Destination SMTP server MUST be an I18N extension SMTP server.
(2) Sender’s and destination’s MUA MUST support I18N extension for SMTP
An I-Email will be properly “sending out” if its delivering environment would satisfy
the “minimum criteria”. And, if one need receive an I-Email properly, he MUST
upgrade his own mail server to be I18N extension.
4. I18N extension SMTP server handshaking
During the stage of two SMTP servers doing handshaking, each SMTP server would
understand each other support what kind of EXTENSION. The I18N extension SMTP
server will echo “250-I18N” while doing EHLO handshaking. This will help the previous
server judge the next server is I18N extension or not. And the previous server would
accord the result of echo to decide the next process. This process during handshaking
stage which play a part of backward compatible mechanism.
5. I18N extension SMTP server and backward compatible mechanism
The I18N extension SMTP server would do handshaking with the next server. If the
next server echo “250-I18N” that means the next server is also I18N extension SMTP
server. Else, the next server is a non-I18N extension SMTP server. The I18N extension
SMTP server would do some certain process for the non-I18N extension SMTP server.
The I18N extension SMTP server would encode the I-Email address of MAIL FROM and
RCPT TO to be ASCII compatible encode for non-I18N extension SMTP server. The goal
of this process is to accomplish backward compatibility.
The encoding of MAIL FROM and RCPT TO in I18N extension SMTP server’s
address slot is:
MAIL FROM: UTF8@UTF8
RCPT TO: UTF8@UTF8
The encoding which choose UTF8 here is because UTF8 is readable (in specific
environment) and matchingable. And UTF8 has already been widely used in doing
encoding transferring.
The I18N extension SMTP server will transfer the encoding to be ASCII compatible
and then send it out to next non-I18N extension SMTP server:
MAIL FROM: iesg--MIME@punycode
RCPT TO: iesg--MIME@punycode
The encoding of the right side of “@” sign is a domain name which is adapted IDNA
[RFC 3490]. The left side of “@” sign is the local part, which is make the UTF8 encode
user name transfer to MIME and add the prefix “iesg--” (to distinguish it is MIME
encode or real ASCII user name) to get the ASCII compatible encoding. Why propose
using MIME as the ASCII compatible encoding, because MIME encoding has already
been widely used in SMTP relative environment currently.
6. I18N eMail address handling diagram
According to the I-Email delivery minimum criteria for SMPT server express in this
document are:
(1) Destination SMTP server MUST be an I18N extension SMTP server.
(2) Sender’s and destination’s MUA MUST support I18N extension for SMTP
There are some situation would exist when handling I18N eMail address. The
following diagrams list the possible situations and show how to handle the I-Email
address.
6.1 If sending SMTP server is I18N extension SMTP server:
While before sending an I-Email, the sending I18N extension SMTP server would do
handshaking with the next SMTP server to judge which is I18N extension SMTP server
or not.
If the next SMTP server is not I18N extension, the sending I18N extension SMTP
server would transfer the encoding of MAIL FROM and RCPT TO from UTF8@UTF8 to
be iesg--MIME@punycode. This is the important part of backward compatibility
mechanism.
Otherwise, the sending I18N extension SMTP server would not transfer the encoding
of MAIL FROM and RCPT TO and send them out as UTF8@UTF8.
I18N SMTP
server
Next SMTP
Yes
server is I18N
aware?
MAIL FROM: UTF8@UTF8
RCPT TO: UTF8@UTF8
No
Encode
MAIL FROM: UTF8@UTF8
RCPT TO: UTF8@UTF8
to:
MAIL FROM: iesg--MIME@punycode
RCPT TO: iesg--MIME@punycode
6.2 If sending SMTP server is non-I18N extension SMTP server:
The non-I18N extension SMTP server does not have to judge the next SMTP server is
I18N extension or not while do handshaking. This sending non-I18N extension SMTP
server would send out the email with MAIL FROM and RCPT TO in the form of ASCII.
That is it does not have to do any process to handle the I-Email address slot. Because
there must have one previous I18N extension SMTP server had transferred the I-Email
address slot MAIL FROM and RCPT TO to be iesg--MIME@punycode, the ASCII
compatible from.
So, the behavior of non-I18N extension SMTP server for sending an I18N Email
would not different from sending a non-I18N Email.
Non-I18N
SMTP server
MAIL FROM: iesg--MIME@punycode
RCPT TO: iesg--MIME@punycode
(the same behavior as the current non-I18N SMTP server)
6.3 How if the sender’s SMTP server is non-I18N extension?
Because the minimum criteria of delivery I-Email which expressed in this document
are:
(1) Destination SMTP server MUST be an I18N extension SMTP server.
(2) Sender’s and detinatgion’s MUA MUST support I18N extension for SMTP
So, the MUA MUST support I18N extension for SMTP. While before sending out an
I-Email, the MUA would do handshaking with the next SMTP server, to judge the one is
I18N extension SMTP server or not.
If the next SMTP server is not I18N extension, the MUA would transfer the encoding
of MAIL FROM and RCPT TO from UTF8@UTF8 to be iesg--MIME@punycode. This
behavior is the same as the I18N extension SMTP server to perform the backward
compatibility mechanism.
Otherwise, the MUA also perform the same behavior as the I18N extension SMTP
server, would not transfer the encoding of MAIL FROM and RCPT TO and send them
out as UTF8@UTF8.
MUA
(I18N aware)
Sender’s SMTP
Yes
server is I18N
aware?
MAIL FROM: UTF8@UTF8
RCPT TO: UTF8@UTF8
No
Encode
MAIL FROM: UTF8@UTF8
RCPT TO: UTF8@UTF8
to:
MAIL FROM: iesg--MIME@punycode
RCPT TO: iesg--MIME@punycode
7. Other requirement for a well I-Email environment
Except the SMTP need I18N extension, the OS and some other user name related
Internet applications (such as: telnet, ftp, pop3……) also requiring support I18N user
name (ex: UTF8 encoding) for some reasons.
(1) Readability
(2) Matchability
(3) Length limitation
The ASCII compatible encoding is not human readable. If the OS do not support
I18N user name, then the administrator would have to face to the readability problem.
And it is difficult to do searching and matching process when manage an I18N user name.
When transfer an I18N user name to an ASCII compatible encoding, the length of ASCII
compatible encoding user name would be far more then the length limitation of some
Unix based OS. For some Unix based OS, the length of user name is limit to 8 bytes. In
some case, 8 bytes only could contain one character of Chinese in some ASCII
compatible encoding.
Because of the same concerns for the OS, the user name related Internet applications
(such as: telnet, ftp, pop3……) would also need upgrade to aware I18N user name.
8. Comment