7Network Working Group C. Newman
8Request for Comments: 5255 Sun Microsystems
9Category: Standards Track A. Gulbrandsen
10 Oryx Mail Systems GmhH
16 Internet Message Access Protocol Internationalization
20 This document specifies an Internet standards track protocol for the
21 Internet community, and requests discussion and suggestions for
22 improvements. Please refer to the current edition of the "Internet
23 Official Protocol Standards" (STD 1) for the standardization state
24 and status of this protocol. Distribution of this memo is unlimited.
28 Internet Message Access Protocol (IMAP) version 4rev1 has basic
29 support for non-ASCII characters in mailbox names and search
30 substrings. It also supports non-ASCII message headers and content
31 encoded as specified by Multipurpose Internet Mail Extensions (MIME).
32 This specification defines a collection of IMAP extensions that
33 improve international support including language negotiation for
34 international error text, translations for namespace prefixes, and
35 comparator negotiation for search, sort, and thread.
58Newman, et al. Standards Track [Page 1]
60RFC 5255 IMAP Internationalization June 2008
65 1. Introduction ....................................................3
66 2. Conventions Used in This Document ...............................3
67 3. LANGUAGE Extension ..............................................3
68 3.1. LANGUAGE Extension Requirements ............................4
69 3.2. LANGUAGE Command ...........................................4
70 3.3. LANGUAGE Response ..........................................6
71 3.4. TRANSLATION Extension to the NAMESPACE Response ............7
72 3.5. Formal Syntax ..............................................8
73 4. I18NLEVEL=1 and I18NLEVEL=2 Extensions ..........................9
74 4.1. Introduction and Overview ..................................9
75 4.2. Requirements Common to Both I18NLEVEL=1 and I18NLEVEL=2 ....9
76 4.3. I18NLEVEL=1 Extension Requirements ........................10
77 4.4. I18NLEVEL=2 Extension Requirements ........................10
78 4.5. Compatibility Notes .......................................11
79 4.6. Comparators and Character Encodings .......................11
80 4.7. COMPARATOR Command ........................................13
81 4.8. COMPARATOR Response .......................................14
82 4.9. BADCOMPARATOR Response Code ...............................14
83 4.10. Formal Syntax ............................................14
84 5. Other IMAP Internationalization Issues .........................15
85 5.1. Unicode Userids and Passwords .............................15
86 5.2. UTF-8 Mailbox Names .......................................15
87 5.3. UTF-8 Domains, Addresses, and Mail Headers ................15
88 6. IANA Considerations ............................................16
89 7. Security Considerations ........................................16
90 8. Acknowledgements ...............................................16
91 9. Relevant Sources of Documents for Internationalized IMAP
92 Implementations ................................................17
93 10. Normative References ..........................................17
94 11. Informative References ........................................18
114Newman, et al. Standards Track [Page 2]
116RFC 5255 IMAP Internationalization June 2008
121 This specification defines two IMAP4rev1 [RFC3501] extensions to
122 enhance international support. These extensions can be advertised
123 and implemented separately.
125 The LANGUAGE extension allows the client to request a suitable
126 language for protocol error messages and in combination with the
127 NAMESPACE extension [RFC2342] enables namespace translations.
129 The I18NLEVEL=2 extension allows the client to request a suitable
130 collation that will modify the behavior of the base specification's
131 SEARCH command as well as the SORT and THREAD extensions [SORT].
132 This leverages the collation registry [RFC4790]. The I18NLEVEL=1
133 extension updates SEARCH/SORT/THREAD to use i;unicode-casemap
134 comparator, as defined in [UCM]. I18NLEVEL=1 is a simpler version of
135 I18NLEVEL=2 with no ability to select a different collation.
1372. Conventions Used in This Document
139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
141 document are to be interpreted as described in [RFC2119].
143 The formal syntax uses the Augmented Backus-Naur Form (ABNF)
144 [RFC5234] notation including the core rules defined in Appendix A.
146 The UTF-8-related productions are defined in [RFC3629].
148 In examples, "C:" and "S:" indicate lines sent by the client and
149 server respectively. If a single "C:" or "S:" label applies to
150 multiple lines, then the line breaks between those lines are for
151 editorial clarity only and are not part of the actual protocol
156 IMAP allows server responses to include human-readable text that in
157 many cases needs to be presented to the user. But that text is
158 limited to US-ASCII by the IMAP specification [RFC3501] in order to
159 preserve backwards compatibility with deployed IMAP implementations.
160 This section specifies a way for an IMAP client to negotiate which
161 language the server should use when sending human-readable text.
170Newman, et al. Standards Track [Page 3]
172RFC 5255 IMAP Internationalization June 2008
175 The LANGUAGE extension only provides a mechanism for altering fixed
176 server strings such as response text and NAMESPACE folder names.
177 Assigning localized language aliases to shared mailboxes would be
178 done with a separate mechanism such as the proposed METADATA
179 extension (see [METADATA]).
1813.1. LANGUAGE Extension Requirements
183 IMAP servers that support this extension MUST list the keyword
184 LANGUAGE in their CAPABILITY response as well as in the greeting
187 A server that advertises this extension MUST use the language
188 "i-default" as described in [RFC2277] as its default language until
189 another supported language is negotiated by the client. A server
190 MUST include "i-default" as one of its supported languages. IMAP
191 servers SHOULD NOT advertise the LANGUAGE extension if they discover
192 that they only support "i-default".
194 Clients and servers that support this extension MUST also support the
195 NAMESPACE extension [RFC2342].
197 The LANGUAGE command is valid in all states. Clients SHOULD issue
198 LANGUAGE before authentication, since some servers send valuable user
199 information as part of authentication (e.g., "password is correct,
200 but expired"). If a security layer (such as SASL or TLS) is
201 subsequently negotiated by the client, it MUST re-issue the LANGUAGE
202 command in order to make sure that no previous active attack (if any)
203 on LANGUAGE negotiation has effect on subsequent error messages.
204 (See Section 7 for a more detailed explanation of the attack.)
208 Arguments: Optional language range arguments.
210 Response: A possible LANGUAGE response (see Section 3.3).
211 A possible NAMESPACE response (see Section 3.4).
213 Result: OK - Command completed
214 NO - Could not complete command
215 BAD - Arguments invalid
217 The LANGUAGE command requests that human-readable text emitted by the
218 server be localized to a language matching one of the language range
219 argument as described by Section 2 of [RFC4647].
226Newman, et al. Standards Track [Page 4]
228RFC 5255 IMAP Internationalization June 2008
231 If the command succeeds, the server will return human-readable
232 responses in the first supported language specified. These responses
233 will be in UTF-8 [RFC3629]. The server MUST send a LANGUAGE response
234 specifying the language used, and the change takes effect immediately
235 after the LANGUAGE response.
237 If the command fails, the server continues to return human-readable
238 responses in the language it was previously using.
240 The special "default" language range argument indicates a request to
241 use a language designated as preferred by the server administrator.
242 The preferred language MAY vary based on the currently active user.
244 If a language range does not match a known language tag exactly but
245 does match a language by the rules of [RFC4647], the server MUST send
246 an untagged LANGUAGE response indicating the language selected.
248 If there aren't any arguments, the server SHOULD send an untagged
249 LANGUAGE response listing the languages it supports. If the server
250 is unable to enumerate the list of languages it supports it MAY
251 return a tagged NO response to the enumeration request. If, after
252 receiving a LANGUAGE request, the server discovers that it doesn't
253 support any language other than i-default, it MUST return a tagged NO
254 response to the enumeration request.
256 < The server defaults to using English i-default responses until
257 the user explicitly changes the language. >
259 C: A001 LOGIN KAREN PASSWORD
260 S: A001 OK LOGIN completed
262 < Client requested MUL language, which no server supports. >
265 S: A002 NO Unsupported language MUL
267 < A LANGUAGE command with no arguments is a request to enumerate
268 the list of languages the server supports. >
271 S: * LANGUAGE (EN DE IT i-default)
272 S: A003 OK Supported languages have been enumerated
275 S: B001 NO Server is unable to enumerate supported languages
282Newman, et al. Standards Track [Page 5]
284RFC 5255 IMAP Internationalization June 2008
287 < Once the client changes the language, all responses will be in
288 that language starting after the LANGUAGE response. Note that
289 this includes the NAMESPACE response. Because RFCs are in US-
290 ASCII, this document uses an ASCII transcription rather than
291 UTF-8 text, e.g., "ue" in the word "ausgefuehrt" >
295 S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
296 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
297 "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
298 S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
300 < If a server does not support the requested primary language,
301 responses will continue to be returned in the current language
302 the server is using. >
305 S: D001 NO Diese Sprache ist nicht unterstuetzt
306 C: D002 LANGUAGE DE-IT
307 S: * LANGUAGE (DE-IT)
308 S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION"
309 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
310 "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
311 S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
312 C: D003 LANGUAGE "default"
314 S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
316 < Server does not speak French, but does speak English. User
317 speaks Canadian French and Canadian English. >
319 C: E001 LANGUAGE FR-CA EN-CA
321 S: E001 OK Now speaking English
3233.3. LANGUAGE Response
325 Contents: A list of one or more language tags.
327 The LANGUAGE response occurs as a result of a LANGUAGE command. A
328 LANGUAGE response with a list containing a single language tag
329 indicates that the server is now using that language. A LANGUAGE
330 response with a list containing multiple language tags indicates the
331 server is communicating a list of available languages to the client,
332 and no change in the active language has been made.
338Newman, et al. Standards Track [Page 6]
340RFC 5255 IMAP Internationalization June 2008
3433.4. TRANSLATION Extension to the NAMESPACE Response
345 If localized representations of the namespace prefixes are available
346 in the selected language, the server SHOULD include these in the
347 TRANSLATION extension to the NAMESPACE response.
349 The TRANSLATION extension to the NAMESPACE response returns a single
350 string, containing the modified UTF-7 [RFC3501] encoded translation
351 of the namespace prefix. It is the responsibility of the client to
352 convert between the namespace prefix and the translation of the
353 namespace prefix when presenting mailbox names to the user.
355 In this example, a server supports the IMAP4 NAMESPACE command. It
356 uses no prefix to the user's Personal Namespace, a prefix of "Other
357 Users" to its Other Users' Namespace, and a prefix of "Public
358 Folders" to its only Shared Namespace. Since a client will often
359 display these prefixes to the user, the server includes a translation
360 of them that can be presented to the user.
362 C: A001 LANGUAGE DE-IT
363 S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
364 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
365 "TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
366 S: A001 OK LANGUAGE-Befehl ausgefuehrt
394Newman, et al. Standards Track [Page 7]
396RFC 5255 IMAP Internationalization June 2008
401 The following syntax specification inherits ABNF [RFC5234] rules from
402 IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the
403 Identifying Languages [RFC4646], UTF-8 [RFC3629], and Collected
404 Extensions to IMAP4 ABNF [RFC4466].
406 command-any =/ language-cmd
407 ; LANGUAGE command is valid in all states
409 language-cmd = "LANGUAGE" *(SP lang-range-quoted)
411 response-payload =/ language-data
413 language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP
416 namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")"
417 ; the string is encoded in Modified UTF-7.
418 ; this is a subset of the syntax permitted by
419 ; the Namespace-Response-Extension rule in [RFC4466]
421 lang-range-quoted = astring
422 ; Once any literal wrapper or quoting is removed, this
423 ; follows the language-range rule in [RFC4647]
425 lang-tag-quoted = astring
426 ; Once any literal wrapper or quoting is removed, this follows
427 ; the Language-Tag rule in [RFC4646]
429 resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR
430 *(UTF8-TEXT-CHAR / "[")
431 ; After the server is changed to a language other than
432 ; i-default, this resp-text rule replaces the resp-text
433 ; rule from [RFC3501].
435 UTF8-TEXT-CHAR = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4
436 ; UTF-8 excluding 7-bit control characters and "["
450Newman, et al. Standards Track [Page 8]
452RFC 5255 IMAP Internationalization June 2008
4554. I18NLEVEL=1 and I18NLEVEL=2 Extensions
4574.1. Introduction and Overview
459 IMAP4rev1 [RFC3501] includes the SEARCH command that can be used to
460 locate messages matching criteria including human-readable text. The
461 SORT extension [SORT] to IMAP allows the client to ask the server to
462 determine the order of messages based on criteria including human-
463 readable text. These mechanisms require the ability to support non-
464 English search and sort functions.
466 Section 4 defines two IMAP extensions for internationalizing IMAP
467 SEARCH, SORT, and THREAD [SORT] using the comparator framework
470 The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use
471 i;unicode-casemap comparator, as defined in [UCM]. See Sections 4.2
472 and 4.3 for more details.
474 The I18NLEVEL=2 extension is a superset of the I18NLEVEL=1 extension.
475 It adds to I18NLEVEL=1 extension the ability to determine the active
476 comparator (see definition below) and to negotiate use of comparators
477 using the COMPARATOR command. It also adds the COMPARATOR response
478 that indicates the active comparator and possibly other available
479 comparators. See Sections 4.2 and 4.4 for more details.
4814.2. Requirements Common to Both I18NLEVEL=1 and I18NLEVEL=2
483 The term "default comparator" refers to the comparator that is used
484 by SEARCH and SORT absent any negotiation using the COMPARATOR
485 command (see Section 4.7). The term "active comparator" refers to
486 the comparator which will be used within a session, e.g., by SEARCH
487 and SORT. The COMPARATOR command is used to change the active
490 The active comparator applies to the following SEARCH keys: "BCC",
491 "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO", and "HEADER". If the
492 server also advertises the "SORT" extension, then the active
493 comparator applies to the following SORT keys: "CC", "FROM",
494 "SUBJECT", and "TO". If the server advertises THREAD=ORDEREDSUBJECT,
495 then the active comparator applies to the ORDEREDSUBJECT threading
496 algorithm. If the server advertises THREAD=REFERENCES, then the
497 active comparator applies to the subject field comparisons done by
498 REFERENCES threading algorithm. Future extensions may choose to
499 apply the active comparator to their SEARCH keys.
506Newman, et al. Standards Track [Page 9]
508RFC 5255 IMAP Internationalization June 2008
511 For SORT and THREAD, the pre-processing necessary to extract the base
512 subject text from a Subject header occurs prior to the application of
515 A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST
516 implement the i;unicode-casemap comparator, as defined in [UCM].
518 A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST
519 support UTF-8 as a SEARCH charset.
5214.3. I18NLEVEL=1 Extension Requirements
523 An IMAP server that satisfies all requirements specified in Sections
524 4.2 and 4.6 (and that doesn't support/advertise any other
525 I18NLEVEL=<n> extension, where n > 1) MUST list the keyword
526 I18NLEVEL=1 in its CAPABILITY data once IMAP enters the authenticated
527 state, and MAY list that keyword in other states.
5294.4. I18NLEVEL=2 Extension Requirements
531 An IMAP server that satisfies all requirements specified in Sections
532 4.2, 4.4, and 4.6-4.10 (and that doesn't support/advertise any other
533 I18NLEVEL=<n> extension, where n > 2) MUST list the keyword
534 I18NLEVEL=2 in its CAPABILITY data once IMAP enters the authenticated
535 state, and MAY list that keyword in other states.
537 A server that advertises this extension MUST implement the
538 i;unicode-casemap comparator, as defined in [UCM]. It MAY implement
539 other comparators from the IANA registry established by [RFC4790].
540 See also Section 4.5 of this document.
542 A server that advertises this extension SHOULD use i;unicode-casemap
543 as the default comparator. (Note that i;unicode-casemap is the
544 default comparator for I18NLEVEL=1, but not necessarily the default
545 for I18NLEVEL=2.) The selection of the default comparator MAY be
546 adjustable by the server administrator, and MAY be sensitive to the
547 current user. Once the IMAP connection enters authenticated state,
548 the default comparator MUST remain static for the remainder of that
551 Note that since SEARCH uses the substring operation, IMAP servers can
552 only implement collations that offer the substring operation (see
553 [RFC4790], Section 4.2.2). Since SORT uses the ordering operation
554 (which in turn uses the equality operation), IMAP servers that
555 advertise the SORT extension can only implement collations that offer
556 all three operations (see [RFC4790], Sections 4.2.2-4.2.4).
562Newman, et al. Standards Track [Page 10]
564RFC 5255 IMAP Internationalization June 2008
567 If the active collation does not provide the operations needed by an
568 IMAP command, the server MUST respond with a tagged BAD.
5704.5. Compatibility Notes
572 Several server implementations deployed prior to the publication of
573 this specification comply with I18NLEVEL=1 (see Section 4.3), but do
574 not advertise that. Other legacy servers use the i;ascii-casemap
575 comparator (see [RFC4790]).
577 There is no good way for a client to know which comparator a legacy
578 server uses. If the client has to assume the worst, it may end up
579 doing expensive local operations to obtain i;unicode-casemap
580 comparisons even though the server implements it.
582 Legacy server implementations which comply with I18NLEVEL=1 should be
583 updated to advertise I18NLEVEL=1. All server implementations should
584 eventually be updated to comply with the I18NLEVEL=2 extension.
5864.6. Comparators and Character Encodings
588 RFC 3501, Section 6.4.4, says:
590 In all search keys that use strings, a message matches the key
591 if the string is a substring of the field. The matching is
594 When performing the SEARCH operation, the active comparator is
595 applied instead of the case-insensitive matching specified above.
597 An IMAP server which performs collation operations (e.g., as part of
598 commands such as SEARCH, SORT, and THREAD) does so according to the
601 (a) MIME encoding (for example, see [RFC2047] for headers and
602 [RFC2045] for body parts) MUST be removed in the texts being
605 If MIME encoding removal fails for a message (e.g., a body part
606 of the message has an unsupported Content-Transfer-Encoding, uses
607 characters not allowed by the Content-Transfer-Encoding, etc.),
608 the collation of this message is undefined by this specification,
609 and is handled in an implementation-dependent manner.
611 (b) The decoded text from (a) MUST be converted to the charset
612 expected by the active comparator.
618Newman, et al. Standards Track [Page 11]
620RFC 5255 IMAP Internationalization June 2008
623 (c) For the substring operation:
625 If step (b) failed (e.g., the text is in an unknown charset,
626 contains a sequence that is not valid according in that charset,
627 etc.), the original decoded text from (a) (i.e., before the
628 charset conversion attempt) is collated using the i;octet
629 comparator (see [RFC4790]).
631 If step (b) was successful, the converted text from (b) is
632 collated according to the active comparator.
634 For the ordering operation:
636 All strings that were successfully converted by step (b) are
637 separated from all strings that failed step (b). Strings in each
638 group are collated independently. All strings successfully
639 converted by step (b) are then validated by the active
640 comparator. Strings that pass validation are collated using the
641 active comparator. All strings that either fail step (b) or fail
642 the active collation's validity operation are collated (after
643 applying step (a)) using the i;octet comparator (see [RFC4790]).
644 The resulting sorted list is produced by appending all collated
645 "failed" strings after all strings collated using the active
648 Example: The following example demonstrates ordering of 4
649 different strings using the i;unicode-casemap [UCM] comparator.
650 Strings are represented using hexadecimal notation used by ABNF
653 (1) %xD0 %xC0 %xD0 %xBD %xD0 %xB4 %xD1 %x80 %xD0 %xB5
654 %xD0 %xB9 (labeled with charset=UTF-8)
655 (2) %xD1 %x81 %xD0 %x95 %xD0 %xA0 %xD0 %x93 %xD0 %x95
656 %xD0 %x99 (labeled with charset=UTF-8)
657 (3) %xD0 %x92 %xD0 %xB0 %xD1 %x81 %xD0 %xB8 %xD0 %xBB
658 %xD0 %xB8 %xFF %xB9 (labeled with charset=UTF-8)
659 (4) %xE1 %xCC %xC5 %xCB %xD3 %xC5 %xCA (labeled with
662 Step (b) will convert string (4) to the following sequence of
665 %xD0 %x90 %xD0 %xBB %xD0 %xB5 %xD0 %xBA %xD1 %x81 %xD0
668 and will reject strings (1) and (3), as they contain octets not
669 allowed in charset=UTF-8.
674Newman, et al. Standards Track [Page 12]
676RFC 5255 IMAP Internationalization June 2008
679 After that, using the i;unicode-casemap collation, string (4)
680 will collate before string (2). Using the i;octet collation on
681 the original strings, string (3) will collate before string (1).
682 So the final ordering is as follows: (4) (2) (3) (1).
684 If the substring operation (e.g., IMAP SEARCH) of the active
685 comparator returns the "undefined" result (see Section 4.2.3 of
686 [RFC4790]) for either the text specified in the SEARCH command or the
687 message text, then the operation is repeated on the result of step
688 (a) using the i;octet comparator.
690 The ordering operation (e.g., IMAP SORT and THREAD) SHOULD collate
691 the following together: strings encoded using unknown or invalid
692 character encodings, strings in unrecognized charsets, and invalid
693 input (as defined by the active collation).
6954.7. COMPARATOR Command
697 Arguments: Optional comparator order arguments.
699 Response: A possible COMPARATOR response (see Section 4.8).
701 Result: OK - Command completed
702 NO - No matching comparator found
703 BAD - Arguments invalid
705 The COMPARATOR command is valid in authenticated and selected states.
707 The COMPARATOR command is used to determine or change the active
708 comparator. When issued with no arguments, it results in a
709 COMPARATOR response indicating the currently active comparator.
711 When issued with one or more comparator arguments, it changes the
712 active comparator as directed. (If more than one installed
713 comparator is matched by an argument, the first argument wins.) The
714 COMPARATOR response lists all matching comparators if more than one
715 matches the specified patterns.
717 The argument "default" refers to the server's default comparator.
718 Otherwise, each argument is a collation specification as defined in
719 the Internet Application Protocol Comparator Registry [RFC4790].
721 < The client requests activating a Czech comparator if possible,
722 or else a generic international comparator which it considers
723 suitable for Czech. The server picks the first supported
730Newman, et al. Standards Track [Page 13]
732RFC 5255 IMAP Internationalization June 2008
735 C: A001 COMPARATOR "cz;*" i;basic
736 S: * COMPARATOR i;basic
737 S: A001 OK Will use i;basic for collation
7394.8. COMPARATOR Response
741 Contents: The active comparator. An optional list of available
744 The COMPARATOR response occurs as a result of a COMPARATOR command.
745 The first argument in the comparator response is the name of the
746 active comparator. The second argument is a list of comparators
747 which matched any of the arguments to the COMPARATOR command and is
748 present only if more than one match is found.
7504.9. BADCOMPARATOR Response Code
752 This response code SHOULD be returned as a result of server failing
753 an IMAP command (returning NO), when the server knows that none of
754 the specified comparators match the requested comparator(s).
758 The following syntax specification inherits ABNF [RFC5234] rules from
759 IMAP4rev1 [RFC3501] and the Internet Application Protocol Comparator
762 command-auth =/ comparator-cmd
764 resp-text-code =/ "BADCOMPARATOR"
766 comparator-cmd = "COMPARATOR" *(SP comp-order-quoted)
768 response-payload =/ comparator-data
770 comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "("
771 comp-id-quoted *(SP comp-id-quoted) ")"]
773 comp-id-quoted = astring
774 ; Once any literal wrapper or quoting is removed, this
775 ; follows the collation-id rule from [RFC4790]
777 comp-order-quoted = astring
778 ; Once any literal wrapper or quoting is removed, this
779 ; follows the collation-order rule from [RFC4790]
786Newman, et al. Standards Track [Page 14]
788RFC 5255 IMAP Internationalization June 2008
791 comp-sel-quoted = astring
792 ; Once any literal wrapper or quoting is removed, this
793 ; follows the collation-selected rule from [RFC4790]
7955. Other IMAP Internationalization Issues
797 The following sections provide an overview of various other IMAP
798 internationalization issues. These issues are not resolved by this
799 specification, but could be resolved by other standards work, such as
800 that being done by the EAI working group (see [IMAP-EAI]).
8025.1. Unicode Userids and Passwords
804 IMAP4rev1 currently restricts the userid and password fields of the
805 LOGIN command to US-ASCII. The "userid" and "password" fields of the
806 IMAP LOGIN command are restricted to US-ASCII only until a future
807 standards track RFC states otherwise. Servers are encouraged to
808 validate both fields to make sure they conform to the formal syntax
809 of UTF-8 and to reject the LOGIN command if that syntax is violated.
810 Servers MAY reject the LOGIN command if either the "userid" or
811 "password" field contains an octet with the highest bit set.
813 When AUTHENTICATE is used, some servers may support userids and
814 passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows
815 that. However, such userids cannot be used as part of email
8185.2. UTF-8 Mailbox Names
820 The modified UTF-7 mailbox naming convention described in Section
821 5.1.3 of RFC 3501 is best viewed as an transition from the status quo
822 in 1996 when modified UTF-7 was first specified. At that time, there
823 was widespread unofficial use of local character sets such as ISO-
824 8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant
825 non-interoperability.
827 The requirements in Section 5.1 of RFC 3501 are very important if
828 we're ever going to be able to deploy UTF-8 mailbox names. Servers
829 are encouraged to enforce them.
8315.3. UTF-8 Domains, Addresses, and Mail Headers
833 There is now an IETF standard for "Internationalizing Domain Names in
834 Applications (IDNA)" [RFC3490]. While IMAP clients are free to
835 support this standard, an argument can be made that it would be
836 helpful to simple clients if the IMAP server could perform this
837 conversion (the same argument would apply to MIME header encoding
842Newman, et al. Standards Track [Page 15]
844RFC 5255 IMAP Internationalization June 2008
847 [RFC2047]). However, it would be unwise to move forward with such
848 work until the work in progress to define the format of international
849 email addresses is complete.
8516. IANA Considerations
853 IANA added LANGUAGE, I18NLEVEL=1, and I18NLEVEL=2 to the IMAP4
854 Capabilities Registry.
8567. Security Considerations
858 The LANGUAGE extension makes a new command available in "Not
859 Authenticated" state in IMAP. Some IMAP implementations run with
860 root privilege when the server is in "Not Authenticated" state and do
861 not revoke that privilege until after authentication is complete.
862 Such implementations are particularly vulnerable to buffer overflow
863 security errors at this stage and need to implement parsing of this
864 command with extra care.
866 A LANGUAGE command issued prior to activation of a security layer is
867 subject to an active attack that suppresses or modifies the
868 negotiation, and thus makes STARTTLS or authentication error messages
869 more difficult to interpret. This is not a new attack as the error
870 messages themselves are subject to active attack. Clients MUST re-
871 issue the LANGUAGE command once a security layer is active, in order
872 to prevent this attack from impacting subsequent protocol operations.
874 LANGUAGE, I18NLEVEL=1, and I18NLEVEL=2 extensions use the UTF-8
875 charset; thus, the security considerations for UTF-8 [RFC3629] are
876 relevant. However, neither uses UTF-8 for identifiers, so the most
877 serious concerns do not apply.
881 The LANGUAGE extension is based on a previous document by Mike
882 Gahrns, a substantial portion of the text in that section was written
883 by him. Many people have participated in discussions about an IMAP
884 Language extension in the various fora of the IETF and Internet
885 working groups, so any list of contributors is bound to be
886 incomplete. However, the authors would like to thank Andrew McCown
887 for early work on the original proposal, John Myers for suggestions
888 regarding the namespace issue, along with Jutta Degener, Mark
889 Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo, Martin Duerst,
890 Timo Sirainen, Ben Campbell, and Magnus Nystrom for their many
891 suggestions that have been incorporated into this document.
893 Initial discussion of the I18NLEVEL=2 extension involved input from
894 Mark Crispin and other participants of the IMAP Extensions WG.
898Newman, et al. Standards Track [Page 16]
900RFC 5255 IMAP Internationalization June 2008
9039. Relevant Sources of Documents for Internationalized IMAP
906 This is a non-normative list of sources to consider when implementing
907 i18n-aware IMAP software.
909 o The LANGUAGE and I18NLEVEL=2 extensions to IMAP (this
912 o The 8-bit rules for mailbox naming in Section 5.1 of RFC 3501.
914 o The Mailbox International Naming Convention in Section 5.1.3 of
917 o MIME [RFC2045] for message bodies.
919 o MIME header encoding [RFC2047] for message headers.
921 o The IETF EAI working group.
923 o MIME Parameter Value and Encoded Word Extensions [RFC2231] for
924 filenames. Quality IMAP server implementations will
925 automatically combine multipart parameters when generating the
926 BODYSTRUCTURE. There is also some deployed non-standard use of
927 MIME header encoding inside double quotes for filenames.
929 o IDNA [RFC3490] and punycode [RFC3492] for domain names
930 (currently only relevant to IMAP clients).
932 o The UTF-8 charset [RFC3629].
934 o The IETF policy on Character Sets and Languages [RFC2277].
93610. Normative References
938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
939 Requirement Levels", BCP 14, RFC 2119, March 1997.
941 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
942 Languages", BCP 18, RFC 2277, January 1998.
944 [RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May
947 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
948 4rev1", RFC 3501, March 2003.
954Newman, et al. Standards Track [Page 17]
956RFC 5255 IMAP Internationalization June 2008
959 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
960 10646", STD 63, RFC 3629, November 2003.
962 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
963 Syntax Specifications: ABNF", STD 68, RFC 5234, January
966 [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
967 Authentication and Security Layer (SASL)", RFC 4422, June
970 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
971 ABNF", RFC 4466, April 2006.
973 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying
974 Languages", BCP 47, RFC 4646, September 2006.
976 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",
977 BCP 47, RFC 4647, September 2006.
979 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
980 Application Protocol Collation Registry", RFC 4790, March
983 [SORT] Crispin, M. and K. Murchison, "Internet Message Access
984 Protocol - SORT and THREAD Extensions", RFC 5256, June
987 [UCM] Crispin, M., "i;unicode-casemap - Simple Unicode Collation
988 Algorithm", RFC 5051, October 2007.
990 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
991 Extensions (MIME) Part One: Format of Internet Message
992 Bodies", RFC 2045, November 1996.
994 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
995 Part Three: Message Header Extensions for Non-ASCII Text",
996 RFC 2047, November 1996.
99811. Informative References
1000 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
1001 Word Extensions: Character Sets, Languages, and
1002 Continuations", RFC 2231, November 1997.
1004 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
1005 "Internationalizing Domain Names in Applications (IDNA)",
1006 RFC 3490, March 2003.
1010Newman, et al. Standards Track [Page 18]
1012RFC 5255 IMAP Internationalization June 2008
1015 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
1016 for Internationalized Domain Names in Applications
1017 (IDNA)", RFC 3492, March 2003.
1019 [METADATA] Daboo, C., "IMAP METADATA Extension", Work in Progress,
1022 [IMAP-EAI] Resnick, P., and C. Newman, "IMAP Support for UTF-8", Work
1023 in Progress, November 2007.
1029 3401 Centrelake Dr., Suite 410
1033 EMail: chris.newman@sun.com
1037 Oryx Mail Systems GmbH
1042 EMail: arnt@oryx.com
1043 Fax: +49 89 4502 9758
1048 5 Castle Business Village, 36 Station Road,
1049 Hampton, Middlesex, TW12 2BX, UK
1051 EMail: Alexey.Melnikov@isode.com
1066Newman, et al. Standards Track [Page 19]
1068RFC 5255 IMAP Internationalization June 2008
1071Full Copyright Statement
1073 Copyright (C) The IETF Trust (2008).
1075 This document is subject to the rights, licenses and restrictions
1076 contained in BCP 78, and except as set forth therein, the authors
1077 retain all their rights.
1079 This document and the information contained herein are provided on an
1080 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1081 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1082 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1083 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1084 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1085 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1087Intellectual Property
1089 The IETF takes no position regarding the validity or scope of any
1090 Intellectual Property Rights or other rights that might be claimed to
1091 pertain to the implementation or use of the technology described in
1092 this document or the extent to which any license under such rights
1093 might or might not be available; nor does it represent that it has
1094 made any independent effort to identify any such rights. Information
1095 on the procedures with respect to rights in RFC documents can be
1096 found in BCP 78 and BCP 79.
1098 Copies of IPR disclosures made to the IETF Secretariat and any
1099 assurances of licenses to be made available, or the result of an
1100 attempt made to obtain a general license or permission for the use of
1101 such proprietary rights by implementers or users of this
1102 specification can be obtained from the IETF on-line IPR repository at
1103 http://www.ietf.org/ipr.
1105 The IETF invites any interested party to bring to its attention any
1106 copyrights, patents or patent applications, or other proprietary
1107 rights that may cover technology that may be required to implement
1108 this standard. Please address the information to the IETF at
1122Newman, et al. Standards Track [Page 20]