--- /dev/null
+\r
+\r
+\r
+\r
+\r
+\r
+Network Working Group Chris Newman\r
+Internet-Draft Sun Microsystems\r
+Intended Status: Proposed Standard Arnt Gulbrandsen\r
+ Oryx Mail Systems GmhH\r
+ Alexey Melnikov\r
+ Isode Limited\r
+ February 1, 2008\r
+\r
+ Internet Message Access Protocol Internationalization\r
+ draft-ietf-imapext-i18n-15.txt\r
+\r
+\r
+Status of this Memo\r
+ By submitting this Internet-Draft, each author represents that any\r
+ applicable patent or other IPR claims of which he or she is aware\r
+ have been or will be disclosed, and any of which he or she becomes\r
+ aware will be disclosed, in accordance with Section 6 of BCP 79.\r
+\r
+ Internet-Drafts are working documents of the Internet Engineering\r
+ Task Force (IETF), its areas, and its working groups. Note that\r
+ other groups may also distribute working documents as Internet-\r
+ Drafts.\r
+\r
+ Internet-Drafts are draft documents valid for a maximum of six\r
+ months and may be updated, replaced, or obsoleted by other documents\r
+ at any time. It is inappropriate to use Internet-Drafts as\r
+ reference material or to cite them other than as "work in progress".\r
+\r
+ The list of current Internet-Drafts can be accessed at\r
+ http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-\r
+ Draft Shadow Directories can be accessed at\r
+ http://www.ietf.org/shadow.html.\r
+\r
+ This Internet-Draft expires in August 2008.\r
+\r
+\r
+Copyright Notice\r
+\r
+ Copyright (C) The IETF Trust (2008).\r
+\r
+\r
+Abstract\r
+\r
+ Internet Message Access Protocol (IMAP) version 4rev1 has basic\r
+ support for non-ASCII characters in mailbox names and search\r
+ substrings. It also supports non-ASCII message headers and content\r
+ encoded as specified by Multipurpose Internet Mail Extensions\r
+ (MIME). This specification defines a collection of IMAP extensions\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 1]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ which improve international support including comparator negotiation\r
+ for search, sort and thread, language negotiation for international\r
+ error text, and translations for namespace prefixes.\r
+\r
+\r
+Table of Contents\r
+\r
+ 1. Conventions Used in this Document . . . . . . . . . . . . . . 2\r
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3\r
+ 3. LANGUAGE Extension . . . . . . . . . . . . . . . . . . . . . 3\r
+ 3.1 LANGUAGE Extension Requirements . . . . . . . . . . . . . . . 3\r
+ 3.2 LANGUAGE Command . . . . . . . . . . . . . . . . . . . . . . 4\r
+ 3.3 LANGUAGE Response . . . . . . . . . . . . . . . . . . . . . . 6\r
+ 3.4 TRANSLATION Extension to the NAMESPACE Response . . . . . . . 6\r
+ 3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6\r
+ 4. I18NLEVEL=1 and I18NLEVEL=2 Extensions . . . . . . . . . . . 7\r
+ 4.1 Introduction and Overview . . . . . . . . . . . . . . . . . . 8\r
+ 4.2 Requirements common to both I18NLEVEL=1 and I18NLEVEL=2 . . .\r
+ 4.3 I18NLEVEL=1 Extension Requirements . . . . . . . . . . . . . 8\r
+ 4.4 I18NLEVEL=2 Extension Requirements . . . . . . . . . . . . . 8\r
+ 4.5 Compatibility Notes\r
+ 4.6 Comparators and Charsets . . . . . . . . . . . . . . . . . . 9\r
+ 4.7 COMPARATOR Command . . . . . . . . . . . . . . . . . . . . . 9\r
+ 4.8 COMPARATOR Response . . . . . . . . . . . . . . . . . . . . . 10\r
+ 4.9 BADCOMPARATOR Response Code . . . . . . . . . . . . . . . . .\r
+ 4.10 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 10\r
+ 5. Other IMAP Internationalization Issues . . . . . . . . . . . 11\r
+ 5.1 UTF-8 Userids and Passwords . . . . . . . . . . . . . . . . . 11\r
+ 5.2 UTF-8 Mailbox Names . . . . . . . . . . . . . . . . . . . . . 11\r
+ 5.3 UTF-8 Domains, Addresses and Mail Headers . . . . . . . . . . 11\r
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12\r
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12\r
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12\r
+ 9. Relevant Standards for i18n IMAP Implementations . . . . . . 13\r
+ Normative References . . . . . . . . . . . . . . . . . . . . 13\r
+ Informative References . . . . . . . . . . . . . . . . . . . 14\r
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15\r
+ Intellectual Property and Copyright Statements . . . . . . . 16\r
+\r
+\r
+Conventions Used in This Document\r
+\r
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
+ document are to be interpreted as described in [RFC2119].\r
+\r
+ The formal syntax use the Augmented Backus-Naur Form (ABNF)\r
+ [RFC4234] notation including the core rules defined in Appendix A.\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 2]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ The UTF8-related productions are defined in [RFC3629].\r
+\r
+ In examples, "C:" and "S:" indicate lines sent by the client and\r
+ server respectively. If a single "C:" or "S:" label applies to\r
+ multiple lines, then the line breaks between those lines are for\r
+ editorial clarity only and are not part of the actual protocol\r
+ exchange.\r
+\r
+\r
+2. Introduction\r
+\r
+ This specification defines two IMAP4rev1 [RFC3501] extensions to\r
+ enhance international support. These extensions can be advertised\r
+ and implemented separately.\r
+\r
+ The LANGUAGE extension allows the client to request a suitable\r
+ language for protocol error messages and in combination with the\r
+ NAMESPACE extension [RFC2342] enables namespace translations.\r
+\r
+ The I18NLEVEL=2 extension allows the client to request a suitable\r
+ collation which will modify the behavior of the base specification's\r
+ SEARCH command as well as the SORT and THREAD extensions [SORT].\r
+ This leverages the collation registry [RFC4790].\r
+\r
+\r
+3. LANGUAGE Extension\r
+\r
+ IMAP allows server responses to include human-readable text that in\r
+ many cases needs to be presented to the user. But that text is\r
+ limited to US-ASCII by the IMAP specification [RFC3501] in order to\r
+ preserve backwards compatibility with deployed IMAP implementations.\r
+ This section specifies a way for an IMAP client to negotiate which\r
+ language the server should use when sending human-readable text.\r
+\r
+ The LANGUAGE extension only provides a mechanism for altering fixed\r
+ server strings such as response text and NAMESPACE folder names.\r
+ Assigning localized language aliases to shared mailboxes would be\r
+ done with a separate mechanism such as the proposed METADATA\r
+ extension (see [METADATA]).\r
+\r
+\r
+3.1 LANGUAGE Extension Requirements\r
+\r
+ IMAP servers that support this extension MUST list the keyword\r
+ LANGUAGE in their CAPABILITY response as well as in the greeting\r
+ CAPABILITY data.\r
+\r
+ A server that advertises this extension MUST use the language "i-\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 3]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ default" as described in [RFC2277] as its default language until\r
+ another supported language is negotiated by the client. A server\r
+ MUST include "i-default" as one of its supported languages.\r
+\r
+ Clients and servers that support this extension MUST also support\r
+ the NAMESPACE extension [RFC2342].\r
+\r
+ The LANGUAGE command is valid in all states. Clients are urged to\r
+ issue LANGUAGE before authentication, since some servers send\r
+ valuable user information as part of authentication (e.g. "password\r
+ is correct, but expired"). If a security layer (such as SASL or\r
+ TLS) is subsequently negotiated by the client, it MUST re-issue the\r
+ LANGUAGE command in order to make sure that no previous active\r
+ attack (if any) on LANGUAGE negotiation has effect on subsequent\r
+ error messages. (See Section 7 for a more detailed explanation of\r
+ the attack.)\r
+\r
+\r
+\r
+3.2 LANGUAGE Command\r
+\r
+ Arguments: Optional language range arguments.\r
+\r
+ Response: A possible LANGUAGE response (see section 3.3).\r
+ A possible NAMESPACE response (see section 3.4).\r
+\r
+ Result: OK - Command completed\r
+ NO - Could not complete command\r
+ BAD - arguments invalid\r
+\r
+ The LANGUAGE command requests that human-readable text emitted by\r
+ the server be localized to a language matching one of the language\r
+ range argument as described by section 2 of [RFC4647].\r
+\r
+ If the command succeeds, the server will return human-readable\r
+ responses in the first supported language specified. These\r
+ responses will be in UTF-8 [RFC3629]. The server MUST send a\r
+ LANGUAGE response specifying the language used, and the change takes\r
+ effect immediately after the LANGUAGE response.\r
+\r
+ If the command fails, the server continues to return human-readable\r
+ responses in the language it was previously using.\r
+\r
+ The special "default" language range argument indicates a request to\r
+ use a language designated as preferred by the server administrator.\r
+ The preferred language MAY vary based on the currently active user.\r
+\r
+ If a language range does not match a known language tag exactly but\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 4]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ does match a language by the rules of [RFC4647], the server MUST\r
+ send an untagged LANGUAGE response indicating the language selected.\r
+\r
+ If there aren't any arguments, the server SHOULD send an untagged\r
+ LANGUAGE response listing the languages it supports. If the server\r
+ is unable to enumerate the list of languages it supports it MAY\r
+ return a tagged NO response to the enumeration request.\r
+\r
+ < The server defaults to using English i-default responses until\r
+ the user explicitly changes the language. >\r
+\r
+ C: A001 LOGIN KAREN PASSWORD\r
+ S: A001 OK LOGIN completed\r
+\r
+ < Client requested MUL language, which no server supports. >\r
+\r
+ C: A002 LANGUAGE MUL\r
+ S: A002 NO Unsupported language MUL\r
+\r
+ < A LANGUAGE command with no arguments is a request to enumerate\r
+ the list of languages the server supports. >\r
+\r
+ C: A003 LANGUAGE\r
+ S: * LANGUAGE (EN DE IT i-default)\r
+ S: A003 OK Supported languages have been enumerated\r
+\r
+ C: B001 LANGUAGE\r
+ S: B001 NO Server is unable to enumerate supported languages\r
+\r
+ < Once the client changes the language, all responses will be in\r
+ that language starting after the LANGUAGE response. Note that\r
+ this includes the NAMESPACE response. Because RFCs are in US-\r
+ ASCII, this document uses an ASCII transcription rather than\r
+ UTF-8 text, e.g. ue in the word "ausgefuehrt" >\r
+\r
+ C: C001 LANGUAGE DE\r
+ S: * LANGUAGE (DE)\r
+ S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"\r
+ ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"\r
+ "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))\r
+ S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt\r
+\r
+ < If a server does not support the requested primary language,\r
+ responses will continue to be returned in the current language\r
+ the server is using. >\r
+\r
+ C: D001 LANGUAGE FR\r
+ S: D001 NO Diese Sprache ist nicht unterstuetzt\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 5]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ C: D002 LANGUAGE DE-IT\r
+ S: * LANGUAGE (DE-IT)\r
+ S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION"\r
+ ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"\r
+ "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))\r
+ S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt\r
+ C: D003 LANGUAGE "default"\r
+ S: * LANGUAGE (DE)\r
+ S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt\r
+\r
+ < Server does not speak French, but does speak English. User\r
+ speaks Canadian French and Canadian English. >\r
+\r
+ C: E001 LANGUAGE FR-CA EN-CA\r
+ S: * LANGUAGE (EN)\r
+ S: E001 OK Now speaking English\r
+\r
+\r
+\r
+3.3 LANGUAGE Response\r
+\r
+ Contents: A list of one or more language tags.\r
+\r
+ The LANGUAGE response occurs as a result of a LANGUAGE command. A\r
+ LANGUAGE response with a list containing a single language tag\r
+ indicates that the server is now using that language. A LANGUAGE\r
+ response with a list containing multiple language tags indicates the\r
+ server is communicating a list of available languages to the client,\r
+ and no change in the active language has been made.\r
+\r
+\r
+3.4 TRANSLATION Extension to the NAMESPACE Response\r
+\r
+ If localized representations of the namespace prefixes are available\r
+ in the selected language, the server SHOULD include these in the\r
+ TRANSLATION extension to the NAMESPACE response.\r
+\r
+ The TRANSLATION extension to the NAMESPACE response returns a single\r
+ string, containing the modified UTF-7 [RFC3501] encoded translation\r
+ of the namespace prefix. It is the responsibility of the client to\r
+ convert between the namespace prefix and the translation of the\r
+ namespace prefix when presenting mailbox names to the user.\r
+\r
+ In this example a server supports the IMAP4 NAMESPACE command. It\r
+ uses no prefix to the user's Personal Namespace, a prefix of "Other\r
+ Users" to its Other Users' Namespace and a prefix of "Public\r
+ Folders" to its only Shared Namespace. Since a client will often\r
+ display these prefixes to the user, the server includes a\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 6]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ translation of them that can be presented to the user.\r
+\r
+ C: A001 LANGUAGE DE-IT\r
+ S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"\r
+ ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"\r
+ "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))\r
+ S: A001 OK LANGUAGE-Befehl ausgefuehrt\r
+\r
+\r
+3.5 Formal Syntax\r
+\r
+ The following syntax specification inherits ABNF [RFC4234] rules\r
+ from IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the\r
+ Identifying Languages [RFC4646], UTF-8 [RFC3629] and Collected\r
+ Extensions to IMAP4 ABNF [RFC4466].\r
+\r
+ command-any =/ language-cmd\r
+ ; LANGUAGE command is valid in all states\r
+\r
+ language-cmd = "LANGUAGE" *(SP lang-range-quoted)\r
+\r
+ response-payload =/ language-data\r
+\r
+ language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP\r
+ lang-tag-quoted) ")"\r
+\r
+ namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")"\r
+ ; the string is encoded in Modified UTF-7.\r
+ ; this is a subset of the syntax permitted by\r
+ ; the Namespace-Response-Extension rule in [RFC4466]\r
+\r
+ lang-range-quoted = astring\r
+ ; Once any literal wrapper or quoting is removed, this\r
+ ; follows the language-range rule in [RFC4647]\r
+\r
+ lang-tag-quoted = astring\r
+ ; Once any literal wrapper or quoting is removed, this follows\r
+ ; the Language-Tag rule in [RFC4646]\r
+\r
+ resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR\r
+ *(UTF8-TEXT-CHAR / "[")\r
+ ; After the server is changed to a language other than\r
+ ; i-default, this resp-text rule replaces the resp-text\r
+ ; rule from [RFC3501].\r
+\r
+ UTF8-TEXT-CHAR = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4\r
+ ; UTF-8 excluding 7-bit control characters and "["\r
+\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 7]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+4. I18NLEVEL=1 and I18NLEVEL=2 Extensions\r
+\r
+\r
+4.1 Introduction and Overview\r
+\r
+ IMAP4rev1 [RFC3501] includes the SEARCH command which can be used to\r
+ locate messages matching criteria including human-readable text.\r
+ The SORT extension [SORT] to IMAP allows the client to ask the\r
+ server to determine the order of messages based on criteria\r
+ including human-readable text. These mechanisms require the ability\r
+ to support non-English search and sort functions.\r
+\r
+ Section 4 defines two IMAP extensions for internationalizing IMAP\r
+ SEARCH, SORT and THREAD [SORT] using the comparator framework\r
+ [RFC4790].\r
+\r
+ The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use\r
+ i;unicode-casemap comparator, as defined in [UCM]. See Sections 4.2\r
+ and 4.3 for more details.\r
+\r
+ The I18NLEVEL=2 extension is a superset of the I18NLEVEL=1\r
+ extension. It adds to I18NLEVEL=1 extension the ability to determine\r
+ the active comparator (see definition below) and negotiate use of\r
+ comparators using the COMPARATOR command. It also adds the\r
+ COMPARATOR response that indicates the active comparator and\r
+ possibly other available comparators. See Sections 4.2 and 4.4 for\r
+ more details.\r
+\r
+\r
+4.2 Requirements common to both I18NLEVEL=1 and I18NLEVEL=2\r
+\r
+ The term "default comparator" refers to the comparator which is used\r
+ by SEARCH and SORT absent any negotiation using the COMPARATOR (see\r
+ Section 4.7) command. The term "active comparator" refers to the\r
+ comparator which will be used within a session e.g. by SEARCH and\r
+ SORT. The COMPARATOR command is used to change the active\r
+ comparator.\r
+\r
+ The active comparator applies to the following SEARCH keys: "BCC",\r
+ "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER". If the\r
+ server also advertises the "SORT" extension, then the active\r
+ comparator applies to the following SORT keys: "CC", "FROM",\r
+ "SUBJECT" and "TO". If the server advertises THREAD=ORDEREDSUBJECT,\r
+ then the active comparator applies to the ORDEREDSUBJECT threading\r
+ algorithm. If the server advertises THREAD=REFERENCES, then the\r
+ active comparator applies to the subject field comparisons done by\r
+ REFERENCES threading algorithm. Future extensions may choose to\r
+ apply the active comparator to their SEARCH keys.\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 8]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ For SORT and THREAD, the pre-processing necessary to extract the\r
+ base subject text from a Subject header occurs prior to the\r
+ application of a comparator.\r
+\r
+ A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST\r
+ implement the i;unicode-casemap comparator, as defined in [UCM].\r
+\r
+ A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST\r
+ support UTF-8 as a SEARCH charset.\r
+\r
+\r
+4.3 I18NLEVEL=1 Extension Requirements\r
+\r
+ An IMAP server that satisfies all requirements specified in sections\r
+ 4.2 and 4.6 (and doesn't support/advertise any other I18NLEVEL=<n>\r
+ extension, where n > 1) MUST list the keyword I18NLEVEL=1 in its\r
+ CAPABILITY data once IMAP enters the authenticated state, and MAY\r
+ list that keyword in other states.\r
+\r
+\r
+\r
+4.4 I18NLEVEL=2 Extension Requirements\r
+\r
+ IMAP server that satisfies all requirements specified in sections\r
+ 4.2, 4.4, 4.6-4.10 (and doesn't support/advertise any other\r
+ I18NLEVEL=<n> extension, where n > 2) MUST list the keyword\r
+ I18NLEVEL=2 in its CAPABILITY data once IMAP enters the\r
+ authenticated state, and MAY list that keyword in other states.\r
+\r
+ A server that advertises this extension MUST implement the\r
+ i;unicode-casemap comparator, as defined in [UCM]. It MAY implement\r
+ other comparators from the IANA registry established by [RFC4790].\r
+ See also section 4.5 of this document.\r
+\r
+ A server that advertises this extension SHOULD use i;unicode-casemap\r
+ as the default comparator. (Note that i;unicode-casemap is the\r
+ default comparator for I18NLEVEL=1, but not necessarily the default\r
+ for I18NLEVEL=2.) The selection of the default comparator MAY be\r
+ adjustable by the server administrator, and MAY be sensitive to the\r
+ current user. Once the IMAP connection enters authenticated state,\r
+ the default comparator MUST remain static for the remainder of that\r
+ connection.\r
+\r
+ Note that since SEARCH uses the substring operation, IMAP servers\r
+ can only implement collations that offer the substring operation\r
+ (see [RFC4790 section 4.2.2). Since SORT uses ordering operation\r
+ (and by implication equality), IMAP servers which advertise the SORT\r
+ extension can only implement collations that offer all three\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 9]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ operations (see [RFC4790] sections 4.2.2-4).\r
+\r
+ If the active collation does not provide the operations needed by an\r
+ IMAP command, the server MUST respond with a tagged BAD.\r
+\r
+\r
+4.5 Compatibility Notes\r
+\r
+ Several server implementations deployed prior to the publication of\r
+ this specification comply with I18NLEVEL=1 (see section 4.3), but do\r
+ not advertise that. Other legacy servers use the i;ascii-casemap\r
+ (see [RFC4790]) comparator.\r
+\r
+ There is no good way for a client to know which comparator that a\r
+ legacy server uses. If the client has to assume the worst, it may\r
+ end up doing expensive local operations to obtain i;unicode-casemap\r
+ comparisons even though the server implements it.\r
+\r
+ Legacy server implementations which comply with I18NLEVEL=1 should\r
+ be updated to advertise I18NLEVEL=1. All server implementations\r
+ should eventually be updated to comply with the I18NLEVEL=2\r
+ extension.\r
+\r
+\r
+4.6 Comparators and Character Encodings\r
+\r
+ RFC 3501, section 6.4.4 says:\r
+\r
+ In all search keys that use strings, a message matches\r
+ the key if the string is a substring of the field. The\r
+ matching is case-insensitive.\r
+\r
+ When performing the SEARCH operation, the active comparator is\r
+ applied instead of the case-insensitive matching specified above.\r
+\r
+ An IMAP server which performs collation operations (e.g., as part of\r
+ commands such as SEARCH, SORT, THREAD) does so according to the\r
+ following procedure:\r
+\r
+ (a) MIME encoding (for example see [RFC2047] for headers and\r
+ [RFC2045] for body parts) MUST be removed in the texts being\r
+ collated.\r
+\r
+ If MIME encoding removal fails for a message (e.g., a body part\r
+ of the message has an unsupported Content-Transfer-Encoding,\r
+ uses characters not allowed by the Content-Transfer-Encoding,\r
+ etc.), the collation of this message is undefined by this\r
+ specification, and is handled in an implementation-dependent\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 10]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ manner.\r
+\r
+ (b) The decoded text from (a) MUST be converted to the charset\r
+ expected by the active comparator.\r
+\r
+ (c) For the substring operation:\r
+ If step (b) failed (e.g., the text is in an unknown charset,\r
+ contains a sequence which is not valid according in that\r
+ charset, etc.), the original decoded text from (a) (i.e.,\r
+ before the charset conversion attempt) is collated using the\r
+ i;octet comparator (see [RFC4790]).\r
+\r
+ If step (b) was successful, the converted text from (b) is\r
+ collated according to the active comparator.\r
+\r
+\r
+ For the ordering operation:\r
+\r
+ All strings that were successfully converted by step (b) are\r
+ separated from all strings that failed step (b). Strings in\r
+ each group are collated independently. All strings successfully\r
+ converted by step (b) are then validated by the active\r
+ comparator. Strings that pass validation are collated using the\r
+ active comparator. All strings that either fail step (b) or fail\r
+ the active collation's validity operation are collated (after\r
+ applying step (a)) using the i;octet comparator (see [RFC4790]).\r
+ The resulting sorted list is produced by appending all collated\r
+ "failed" strings after all strings collated using the active\r
+ comparator.\r
+\r
+\r
+ Example: The following example demonstrates ordering of 4\r
+ different strings using i;unicode-casemap [UCM] comparator.\r
+ Strings are represented using hexadecimal notation used by\r
+ ABNF [RFC4234].\r
+\r
+ (1) %xD0 %xC0 %xD0 %xBD %xD0 %xB4 %xD1 %x80 %xD0 %xB5\r
+ %xD0 %xB9 (labeled with charset=UTF-8)\r
+ (2) %xD1 %x81 %xD0 %x95 %xD0 %xA0 %xD0 %x93 %xD0 %x95\r
+ %xD0 %x99 (labeled with charset=UTF-8)\r
+ (3) %xD0 %x92 %xD0 %xB0 %xD1 %x81 %xD0 %xB8 %xD0 %xBB\r
+ %xD0 %xB8 %xFF %xB9 (labeled with charset=UTF-8)\r
+ (4) %xE1 %xCC %xC5 %xCB %xD3 %xC5 %xCA (labeled with\r
+ charset=KOI8-R)\r
+\r
+ Step (b) will convert string # 4 to the following\r
+ sequence of octets (in UTF-8):\r
+\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 11]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ %xD0 %x90 %xD0 %xBB %xD0 %xB5 %xD0 %xBA %xD1 %x81 %xD0\r
+ %xB5 %xD0 %xB9\r
+\r
+ and will reject strings (1) and (3), as they contain\r
+ octets not allowed in charset=UTF-8.\r
+ After that, using the i;unicode-casemap collation,\r
+ string (4) will collate before string (2). Using the\r
+ i;octet collation on the original strings, string (3)\r
+ will collate before string (1). So the final ordering\r
+ is as follows: (4) (2) (3) (1).\r
+\r
+ If the substring operation (e.g., IMAP SEARCH) of the active\r
+ comparator returns the "undefined" result (see section 4.2.3 of\r
+ [RFC4790]) for either the text specified in the SEARCH command or\r
+ the message text, then the operation is repeated on the result of\r
+ step (a) using the i;octet comparator.\r
+\r
+ The ordering operation (e.g., IMAP SORT and THREAD) SHOULD collate\r
+ the following together: strings encoded using unknown or invalid\r
+ character encodings, strings in unrecognized charsets, and invalid\r
+ input (as defined by the active collation).\r
+\r
+\r
+\r
+4.7 COMPARATOR Command\r
+\r
+ Arguments: Optional comparator order arguments.\r
+\r
+ Response: A possible COMPARATOR response (see Section 4.8).\r
+\r
+ Result: OK - Command completed\r
+ NO - No matching comparator found\r
+ BAD - arguments invalid\r
+\r
+ The COMPARATOR command is valid in authenticated and selected\r
+ states.\r
+\r
+ The COMPARATOR command is used to determine or change the active\r
+ comparator. When issued with no arguments, it results in a\r
+ COMPARATOR response indicating the currently active comparator.\r
+\r
+ When issued with one or more comparator argument, it changes the\r
+ active comparator as directed. (If more than one installed\r
+ comparator is matched by an argument, the first argument wins.) The\r
+ COMPARATOR response lists all matching comparators if more than one\r
+ matches the specified patterns.\r
+\r
+ The argument "default" refers to the server's default comparator.\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 12]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ Otherwise each argument is an collation specification as defined in\r
+ the Internet Application Protocol Comparator Registry [RFC4790].\r
+\r
+ < The client requests activating a Czech comparator if possible,\r
+ or else a generic international comparator which it considers\r
+ suitable for Czech. The server picks the first supported\r
+ comparator. >\r
+\r
+ C: A001 COMPARATOR "cz;*" i;basic\r
+ S: * COMPARATOR i;basic\r
+ S: A001 OK Will use i;basic for collation\r
+\r
+\r
+4.8 COMPARATOR Response\r
+\r
+ Contents: The active comparator.\r
+ An optional list of available matching comparators\r
+\r
+ The COMPARATOR response occurs as a result of a COMPARATOR command.\r
+ The first argument in the comparator response is the name of the\r
+ active comparator. The second argument is a list of comparators\r
+ which matched any of the arguments to the COMPARATOR command and is\r
+ present only if more than one match is found.\r
+\r
+\r
+4.9 BADCOMPARATOR response code\r
+\r
+ This response code SHOULD be returned as a result of server failing\r
+ an IMAP command (returning NO), when the server knows that none of\r
+ the specified comparators match the requested comparator(s).\r
+\r
+\r
+4.10 Formal Syntax\r
+\r
+ The following syntax specification inherits ABNF [RFC4234] rules\r
+ from IMAP4rev1 [RFC3501], and Internet Application Protocol\r
+ Comparator Registry [RFC4790].\r
+\r
+ command-auth =/ comparator-cmd\r
+\r
+ resp-text-code =/ "BADCOMPARATOR"\r
+\r
+ comparator-cmd = "COMPARATOR" *(SP comp-order-quoted)\r
+\r
+ response-payload =/ comparator-data\r
+\r
+ comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "("\r
+ comp-id-quoted *(SP comp-id-quoted) ")"]\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 13]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ comp-id-quoted = astring\r
+ ; Once any literal wrapper or quoting is removed, this\r
+ ; follows the collation-id rule from [RFC4790]\r
+\r
+ comp-order-quoted = astring\r
+ ; Once any literal wrapper or quoting is removed, this\r
+ ; follows the collation-order rule from [RFC4790]\r
+\r
+ comp-sel-quoted = astring\r
+ ; Once any literal wrapper or quoting is removed, this\r
+ ; follows the collation-selected rule from [RFC4790]\r
+\r
+\r
+5. Other IMAP Internationalization Issues\r
+\r
+ The following sections provide an overview of various other IMAP\r
+ internationalization issues. These issues are not resolved by this\r
+ specification, but could be resolved by other standards work, such\r
+ as that being done by the EAI group (see [IMAP-EAI]).\r
+\r
+\r
+5.1 Unicode Userids and Passwords\r
+\r
+ IMAP4rev1 currently restricts the userid and password fields of the\r
+ LOGIN command to US-ASCII. The "userid" and "password" fields of the\r
+ IMAP LOGIN command are restricted to US-ASCII only until a future\r
+ standards track RFC states otherwise. Servers are encouraged to\r
+ validate both fields to make sure they conform to the formal syntax\r
+ of UTF-8 and to reject the LOGIN command if that syntax is violated.\r
+ Servers MAY reject the use of any 8-bit in the "userid" or\r
+ "password" field.\r
+\r
+ When AUTHENTICATE is used, some servers may support userids and\r
+ passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows\r
+ that. However, such userids cannot be used as part of email\r
+ addresses.\r
+\r
+\r
+5.2 UTF-8 Mailbox Names\r
+\r
+ The modified UTF-7 mailbox naming convention described in section\r
+ 5.1.3 of RFC 3501 is best viewed as an transition from the status\r
+ quo in 1996 when modified UTF-7 was first specified. At that time,\r
+ there was widespread unofficial use of local character sets such as\r
+ ISO-8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant\r
+ non-interoperability.\r
+\r
+ The requirements in section 5.1 of RFC 3501 are very important if\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 14]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ we're ever going to be able to deploy UTF-8 mailbox names. Servers\r
+ are encouraged to enforce them.\r
+\r
+\r
+5.3 UTF-8 Domains, Addresses and Mail Headers\r
+\r
+ There is now an IETF standard for Internationalizing Domain Names in\r
+ Applications [RFC3490]. While IMAP clients are free to support this\r
+ standard, an argument can be made that it would be helpful to simple\r
+ clients if the IMAP server could perform this conversion (the same\r
+ argument would apply to MIME header encoding [RFC2047]). However,\r
+ it would be unwise to move forward with such work until the work in\r
+ progress to define the format of international email addresses is\r
+ complete.\r
+\r
+\r
+6. IANA Considerations\r
+\r
+ The IANA is requested to add LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2\r
+ to the IMAP4 Capabilities Registry. [Note to IANA:\r
+ http://www.iana.org/assignments/imap4-capabilities]\r
+\r
+\r
+7. Security Considerations\r
+\r
+ The LANGUAGE extension makes a new command available in "Not\r
+ Authenticated" state in IMAP. Some IMAP implementations run with\r
+ root privilege when the server is in "Not Authenticated" state and\r
+ do not revoke that privilege until after authentication is complete.\r
+ Such implementations are particularly vulnerable to buffer overflow\r
+ security errors at this stage and need to implement parsing of this\r
+ command with extra care.\r
+\r
+ A LANGUAGE command issued prior to activation of a security layer is\r
+ subject to an active attack which suppresses or modifies the\r
+ negotiation and thus makes STARTTLS or authentication error messages\r
+ more difficult to interpret. This is not a new attack as the error\r
+ messages themselves are subject to active attack. Clients MUST re-\r
+ issue the LANGUAGE command once a security layer is active, so this\r
+ does not impact subsequent protocol operations.\r
+\r
+ LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2 extensions use the UTF-8\r
+ charset, thus the security considerations for UTF-8 [RFC3629] are\r
+ relevent. However, neither uses UTF-8 for identifiers so the most\r
+ serious concerns do not apply.\r
+\r
+\r
+8. Acknowledgements\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 15]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ The LANGUAGE extension is based on a previous Internet draft by Mike\r
+ Gahrns, a substantial portion of the text in that section was\r
+ written by him. Many people have participated in discussions about\r
+ an IMAP Language extension in the various fora of the IETF and\r
+ Internet working groups, so any list of contributors is bound to be\r
+ incomplete. However, the authors would like to thank Andrew McCown\r
+ for early work on the original proposal, John Myers for suggestions\r
+ regarding the namespace issue, along with Jutta Degener, Mark\r
+ Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo, Martin Duerst,\r
+ Timo Sirainen, Ben Campbell and Magnus Nystrom for their many\r
+ suggestions that have been incorporated into this document.\r
+\r
+ Initial discussion of the I18NLEVEL=2 extension involved input from\r
+ Mark Crispin and other participants of the IMAP Extensions WG.\r
+\r
+\r
+9. Relevant Standards for i18n IMAP Implementations\r
+\r
+ This is a non-normative list of standards to consider when\r
+ implementing i18n aware IMAP software.\r
+\r
+ o The LANGUAGE and I18NLEVEL=2 extensions to IMAP (this\r
+ specification).\r
+ o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501.\r
+ o The Mailbox International Naming Convention in section 5.1.3 of\r
+ RFC 3501.\r
+ o MIME [RFC2045] for message bodies.\r
+ o MIME header encoding [RFC2047] for message headers.\r
+ o The IETF EAI working group.\r
+ o MIME Parameter Value and Encoded Word Extensions [RFC2231] for\r
+ filenames. Quality IMAP server implementations will\r
+ automatically combine multipart parameters when generating the\r
+ BODYSTRUCTURE. There is also some deployed non-standard use of\r
+ MIME header encoding inside double-quotes for filenames.\r
+ o IDNA [RFC3490] and punycode [RFC3492] for domain names\r
+ (currently only relevant to IMAP clients).\r
+ o The UTF-8 charset [RFC3629].\r
+ o The IETF policy on Character Sets and Languages [RFC2277].\r
+\r
+\r
+Normative References\r
+\r
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
+ Requirement Levels", BCP 14, RFC 2119, March 1997.\r
+\r
+ [RFC2277] Alvestrand, "IETF Policy on Character Sets and\r
+ Languages", BCP 18, RFC 2277, January 1998.\r
+\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 16]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ [RFC2342] Gahrns, Newman, "IMAP4 Namespace", RFC 2342, May 1998.\r
+\r
+ [RFC3501] Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION\r
+ 4rev1", RFC 3501, March 2003.\r
+\r
+ [RFC3629] Yergeau, "UTF-8, a transformation format of ISO 10646",\r
+ STD 63, RFC 3629, November 2003.\r
+\r
+ [RFC4234] Crocker, Overell, "Augmented BNF for Syntax\r
+ Specifications: ABNF", RFC 4234, Brandenburg\r
+ Internetworking, Demon Internet Ltd, October 2005.\r
+\r
+ [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security\r
+ Layer (SASL)", RFC 4422, June 2006.\r
+\r
+ [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF",\r
+ RFC 4466, Isode Ltd., April 2006.\r
+\r
+ [RFC4646] Philips, Davis, "Tags for Identifying Languages", BCP 47,\r
+ RFC 4646, September 2006.\r
+\r
+ [RFC4647] Philips, Davis, "Matching of Language Tags", BCP 47, RFC\r
+ 4647, September 2006.\r
+\r
+ [RFC4790] Newman, Duerst, Gulbrandsen, "Internet Application\r
+ Protocol Comparator Registry", RFC 4790, February 2007.\r
+\r
+ [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS\r
+ PROTOCOL - SORT AND THREAD EXTENSION", draft-ietf-\r
+ imapext-sort-19 (work in progress), November 2006.\r
+\r
+ [UCM] Crispin, "i;unicode-casemap - Simple Unicode Collation\r
+ Algorithm", RFC 5051, October 2007.\r
+\r
+ [RFC2045] Freed, Borenstein, "Multipurpose Internet Mail Extensions\r
+ (MIME) Part One: Format of Internet Message Bodies", RFC\r
+ 2045, November 1996.\r
+\r
+ [RFC2047] Moore, "MIME (Multipurpose Internet Mail Extensions) Part\r
+ Three: Message Header Extensions for Non-ASCII Text", RFC\r
+ 2047, November 1996.\r
+\r
+\r
+Informative References\r
+\r
+\r
+ [RFC2231] Freed, Moore, "MIME Parameter Value and Encoded Word\r
+ Extensions: Character Sets, Languages, and\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 17]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+ Continuations", RFC 2231, November 1997.\r
+\r
+ [RFC3490] Faltstrom, Hoffman, Costello, "Internationalizing Domain\r
+ Names in Applications (IDNA)", RFC 3490, March 2003.\r
+\r
+ [RFC3492] Costello, "Punycode: A Bootstring encoding of Unicode for\r
+ Internationalized Domain Names in Applications (IDNA)",\r
+ RFC 3492, March 2003.\r
+\r
+ [METADATA] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap-\r
+ annotatemore-12 (work in progress), December 2007.\r
+\r
+ [IMAP-EAI] Resnick, Newman, "IMAP Support for UTF-8", draft-ietf-\r
+ eai-imap-utf8 (work in progress), May 2006.\r
+\r
+\r
+\r
+Authors' Addresses\r
+\r
+ Chris Newman\r
+ Sun Microsystems\r
+ 3401 Centrelake Dr., Suite 410\r
+ Ontario, CA 91761\r
+ US\r
+\r
+ Email: chris.newman@sun.com\r
+\r
+\r
+ Arnt Gulbrandsen\r
+ Oryx Mail Systems GmbH\r
+ Schweppermannstr. 8\r
+ D-81671 Muenchen\r
+ Germany\r
+\r
+ Email: arnt@oryx.com\r
+\r
+ Fax: +49 89 4502 9758\r
+\r
+\r
+ Alexey Melnikov\r
+ Isode Limited\r
+ 5 Castle Business Village, 36 Station Road,\r
+ Hampton, Middlesex, TW12 2BX, UK\r
+\r
+ Email: Alexey.Melnikov@isode.com\r
+\r
+\r
+\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 18]\r
+\r
+\r
+\r
+\r
+\r
+Internet-draft February 2008\r
+\r
+\r
+Intellectual Property Statement\r
+\r
+ The IETF takes no position regarding the validity or scope of any\r
+ Intellectual Property Rights or other rights that might be claimed to\r
+ pertain to the implementation or use of the technology described in\r
+ this document or the extent to which any license under such rights\r
+ might or might not be available; nor does it represent that it has\r
+ made any independent effort to identify any such rights. Information\r
+ on the procedures with respect to rights in RFC documents can be found\r
+ in BCP 78 and BCP 79.\r
+\r
+ Copies of IPR disclosures made to the IETF Secretariat and any\r
+ assurances of licenses to be made available, or the result of an\r
+ attempt made to obtain a general license or permission for the use of\r
+ such proprietary rights by implementers or users of this specification\r
+ can be obtained from the IETF on-line IPR repository at\r
+ http://www.ietf.org/ipr.\r
+\r
+ The IETF invites any interested party to bring to its attention any\r
+ copyrights, patents or patent applications, or other proprietary\r
+ rights that may cover technology that may be required to implement\r
+ this standard. Please address the information to the IETF at\r
+ ietf-ipr@ietf.org.\r
+\r
+\r
+Full Copyright Statement\r
+\r
+ Copyright (C) The IETF Trust (2008). This document is subject to\r
+ the rights, licenses and restrictions contained in BCP 78, and\r
+ except as set forth therein, the authors retain all their rights.\r
+\r
+ This document and the information contained herein are provided on\r
+ an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE\r
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE\r
+ IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL\r
+ WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY\r
+ WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE\r
+ ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS\r
+ FOR A PARTICULAR PURPOSE.\r
+\r
+\r
+Acknowledgment\r
+\r
+ Funding for the RFC Editor function is currently provided by the\r
+ Internet Society.\r
+\r
+\r
+\r
+\r
+\r
+\r
+Newman & Co Expires August 2008 FF[Page 19]\r
+\r
+\r
projects / uw-imap / commitdiff