Internet Message Access Protocol Internationalization
RFC 5255
Document | Type | RFC - Proposed Standard (June 2008; Errata) | |
---|---|---|---|
Authors | Alexey Melnikov , Arnt Gulbrandsen , Chris Newman | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Reviews | |||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5255 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Lisa Dusseault | ||
Send notices to | (None) |
Network Working Group C. Newman Request for Comments: 5255 Sun Microsystems Category: Standards Track A. Gulbrandsen Oryx Mail Systems GmhH A. Melnikov Isode Limited June 2008 Internet Message Access Protocol Internationalization Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME). This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. Newman, et al. Standards Track [Page 1] RFC 5255 IMAP Internationalization June 2008 Table of Contents 1. Introduction ....................................................3 2. Conventions Used in This Document ...............................3 3. LANGUAGE Extension ..............................................3 3.1. LANGUAGE Extension Requirements ............................4 3.2. LANGUAGE Command ...........................................4 3.3. LANGUAGE Response ..........................................6 3.4. TRANSLATION Extension to the NAMESPACE Response ............7 3.5. Formal Syntax ..............................................8 4. I18NLEVEL=1 and I18NLEVEL=2 Extensions ..........................9 4.1. Introduction and Overview ..................................9 4.2. Requirements Common to Both I18NLEVEL=1 and I18NLEVEL=2 ....9 4.3. I18NLEVEL=1 Extension Requirements ........................10 4.4. I18NLEVEL=2 Extension Requirements ........................10 4.5. Compatibility Notes .......................................11 4.6. Comparators and Character Encodings .......................11 4.7. COMPARATOR Command ........................................13 4.8. COMPARATOR Response .......................................14 4.9. BADCOMPARATOR Response Code ...............................14 4.10. Formal Syntax ............................................14 5. Other IMAP Internationalization Issues .........................15 5.1. Unicode Userids and Passwords .............................15 5.2. UTF-8 Mailbox Names .......................................15 5.3. UTF-8 Domains, Addresses, and Mail Headers ................15 6. IANA Considerations ............................................16 7. Security Considerations ........................................16 8. Acknowledgements ...............................................16 9. Relevant Sources of Documents for Internationalized IMAP Implementations ................................................17 10. Normative References ..........................................17 11. Informative References ........................................18 Newman, et al. Standards Track [Page 2] RFC 5255 IMAP Internationalization June 2008 1. Introduction This specification defines two IMAP4rev1 [RFC3501] extensions to enhance international support. These extensions can be advertised and implemented separately. The LANGUAGE extension allows the client to request a suitable language for protocol error messages and in combination with the NAMESPACE extension [RFC2342] enables namespace translations. The I18NLEVEL=2 extension allows the client to request a suitable collation that will modify the behavior of the base specification's SEARCH command as well as the SORT and THREAD extensions [SORT]. This leverages the collation registry [RFC4790]. The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use i;unicode-casemap comparator, as defined in [UCM]. I18NLEVEL=1 is a simpler version of I18NLEVEL=2 with no ability to select a different collation. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",Show full document text