idnits 2.17.1 draft-ietf-imapext-i18n-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 686. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 692. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2007) is 6161 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-18 == Outdated reference: A later version (-07) exists of draft-crispin-collation-unicasemap-04 -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-17) exists of draft-daboo-imap-annotatemore-10 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Chris Newman 2 Internet-Draft Sun Microsystems 3 Intended Status: Proposed Standard Arnt Gulbrandsen 4 Oryx Mail Systems GmhH 5 June 2007 7 Internet Message Access Protocol Internationalization 8 draft-ietf-imapext-i18n-11.txt 10 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 28 Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft expires in December 2007. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). 37 Abstract 39 Internet Message Access Protocol (IMAP) version 4rev1 has basic 40 support for non-ASCII characters in mailbox names and search 41 substrings. It also supports non-ASCII message headers and content 42 encoded as specified by Multipurpose Internet Mail Extensions 43 (MIME). This specification defines a collection of IMAP extensions 44 which improve international support including comparator negotiation 45 for search, sort and thread, language negotiation for international 46 error text, and translations for namespace prefixes. 48 Table of Contents 50 1. Conventions Used in this Document . . . . . . . . . . . . . . 2 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. LANGUAGE Extension . . . . . . . . . . . . . . . . . . . . . 3 53 3.1 LANGUAGE Extension Requirements . . . . . . . . . . . . . . . 3 54 3.2 LANGUAGE Command . . . . . . . . . . . . . . . . . . . . . . 4 55 3.3 LANGUAGE Response . . . . . . . . . . . . . . . . . . . . . . 6 56 3.4 TRANSLATION Extension to the NAMESPACE Response . . . . . . . 6 57 3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. COMPARATOR Extension . . . . . . . . . . . . . . . . . . . . 7 59 4.1 COMPARATOR Extension Requirements . . . . . . . . . . . . . . 8 60 4.2 Comparators and Charsets . . . . . . . . . . . . . . . . . . 9 61 4.3 COMPARATOR Command . . . . . . . . . . . . . . . . . . . . . 9 62 4.4 COMPARATOR Response . . . . . . . . . . . . . . . . . . . . . 10 63 4.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5. Other IMAP Internationalization Issues . . . . . . . . . . . 11 65 5.1 UTF-8 Userids and Passwords . . . . . . . . . . . . . . . . . 11 66 5.2 UTF-8 Mailbox Names . . . . . . . . . . . . . . . . . . . . . 11 67 5.3 UTF-8 Domains, Addresses and Mail Headers . . . . . . . . . . 11 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 71 9. Relevant Standards for i18n IMAP Implementations . . . . . . 13 72 Normative References . . . . . . . . . . . . . . . . . . . . 13 73 Informative References . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 75 Intellectual Property and Copyright Statements . . . . . . . 16 77 Conventions Used in This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 The formal syntax use the Augmented Backus-Naur Form (ABNF) 84 [RFC4234] notation including the core rules defined in Appendix A. 85 The UTF8-related productions are defined in [RFC3629]. 87 In examples, "C:" and "S:" indicate lines sent by the client and 88 server respectively. If a single "C:" or "S:" label applies to 89 multiple lines, then the line breaks between those lines are for 90 editorial clarity only and are not part of the actual protocol 91 exchange. 93 2. Introduction 95 This specification defines two IMAP4rev1 [RFC3501] extensions to 96 enhance international support. These extensions can be advertised 97 and implemented separately. 99 The LANGUAGE extension allows the client to request a suitable 100 language for protocol error messages and in combination with the 101 NAMESPACE extension [RFC2342] enables namespace translations. 103 The COMPARATOR extension allows the client to request a suitable 104 collation which will modify the behavior of the base specification's 105 SEARCH command as well as the SORT and THREAD extensions [SORT]. 106 This leverages the collation registry [RFC4790]. 108 3. LANGUAGE Extension 110 IMAP allows server responses to include human-readable text that in 111 many cases needs to be presented to the user. But that text is 112 limited to US-ASCII by the IMAP specification [RFC3501] in order to 113 preserve backwards compatibility with deployed IMAP implementations. 114 This section specifies a way for an IMAP client to negotiate which 115 language the server should use when sending human-readable text. 117 The LANGUAGE extension only provides a mechanism for altering fixed 118 server strings such as response text and NAMESPACE folder names. 119 Assigning localized language aliases to shared mailboxes would be 120 done with a separate mechanism such as the proposed METADATA 121 extension (see [METADATA]). 123 3.1 LANGUAGE Extension Requirements 125 IMAP servers that support this extension MUST list the keyword 126 LANGUAGE in their CAPABILITY response as well as in the greeting 127 CAPABILITY data. 129 A server that advertises this extension MUST use the language "i- 130 default" as described in [RFC2277] as its default language until 131 another supported language is negotiated by the client. A server 132 MUST include "i-default" as one of its supported languages. 134 Clients and servers that support this extension MUST also support 135 the NAMESPACE extension [RFC2342]. 137 The LANGUAGE command is valid in all states. Clients are urged to 138 issue LANGUAGE before authentication, since some servers send 139 valuable user information as part of authentication (e.g. "password 140 is correct, but expired"). 142 3.2 LANGUAGE Command 144 Arguments: Optional language range arguments. 146 Response: A possible LANGUAGE response (see section 3.3). 147 A possible NAMESPACE response (see section 3.4). 149 Result: OK - Command completed 150 NO - Could not complete command 151 BAD - arguments invalid 153 The LANGUAGE command requests that human-readable text emitted by 154 the server be localized to a language matching one of the language 155 range argument as described by section 2 of [RFC4647]. 157 If the command succeeds, the server will return human-readable 158 responses in the first supported language specified. These 159 responses will be in UTF-8 [RFC3629]. The server MUST send a 160 LANGUAGE response specifying the language used, and the change takes 161 effect immediately after the LANGUAGE response. 163 If the command fails, the server continues to return human-readable 164 responses in the language it was previously using. 166 The special "default" language range argument indicates a request to 167 use a language designated as preferred by the server administrator. 168 The preferred language MAY vary based on the currently active user. 170 If a language range does not match a known language tag exactly but 171 does match a language by the rules of [RFC4647], the server MUST 172 send an untagged LANGUAGE response indicating the language selected. 174 If there aren't any arguments, the server SHOULD send an untagged 175 LANGUAGE response listing the languages it supports. If the server 176 is unable to enumerate the list of languages it supports it MAY 177 return a tagged NO response to the enumeration request. 179 < The server defaults to using English i-default responses until 180 the user explicitly changes the language. > 182 C: A001 LOGIN KAREN PASSWORD 183 S: A001 OK LOGIN completed 185 < Client requested MUL language, which no server supports. > 186 C: A002 LANGUAGE MUL 187 S: A002 NO Unsupported language MUL 189 < A LANGUAGE command with no arguments is a request to enumerate 190 the list of languages the server supports. > 192 C: A003 LANGUAGE 193 S: * LANGUAGE (EN DE IT i-default) 194 S: A003 OK Supported languages have been enumerated 196 C: B001 LANGUAGE 197 S: B001 NO Server is unable to enumerate supported languages 199 < Once the client changes the language, all responses will be in 200 that language starting after the LANGUAGE response. Note that 201 this includes the NAMESPACE response. Because RFCs are in US- 202 ASCII, this document uses an ASCII transcription rather than 203 UTF-8 text, e.g. ue in the word "ausgefuehrt" > 205 C: C001 LANGUAGE DE 206 S: * LANGUAGE (DE) 207 S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION" 208 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 209 "TRANSLATION" ("Gemeinsame Mailboxen/"))) 210 S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 212 < If a server does not support the requested primary language, 213 responses will continue to be returned in the current language 214 the server is using. > 216 C: D001 LANGUAGE FR 217 S: D001 NO Diese Sprache ist nicht unterstuetzt 218 C: D002 LANGUAGE DE-IT 219 S: * LANGUAGE (DE-IT) 220 S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION" 221 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 222 "TRANSLATION" ("Gemeinsame Mailboxen/"))) 223 S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 224 C: D003 LANGUAGE "default" 225 S: * LANGUAGE (DE) 226 S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 228 < Server does not speak French, but does speak English. User 229 speaks Canadian French and Canadian English. > 231 C: E001 LANGUAGE FR-CA EN-CA 232 S: * LANGUAGE (EN) 233 S: E001 OK Now speaking English 235 3.3 LANGUAGE Response 237 Contents: A list of one or more language tags. 239 The LANGUAGE response occurs as a result of a LANGUAGE command. A 240 LANGUAGE response with a list containing a single language tag 241 indicates that the server is now using that language. A LANGUAGE 242 response with a list containing multiple language tags indicates the 243 server is communicating a list of available languages to the client, 244 and no change in the active language has been made. 246 3.4 TRANSLATION Extension to the NAMESPACE Response 248 If localized representations of the namespace prefixes are available 249 in the selected language, the server SHOULD include these in the 250 TRANSLATION extension to the NAMESPACE response. 252 The TRANSLATION extension to the NAMESPACE response returns a single 253 string, containing the modified UTF-7 [RFC3501] encoded translation 254 of the namespace prefix. It is the responsibility of the client to 255 convert between the namespace prefix and the translation of the 256 namespace prefix when presenting mailbox names to the user. 258 In this example a server supports the IMAP4 NAMESPACE command. It 259 uses no prefix to the user's Personal Namespace, a prefix of "Other 260 Users" to its Other Users' Namespace and a prefix of "Public 261 Folders" to its only Shared Namespace. Since a client will often 262 display these prefixes to the user, the server includes a 263 translation of them that can be presented to the user. 265 C: A001 LANGUAGE DE-IT 266 S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION" 267 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 268 "TRANSLATION" ("Gemeinsame Mailboxen/"))) 269 S: A001 OK LANGUAGE-Befehl ausgefuehrt 271 3.5 Formal Syntax 273 The following syntax specification inherits ABNF [RFC4234] rules 274 from IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the 275 Identifying Languages [RFC4646], UTF-8 [RFC3629] and Collected 276 Extensions to IMAP4 ABNF [RFC4466]. 278 command-any =/ language-cmd 279 ; LANGUAGE command is valid in all states 281 language-cmd = "LANGUAGE" *(SP lang-range-quoted) 283 response-payload =/ language-data / comparator-data 285 language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP lang-tag- 286 quoted) ")" 288 namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")" 289 ; the string is encoded in Modified UTF-7. 290 ; this is a subset of the syntax permitted by 291 ; the Namespace-Response-Extension rule in [RFC4466] 293 lang-range-quoted = astring 294 ; Once any literal wrapper or quoting is removed, this 295 ; follows the language-range rule in [RFC4647] 297 lang-tag-quoted = astring 298 ; Once any literal wrapper or quoting is removed, this follows 299 ; the Language-Tag rule in [RFC4646] 301 resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR 302 *(UTF8-TEXT-CHAR / "[") 303 ; After the server is changed to a language other than 304 ; i-default, this resp-text rule replaces the resp-text 305 ; rule from [RFC3501]. 307 UTF8-TEXT-CHAR = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4 308 ; UTF-8 excluding 7-bit control characters and "[" 310 4. COMPARATOR Extension 312 IMAP4rev1 [RFC3501] includes the SEARCH command which can be used to 313 locate messages matching criteria including human-readable text. 314 The SORT extension [SORT] to IMAP allows the client to ask the 315 server to determine the order of messages based on criteria 316 including human-readable text. These mechanisms require the ability 317 to support non-English search and sort functions. 319 This section defines an IMAP extension to negotiate use of 320 comparators [RFC4790] to internationalize IMAP SEARCH, SORT and 321 THREAD. The IMAP extension consists of a new command to determine 322 or change the active comparator and a new response to indicate the 323 active comparator and possibly other available comparators. 325 The term "default comparator" refers to the comparator which is used 326 by SEARCH and SORT absent any negotiation using the COMPARATOR 327 command. The term "active comparator" refers to the comparator 328 which will be used within a session e.g. by SEARCH and SORT. The 329 COMPARATOR command is used to change the active comparator. 331 The active comparator applies to the following SEARCH keys: "BCC", 332 "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER". If the 333 server also advertises the "SORT" extension, then the active 334 comparator applies to the following SORT keys: "CC", "FROM", 335 "SUBJECT" and "TO". If the server advertises THREAD=ORDEREDSUBJECT, 336 then the active comparator applies to the ORDEREDSUBJECT threading 337 algorithm. If the server advertises THREAD=REFERENCES, then the 338 active comparator applies to the subject field comparisons done by 339 REFERENCES threading algorithm. Future extensions may choose to 340 apply the active comparator to their SEARCH keys. 342 For SORT and THREAD, the pre-processing necessary to extract the 343 base subject text from a Subject header occurs prior to the 344 application of a comparator. 346 4.1 COMPARATOR Extension Requirements 348 IMAP servers that support this extension MUST list the keyword 349 COMPARATOR in their CAPABILITY data once IMAP enters authenticated 350 state, and MAY list that keyword in other states. 352 A server that advertises this extension MUST implement the i;ascii- 353 casemap and i;octet comparators, as defined in [RFC4790]. A server 354 intended to be deployed globally MUST implement the i;unicode- 355 casemap comparator, as defined in [UCM]. 357 A server that advertises this extension SHOULD use i;ascii-casemap 358 as the default comparator. The selection of the default comparator 359 MAY be adjustable by the server administrator, and MAY be sensitive 360 to the current user. Once the IMAP connection enters authenticated 361 state, the default comparator MUST remain static for the remainder 362 of that connection. 364 A server that advertises this extension MUST support UTF-8 as a 365 SEARCH charset. 367 The COMPARATOR command is valid in authenticated and selected 368 states. 370 Note that since SEARCH uses the substring operation, IMAP servers 371 can only implement collations that offer the substring operation 372 (see [RFC4790 section 4.2.2). Since SORT uses ordering operation 373 (and by implication equality), IMAP servers which advertise the SORT 374 extension can only implement collations that offer all three 375 operations (see [RFC4790] sections 4.2.2-4). 377 If the active collation does not provide the operations needed by an 378 IMAP command, the server MUST respond with a tagged BAD. 380 4.2 Comparators and Character Encodings 382 When SEARCH, SORT, THREAD or another command needs to perform 383 collation operations on messages (or on the command's arguments), 384 the server MUST remove MIME encoding (see [RFC2047] for headers and 385 [RFC2045] for bodyparts) and convert character encodings compatibly 386 before doing the collation operation. 388 Strings encoded using unknown character encodings should never match 389 when using the SEARCH command, and should sort together with invalid 390 input (as defined by the active collation) for the SORT and THREAD 391 commands. 393 4.3 COMPARATOR Command 395 Arguments: Optional comparator order arguments. 397 Response: A possible COMPARATOR response (see Section 4.4). 399 Result: OK - Command completed 400 NO - No matching comparator found 401 BAD - arguments invalid 403 The COMPARATOR command is used to determine or change the active 404 comparator. When issued with no arguments, it results in a 405 COMPARATOR response indicating the currently active comparator. 407 When issued with one or more comparator argument, it changes the 408 active comparator as directed. (If more than one installed 409 comparator is matched by an argument, the first argument wins.) The 410 COMPARATOR response lists all matching comparators if more than one 411 matches the specified patterns. 413 The argument "default" refers to the server's default comparator. 414 Otherwise each argument is an collation specification as defined in 415 the Internet Application Protocol Comparator Registry [RFC4790]. 417 < The client requests activating a Czech comparator if possible, 418 or else a generic international comparator which it considers 419 suitable for Czech. The server picks the first supported 420 comparator. > 422 C: A001 COMPARATOR "cz;*" i;basic 423 S: * COMPARATOR i;basic 424 S: A001 OK Will use i;basic for collation 426 4.4 COMPARATOR Response 428 Contents: The active comparator. 429 An optional list of available matching comparators 431 The COMPARATOR response occurs as a result of a COMPARATOR command. 432 The first argument in the comparator response is the name of the 433 active comparator. The second argument is a list of comparators 434 which matched any of the arguments to the COMPARATOR command and is 435 present only if more than one match is found. 437 4.5 Formal Syntax 439 The following syntax specification inherits ABNF [RFC4234] rules 440 from IMAP4rev1 [RFC3501], and Internet Application Protocol 441 Comparator Registry [RFC4790]. 443 command-auth =/ comparator-cmd 445 resp-text-code =/ "BADCOMPARATOR" / "BADMATCH" 447 comparator-cmd = "COMPARATOR" *(SP comp-order-quoted) 449 comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "(" 450 comp-id-quoted *(SP comp-id-quoted) ")"] 452 comp-id-quoted = astring 453 ; Once any literal wrapper or quoting is removed, this 454 ; follows the collation-id rule from [RFC4790] 456 comp-order-quoted = astring 457 ; Once any literal wrapper or quoting is removed, this 458 ; follows the collation-order rule from [RFC4790] 460 comp-sel-quoted = astring 461 ; Once any literal wrapper or quoting is removed, this 462 ; follows the collation-selected rule from [RFC4790] 464 5. Other IMAP Internationalization Issues 466 The following sections provide an overview of various other IMAP 467 internationalization issues. These issues are not resolved by this 468 specification, but could be resolved by other standards work, such 469 as that being done by the EAI group (see [IMAP-EAI]). 471 5.1 Unicode Userids and Passwords 473 IMAP4rev1 presently restricts the userid and password fields of the 474 LOGIN command to US-ASCII. The "userid" and "password" fields of the 475 IMAP LOGIN command are restricted to US-ASCII only until a future 476 standards track RFC states otherwise. Servers are encouraged to 477 validate both fields to make sure they conform to the formal syntax 478 of UTF-8 and to reject the LOGIN command if that syntax is violated. 479 Servers MAY reject the use of any 8-bit in the "userid" or 480 "password" field. 482 When AUTHENTICATE is used, some servers may support userids and 483 passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows 484 that. However, such userids cannot be used as part of email 485 addresses. 487 5.2 UTF-8 Mailbox Names 489 The modified UTF-7 mailbox naming convention described in section 490 5.1.3 of RFC 3501 is best viewed as an transition from the status 491 quo in 1996 when modified UTF-7 was first specified. At that time, 492 there was widespread unofficial use of local character sets such as 493 ISO-8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant 494 non-interoperability. 496 The requirements in section 5.1 of RFC 3501 are very important if 497 we're ever going to be able to deploy UTF-8 mailbox names. Servers 498 are encouraged to enforce them. 500 5.3 UTF-8 Domains, Addresses and Mail Headers 502 There is now an IETF standard for Internationalizing Domain Names in 503 Applications [RFC3490]. While IMAP clients are free to support this 504 standard, an argument can be made that it would be helpful to simple 505 clients if the IMAP server could perform this conversion (the same 506 argument would apply to MIME header encoding [RFC2047]). However, 507 it would be unwise to move forward with such work until the work in 508 progress to define the format of international email addresses is 509 complete. 511 6. IANA Considerations 513 The IANA is requested to add LANGUAGE and COMPARATOR to the IMAP4 514 Capabilities Registry. [Note to IANA: 515 http://www.iana.org/assignments/imap4-capabilities] 517 7. Security Considerations 519 The LANGUAGE extension makes a new command available in "Not 520 Authenticated" state in IMAP. Some IMAP implementations run with 521 root privilege when the server is in "Not Authenticated" state and 522 do not revoke that privilege until after authentication is complete. 523 Such implementations are particularly vulnerable to buffer overflow 524 security errors at this stage and need to implement parsing of this 525 command with extra care. 527 A LANGUAGE command issued prior to activation of a security layer is 528 subject to an active attack which suppresses or modifies the 529 negotiation and thus makes STARTTLS or authentication error messages 530 more difficult to interpret. This is not a new attack as the error 531 messages themselves are subject to active attack. Clients MUST re- 532 issue the LANGUAGE command once a security layer is active, so this 533 does not impact subsequent protocol operations. 535 Both the LANGUAGE and COMPARATOR extensions use the UTF-8 charset, 536 thus the security considerations for UTF-8 [RFC3629] are relevent. 537 However, neither uses UTF-8 for identifiers so the most serious 538 concerns do not apply. 540 8. Acknowledgements 542 The LANGUAGE extension is based on a previous Internet draft by Mike 543 Gahrns and Alexey Melnikov, a substantial portion of the text in 544 that section was written by them. Many people have participated in 545 discussions about an IMAP Language extension in the various fora of 546 the IETF and Internet working groups, so any list of contributors is 547 bound to be incomplete. However, the authors would like to thank 548 Andrew McCown for early work on the original proposal, John Myers 549 for suggestions regarding the namespace issue, along with Jutta 550 Degener, Mark Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo 551 and Martin Duerst for their many suggestions that have been 552 incorporated into this document. 554 Initial discussion of the COMPARATOR extension involved input from 555 Mark Crispin and other participants of the IMAP Extensions WG. 557 9. Relevant Standards for i18n IMAP Implementations 559 This is a non-normative list of standards to consider when 560 implementing i18n aware IMAP software. 562 o The LANGUAGE and COMPARATOR extensions to IMAP (this 563 specification). 564 o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501. 565 o The Mailbox International Naming Convention in section 5.1.3 of 566 RFC 3501. 567 o MIME [RFC2045] for message bodies. 568 o MIME header encoding [RFC2047] for message headers. 569 o The IETF EAI working group. 570 o MIME Parameter Value and Encoded Word Extensions [RFC2231] for 571 filenames. Quality IMAP server implementations will 572 automatically combine multipart parameters when generating the 573 BODYSTRUCTURE. There is also some deployed non-standard use of 574 MIME header encoding inside double-quotes for filenames. 575 o IDNA [RFC3490] and punycode [RFC3492] for domain names 576 (presently only relevant to IMAP clients). 577 o The UTF-8 charset [RFC3629]. 578 o The IETF policy on Character Sets and Languages [RFC2277]. 580 Normative References 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997. 585 [RFC2277] Alvestrand, "IETF Policy on Character Sets and 586 Languages", BCP 18, RFC 2277, January 1998. 588 [RFC2342] Gahrns, Newman, "IMAP4 Namespace", RFC 2342, May 1998. 590 [RFC3501] Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 591 4rev1", RFC 3501, March 2003. 593 [RFC3629] Yergeau, "UTF-8, a transformation format of ISO 10646", 594 STD 63, RFC 3629, November 2003. 596 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 597 Specifications: ABNF", RFC 4234, Brandenburg 598 Internetworking, Demon Internet Ltd, October 2005. 600 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 601 Layer (SASL)", RFC 4422, June 2006. 603 [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", 604 RFC 4466, Isode Ltd., April 2006. 606 [RFC4646] Philips, Davis, "Tags for Identifying Languages", BCP 47, 607 RFC 4646, September 2006. 609 [RFC4647] Philips, Davis, "Matching of Language Tags", BCP 47, RFC 610 4647, September 2006. 612 [RFC4790] Newman, Duerst, Gulbrandsen, "Internet Application 613 Protocol Comparator Registry", RFC 4790, February 2007 615 [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 616 PROTOCOL - SORT AND THREAD EXTENSION", draft-ietf- 617 imapext-sort-18 (work in progress), November 2006. 619 [UCM] Crispin, "i;unicode-casemap - Simple Unicode Collation 620 Algorithm", draft-crispin-collation-unicasemap-04.txt, 621 May 2007. 623 Informative References 625 [RFC2045] Freed, Borenstein, "Multipurpose Internet Mail Extensions 626 (MIME) Part One: Format of Internet Message Bodies", RFC 627 2045, November 1996. 629 [RFC2047] Moore, "MIME (Multipurpose Internet Mail Extensions) Part 630 Three: Message Header Extensions for Non-ASCII Text", RFC 631 2047, November 1996. 633 [RFC2231] Freed, Moore, "MIME Parameter Value and Encoded Word 634 Extensions: Character Sets, Languages, and 635 Continuations", RFC 2231, November 1997. 637 [RFC3490] Faltstrom, Hoffman, Costello, "Internationalizing Domain 638 Names in Applications (IDNA)", RFC 3490, March 2003. 640 [RFC3492] Costello, "Punycode: A Bootstring encoding of Unicode for 641 Internationalized Domain Names in Applications (IDNA)", 642 RFC 3492, March 2003. 644 [METADATA] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap- 645 annotatemore-10 (work in progress), November 2006. 647 [IMAP-EAI] Resnick, Newman, "IMAP Support for UTF-8", draft-ietf- 648 eai-imap-utf8 (work in progress), May 2006. 650 Authors' Addresses 652 Chris Newman 653 Sun Microsystems 654 3401 Centrelake Dr., Suite 410 655 Ontario, CA 91761 656 US 658 Email: chris.newman@sun.com 660 Arnt Gulbrandsen 661 Oryx Mail Systems GmbH 662 Schweppermannstr. 8 663 D-81671 Muenchen 664 Germany 666 Email: arnt@oryx.com 668 Fax: +49 89 4502 9758 670 Intellectual Property Statement 672 The IETF takes no position regarding the validity or scope of any 673 Intellectual Property Rights or other rights that might be claimed 674 to pertain to the implementation or use of the technology described 675 in this document or the extent to which any license under such 676 rights might or might not be available; nor does it represent that 677 it has made any independent effort to identify any such rights. 678 Information on the procedures with respect to rights in RFC 679 documents can be found in BCP 78 and BCP 79. 681 Copies of IPR disclosures made to the IETF Secretariat and any 682 assurances of licenses to be made available, or the result of an 683 attempt made to obtain a general license or permission for the use 684 of such proprietary rights by implementers or users of this 685 specification can be obtained from the IETF on-line IPR repository 686 at http://www.ietf.org/ipr. 688 The IETF invites any interested party to bring to its attention any 689 copyrights, patents or patent applications, or other proprietary 690 rights that may cover technology that may be required to implement 691 this standard. Please address the information to the IETF at ietf- 692 ipr@ietf.org. 694 Full Copyright Statement 696 Copyright (C) The IETF Trust (2007). This document is subject to 697 the rights, licenses and restrictions contained in BCP 78, and 698 except as set forth therein, the authors retain all their rights. 700 This document and the information contained herein are provided on 701 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 702 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 703 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 704 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 705 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 706 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 707 FOR A PARTICULAR PURPOSE. 709 Acknowledgment 711 Funding for the RFC Editor function is currently provided by the 712 Internet Society.