Internationalized Email Addresses:

1
Internationalized E-mail Addresses The Next
Step Maynard J. Kang i-DNS.net
International APRICOT 2002 Bangkok,
Thailand Mar 6, 2002
2
Summary

• Introduction
• Why Internationalized Addresses?
• E-mail Components
• Relevant E-mail Standards
• Internationalized E-mail Addresses
• Impact on Existing Standards
• Possible Solutions
• Feasibility Analysis
• The iEmail Solution
• Conclusion
• References

3
Introduction

• Currently, only 48 of worldwide Internet usage
  is non-English (Afternic.com, 2000)
• By 2003, 70 of language usage online will be
  non-English (Afternic.com, 2000)
• E-mail is by far the most commonly used
  application on the Internet total number of
  Internet mailboxes is expected to hit 1 billion
  by 2005 (IDC, 2000)
• But is E-mail ready for the Multilingual
  Internet?

4

• Why Internationalized Addresses?

• E-mail addresses represent individuals unique
  identity on the Internet
• Current e-mail systems only allow Roman (ASCII)
  characters but there are many users whose
  identity cannot be represented in ASCII
• Therefore, the need for Internationalized E-mail
  Addresses which preserves cultural and
  traditional heritage
• Easier to remember and to communicate across
  print and voice medium

5

• E-mail Components

6

• E-mail Components

7

• E-mail Components

8

• E-mail Components

9

• Relevant E-mail Standards

• RFC 821 Simple Mail Transfer Protocol
• RFC 822 Standard for the Format of ARPA Internet
  Text
• RFC 2045-2049 (MIME Specifications)
• RFC 1869 SMTP Service Extensions
• RFC 1652 SMTP Service Extension for 8bit-MIME
  transport
• RFC 974 Mail Routing and the Domain System
• RFC 1123 Requirements for Internet Hosts -
  Application and Support
• RFC 2476 Message Submission
• RFC 1939 Post Office Protocol - Ver 3
• RFC 2060 Internet Message Access Protocol -
  Version 4rev1

10

• Internationalized E-mail Addresses

Fully Internationalized Chinese E-mail Address
Fully Internationalized Japanese E-mail Address
Fully Internationalized Korean E-mail Address
With service offering from i-DNS.net
International
11

• Internationalized E-mail Addresses

Multilingual .com Chinese E-mail Address
Multilingual .com Japanese E-mail Address
Multilingual .com Korean E-mail Address
Service offering from Verisign Global Registry
Services
12

• Internationalized E-mail Addresses

Username-only Chinese E-mail Address
Username-only Japanese E-mail Address
Username-only Korean E-mail Address
13
Internationalized E-mail Addresses

• Possible representations
• Localized Encoding (BIG5, GB2312, KSC5601, etc)
• 8-bit Transformation of ISO 10646 (UTF-8)
• ASCII-Compatible Encoding of ISO 10646 (RACE,
  AMC-ACE-Z, PunyCode)

14

• Impact on Existing Standards

• RFC 821/SMTP
• SMTP Data restricted to 7-bit ASCII character set
• (Appendix A The SMTP data is 7-bit ASCII
  characters. Each character is transmitted as an
  8-bit byte with the high-order bit cleared to
  zero)
• characters reserved (e.g. ASCII 0-31, _at_
  ! etc)

15

• Impact on Existing Standards

• RFC 821/SMTP
• Restriction may be superceded in ESMTP (RFC 1869)
  transactions with 8BITMIME (RFC 1652) capability
• However, the 8BITMIME extension only applies to
  message content and not message envelope

16

• Impact on Existing Standards

• RFC 822/MFS
• Character set of messages limited to 7-bit ASCII
  although not explicitly restricted
• (Section 3.1 The body is simply a sequence
  of lines containing ASCII characters, and
  Section 3.1.2 The field-body MAY be composed
  of any ASCII characters, except CR or LF)

17

• Impact on Existing Standards

• RFC 822/MFS
• RFC 2047 Message Header Extensions for Non-ASCII
  Text (MIME) redefined message format
• BUT, QP/Base64 transfer-encoding cannot be
  applied to all instances where multilingual
  characters may occur (e.g. addr-spec)
• Transfer-encoding cannot be used in RFC821
  session, for MAIL FROM and RCPT TO parameters
  which contain IDN

18

• Impact on Existing Standards

• RFC 1939/POP3
• Message content conforms to RFC 822
• (Section 11 - All messages transmitted during a
  POP3 session are assumed to conform to the
  standard for the format of Internet text messages
  RFC822)
• but protocol level implies restriction
• (Section 3 - Keywords and arguments consist of
  printable ASCII characters)

19

• Impact on Existing Standards

• RFC 2060/IMAP4
• Mailbox names support modified UTF-7 and modified
  BASE64 representation (change of delimiter to
  avoid confusion)
• (See Section 5.1.3 Mailbox International Naming
  Conventions)

20

• Possible Solutions

• Deprecate 7-bit ASCII character set restriction
  on e-mail protocols
• Implicitly (Flag Day upgrade)
• - MUA/MTA forced to upgrade by certain period
• - May break quite a number of implementations
• Use ASCII-Compatible Encoding (ACE) to represent
  internationalized characters
• Preserves interoperability
• - Legacy mail systems have no problem
• - Seamless transition

21

• Possible Solutions

• Deprecate 7-bit restriction
• Localized/Internationalized charsets (e.g. Big5,
  GB2312, UTF-8) used in e-mail protocol exchanges
  (e.g. SMTP, below)
• S 220 foo.com SMTP service ready
• C HELO bar.com
• S 250 foo.com says hello
• C MAIL FROM
• S 250 OK
• C etc
• Programs like Sendmail and Microsoft Exchange
  SMTP Server would break in this scenario

22
Possible Solutions

• ASCII-Compatible Encoding
• Use ACE (ASCII Compatible Encoding) to encode
  multilingual e-mail addresses for representation
  and transport

ACE conversion
bq--3b2sqyrx_at_bq--3bhc2zmhk7pvidi.com (example
shown in RACE)
23
Possible Solutions

• ASCII-Compatible Encoding
• Inline with IETF-developed IDNA specification
  (Internationalizing Host Names in Applications)
  for Domain Names
• http//www.ietf.org/internet-drafts/draft-ietf-id
  n-idna-06.txt

24

• Feasibility Analysis

25

• The iEmail Solution

• Design Fundamentals
• Display and Rendering (8-bit CES)
• Localized (Big5, GB, KSC5601, SJIS, etc)
• Universal Encoding (UTF-8)
• Representation and Transport (
• ACE (ASCII-compatible encoding) RACE, DUDE,
  AMC-ACE-Z, PunyCode

bq--3b2sqyrx_at_bq--3bhc2zmhk7pvidi.com (example
shown in RACE)
26
The iEmail Solution

• Choice of different implementation possibilities
• Client-based (iClient)
• Web Server-based (CGI layer conversion)
• Mail Server-based (iSMTP and iPOP)
• Other areas where iEmail Technology can be applied

27
Client-based Solution
Send mail to standard SMTP Server bq--3b2sqyrx_at_bq-
-3bhc2zmhk7pvidi.com
Client
SMTP
Internet
(in the To Field)
Convert to ACE E-mail Address bq--3b2sqyrx_at_bq--3bh
c2zmhk7pvidi.com
iClient Software
28
Client-based Solution
29
Web Server-based Solution
Client
Web Server
Mail Server
HTTP
SMTP
bq--3b2sqyrx_at_bq--3bhc2zmhk7pvidi.com
CGI layer conversion
HTTP
bq--3b2sqyrx_at_bq--3bhc2zmhk7pvidi.com
Web Server
Destination MTA
SMTP
SMTP
bq--3b2sqyrx_at_bq--3bhc2zmhk7pvidi.com
bq--3b2sqyrx_at_bq--3bhc2zmhk7pvidi.com
CGI layer conversion
30
Web Server-based Solution
31
Mail Server-based Solution
bq--3b2sqyrx_at_
bq--3b2sqyrx_at_
RFC 821 SMTP
RFC 821 SMTP
Destination
bq--3b2sqyrx_at_
bq--3b2sqyrx_at_
iSMTP Software (Converts to ACE e-mail address)
POP3 IMAP
iPOP Software (Converts back to original address)
32
Mail Server-based Solution
33
Other Areas

• iEmail Technology may be integrated into other
  e-mail software to enable Internationalized
• E-mail Addresses
• Mail User Agents (e.g. Netscape Mail)
• Mail Transfer Agents (e.g. Sendmail)
• Mail Retrieval Software (POP3/IMAP4/etc)
• Other software which utilize e-mail addresses
  (e.g. Calendaring/Scheduling systems, Directory
  servers, PKI servers, etc)

34

• Conclusion

• Use of Internationalized Domain Names becoming a
  reality soon with the IETF IDNA standard
• Internationalized E-mail Addresses are the
  logical next step
• However, this does not come without problems
  e-mail client and server applications have to be
  updated in order to take advantage of this
• Is your organization ready?

35

• References

• Postel, J., Simple Mail Transfer Protocol, STD
  10, RFC 821, USC/Information Sciences Institute,
  August 1982.
• Crocker, D., Standard for the Format of ARPA
  Internet Text Messages, STD 11, RFC 822, UDEL,
  August 1982.
• Moore, K., MIME (Multipurpose Internet Mail
  Extensions) Part Three Message Header Extensions
  for Non-ASCII Text, Draft Standard, RFC 2047,
  University of Tennessee, November 1996.
• Klensin, J., Freed, N., Rose, M., Stefferud, E.,
  and Crocker, D., SMTP Service Extensions, STD
  11, RFC 1869, MCI, Innosoft International, Inc.,
  Dover Beach Consulting, Inc., Network Management
  Associates, Inc., Brandenburg Consulting,
  November 1995.
• Klensin, J., Freed, N., Rose, M., Stefferud, E.
  and D. Crocker, "SMTP Service Extension for
  8bit-MIME Transport", RFC 1652, July 1994.

36

• References

• Partridge, C., "Mail Routing and the Domain
  System", STD 14, RFC 974, January 1986
• Braden, R., Editor, "Requirements for Internet
  Hosts -- Application and Support", STD 3, RFC
  1123, October 1989
• Gellens, R., Klensin, J., Message Submission,
  RFC 2476, December 1998
• Myers, J. and M. Rose, "Post Office Protocol --
  Version 3", STD 53, RFC 1939, May 1996.
• Crispin, M., "Internet Message Access Protocol
  Version 4rev1", RFC 2060, December 1996.

37
Contact Us
Mailing Address i-DNS.net International Pte Ltd 8
Temasek Boulevard 24-02 Suntec Tower
Three Singapore 038988 Tel [phone] Fax
65 (6) 248-6189 URL http//www.i-DNS.net E-mail
General Enquiries info_at_i-DNS.net Tech
Enquiries tech-support_at_i-DNS.net