draft-ietf-imapext-i18n-00.txt   draft-ietf-imapext-i18n-01.txt 
Network Working Group C. Newman Network Working Group C. Newman
Internet-Draft Sun Microsystems Internet-Draft Sun Microsystems
Expires: November 7, 2003 May 9, 2003 Expires: October 30, 2003 May 2003
Internet Message Access Protocol Internationalization Internet Message Access Protocol Internationalization
draft-ietf-imapext-i18n-00.txt draft-ietf-imapext-i18n-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 7, 2003. This Internet-Draft will expire on October 30, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Internet Message Access Protocol (IMAP) version 4rev1 has basic Internet Message Access Protocol (IMAP) version 4rev1 has basic
support for non-ASCII characters in mailbox names and search support for non-ASCII characters in mailbox names and search
substrings. It also supports non-ASCII message headers and content substrings. It also supports non-ASCII message headers and content
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.5 COMPARATOR SEARCH and SORT Key . . . . . . . . . . . . . . . . 10 4.5 COMPARATOR SEARCH and SORT Key . . . . . . . . . . . . . . . . 10
4.6 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Other IMAP Internationalization Issues . . . . . . . . . . . . 11 5. Other IMAP Internationalization Issues . . . . . . . . . . . . 11
5.1 UTF-8 Userids and Passwords . . . . . . . . . . . . . . . . . 11 5.1 UTF-8 Userids and Passwords . . . . . . . . . . . . . . . . . 11
5.2 UTF-8 Mailbox Names . . . . . . . . . . . . . . . . . . . . . 12 5.2 UTF-8 Mailbox Names . . . . . . . . . . . . . . . . . . . . . 12
5.3 UTF-8 Domains, Addresses and Mail Headers . . . . . . . . . . 12 5.3 UTF-8 Domains, Addresses and Mail Headers . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Relevant Standards for i18n IMAP Implementations . . . . . . . 14 9. Relevant Standards for i18n IMAP Implementations . . . . . . . 14
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . . 14
Informative References . . . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 16
1. Conventions Used in this Document 1. Conventions Used in this Document
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in "Key words for in this document are to be interpreted as defined in "Key words for
use in RFCs to Indicate Requirement Levels" [1]. use in RFCs to Indicate Requirement Levels" [1].
The formal syntax use the Augmented Backus-Naur Form (ABNF) [2] The formal syntax use the Augmented Backus-Naur Form (ABNF) [2]
notation including the core rules defined in Appendix A of RFC 2234. notation including the core rules defined in Appendix A of RFC 2234.
skipping to change at page 3, line 44 skipping to change at page 3, line 44
3. LANGUAGE Extension 3. LANGUAGE Extension
IMAP allows server responses to include human-readable text that in IMAP allows server responses to include human-readable text that in
many cases needs to be presented to the user. But that text is many cases needs to be presented to the user. But that text is
limited to US-ASCII by the IMAP specification [6] in order to limited to US-ASCII by the IMAP specification [6] in order to
preserve backwards compatibility with deployed IMAP implementations. preserve backwards compatibility with deployed IMAP implementations.
This section specifies a way for an IMAP client to negotiate which This section specifies a way for an IMAP client to negotiate which
language the server should use when sending human-readable text. language the server should use when sending human-readable text.
The LANGUAGE extension only provides a mechanism for altering fixed
server strings such as response text and NAMESPACE folder names.
Assigning localized language aliases to shared mailboxes would be
done with a separate mechanism such as the proposed ANNOTATEMORE
extension. [16]
3.1 LANGUAGE Extension Requirements 3.1 LANGUAGE Extension Requirements
IMAP servers that support this extension MUST list the keyword IMAP servers that support this extension MUST list the keyword
LANGUAGE in their CAPABILITY response as well as in the greeting LANGUAGE in their CAPABILITY response as well as in the greeting
CAPABILITY data. CAPABILITY data.
A server that advertises this extension MUST use the language A server that advertises this extension MUST use the language
"i-default" as described in [3] as its default language until another "i-default" as described in [3] as its default language until another
supported language is negotiated by the client. A server MUST include supported language is negotiated by the client. A server MUST include
"i-default" as one of its supported languages. "i-default" as one of its supported languages.
skipping to change at page 14, line 12 skipping to change at page 14, line 12
Mark Crispin, Mark Pustilnik and Larry Osterman for their many Mark Crispin, Mark Pustilnik and Larry Osterman for their many
suggestions that have been incorporated into this document. suggestions that have been incorporated into this document.
Initial discussion of the COMPARATOR extension involved input from Initial discussion of the COMPARATOR extension involved input from
Mark Crispin and other participants of the IMAP Extensions WG. Mark Crispin and other participants of the IMAP Extensions WG.
9. Relevant Standards for i18n IMAP Implementations 9. Relevant Standards for i18n IMAP Implementations
This is a non-normative list of standards to consider when This is a non-normative list of standards to consider when
implementing i18n aware IMAP software. implementing i18n aware IMAP software.
o The LANGUAGE and COMPARATOR extensions to IMAP (this o The LANGUAGE and COMPARATOR extensions to IMAP (this
specification). specification).
o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501. o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501.
o The Mailbox International Naming Convention in section 5.1.3 of o The Mailbox International Naming Convention in section 5.1.3 of
RFC 3501. RFC 3501.
o MIME [9] for message bodies. o MIME [9] for message bodies.
o MIME header encoding [10] for message headers. o MIME header encoding [10] for message headers.
o MIME Parameter Value and Encoded Word Extensions [11] for o MIME Parameter Value and Encoded Word Extensions [11] for
filenames. Quality IMAP server implementations will automatically filenames. Quality IMAP server implementations will automatically
combine multipart parameters when generating the BODYSTRUCTURE. combine multipart parameters when generating the BODYSTRUCTURE.
There is also some deployed non-standard use of MIME header There is also some deployed non-standard use of MIME header
encoding inside double-quotes for filenames. encoding inside double-quotes for filenames.
o IDNA [13] and punycode [14] for domain names (presently only o IDNA [13] and punycode [14] for domain names (presently only
relevant to IMAP clients). relevant to IMAP clients).
o The UTF-8 charset [7]. o The UTF-8 charset [7].
o The IETF policy on Character Sets and Languages [3]. o The IETF policy on Character Sets and Languages [3].
10. Open Issues
1. Should there be an explicit request for the list of comparators
in the COMPARATOR response code?
2. Should we add a command to fetch the lookup tables associated
with a comparator?
3. Need examples for COMPARATOR extension.
Normative References Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", [3] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998. BCP 18, RFC 2277, January 1998.
[4] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998. [4] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[5] Alvestrand, H., "Tags for the Identification of Languages", BCP [5] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001. 47, RFC 3066, January 2001.
[6] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", [6] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
RFC 3501, March 2003. RFC 3501, March 2003.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
draft-yergeau-rfc2279bis-04 (work in progress), February 2003. 63, RFC 3629, November 2003.
[8] Newman, C., "Internet Application Protocol Comparator Registry", [8] Newman, C., "Internet Application Protocol Comparator Registry",
draft-newman-i18n-comparator-00 (work in progress), May 2003. draft-newman-i18n-comparator-01 (work in progress), October
2003.
Informative References Informative References
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996. RFC 2045, November 1996.
[10] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part [10] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 2047, Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996. November 1996.
skipping to change at page 16, line 5 skipping to change at page 15, line 34
Domain Names in Applications (IDNA)", RFC 3490, March 2003. Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[14] Costello, A., "Punycode: A Bootstring encoding of Unicode for [14] Costello, A., "Punycode: A Bootstring encoding of Unicode for
Internationalized Domain Names in Applications (IDNA)", RFC Internationalized Domain Names in Applications (IDNA)", RFC
3492, March 2003. 3492, March 2003.
[15] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL [15] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL
- SORT AND THREAD EXTENSION", draft-ietf-imapext-sort-12 (work - SORT AND THREAD EXTENSION", draft-ietf-imapext-sort-12 (work
in progress), March 2003. in progress), March 2003.
[16] Daboo, C., "IMAP ANNOTATEMORE Extension",
draft-daboo-imap-annotatemore-02 (work in progress), March
2003.
Author's Address Author's Address
Chris Newman Chris Newman
Sun Microsystems Sun Microsystems
1050 Lakes Drive 1050 Lakes Drive
West Covina, CA 91790 West Covina, CA 91790
US US
EMail: chris.newman@sun.com EMail: chris.newman@sun.com
skipping to change at page 18, line 7 skipping to change at page 17, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/