idnits 2.17.1 draft-ietf-imapext-i18n-10.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 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 687. 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 (March 2007) is 6214 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) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-17 == Outdated reference: A later version (-17) exists of draft-daboo-imap-annotatemore-10 == Outdated reference: A later version (-07) exists of draft-crispin-collation-unicasemap-00 -- No information found for draft-ietf-iea-imap-utf8 - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 9 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 March 2007 7 Internet Message Access Protocol Internationalization 8 draft-ietf-imapext-i18n-10.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 September 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 8 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 comparator which will modify the behavior of the base 105 specification's SEARCH command as well as the SORT and THREAD 106 extensions [SORT]. This leverages the comparator registry 107 [RFC4790]. 109 3. LANGUAGE Extension 111 IMAP allows server responses to include human-readable text that in 112 many cases needs to be presented to the user. But that text is 113 limited to US-ASCII by the IMAP specification [RFC3501] in order to 114 preserve backwards compatibility with deployed IMAP implementations. 115 This section specifies a way for an IMAP client to negotiate which 116 language the server should use when sending human-readable text. 118 The LANGUAGE extension only provides a mechanism for altering fixed 119 server strings such as response text and NAMESPACE folder names. 120 Assigning localized language aliases to shared mailboxes would be 121 done with a separate mechanism such as the proposed METADATA 122 extension (see [METADATA]). 124 3.1 LANGUAGE Extension Requirements 126 IMAP servers that support this extension MUST list the keyword 127 LANGUAGE in their CAPABILITY response as well as in the greeting 128 CAPABILITY data. 130 A server that advertises this extension MUST use the language "i- 131 default" as described in [RFC2277] as its default language until 132 another supported language is negotiated by the client. A server 133 MUST include "i-default" as one of its supported languages. 135 Clients and servers that support this extension MUST also support 136 the NAMESPACE extension [RFC2342]. 138 The LANGUAGE command is valid in all states. 140 3.2 LANGUAGE Command 142 Arguments: Optional language range arguments. 144 Response: A possible LANGUAGE response (see section 3.3). 145 A possible NAMESPACE response (see section 3.4). 147 Result: OK - Command completed 148 NO - Could not complete command 149 BAD - arguments invalid 151 The LANGUAGE command requests that human-readable text emitted by 152 the server be localized to a language matching one of the language 153 range argument as described by section 2.5 of RFC 3066. 155 If the command succeeds, the server will return human-readable 156 responses in the first supported language specified. These 157 responses will be in UTF-8 [RFC3629]. The server MUST send a 158 LANGUAGE response specifying the language used, and the change takes 159 effect immediately after the LANGUAGE response. 161 If the command fails, the server continues to return human-readable 162 responses in the language it was previously using. 164 The special "*" language range argument indicates a request to use a 165 language designated as preferred by the server administrator. The 166 preferred language MAY vary based on the currently active user. 168 If a language range does not match a known language tag exactly but 169 does match a language by the rules of [RFC4647], the server MUST 170 send an untagged LANGUAGE response indicating the language selected. 172 If there aren't any arguments, the server SHOULD send an untagged 173 LANGUAGE response listing the languages it supports. If the server 174 is unable to enumerate the list of languages it supports it MAY 175 return a tagged NO response to the enumeration request. 177 < The server defaults to using English i-default responses until 178 the user explicitly changes the language. > 180 C: A001 LOGIN KAREN PASSWORD 181 S: A001 OK LOGIN completed 183 < Client requested MUL language, which no server supports. > 185 C: A002 LANGUAGE MUL 186 S: A002 NO Unsupported language MUL 187 < A LANGUAGE command with no arguments is a request to enumerate 188 the list of languages the server supports. > 190 C: A003 LANGUAGE 191 S: * LANGUAGE (EN DE IT i-default) 192 S: A003 OK Supported languages have been enumerated 194 C: B001 LANGUAGE 195 S: B001 NO Server is unable to enumerate supported languages 197 < Once the client changes the language, all responses will be in 198 that language starting after the LANGUAGE response. Note that 199 this includes the NAMESPACE response. Because RFCs are in US- 200 ASCII, this document uses an ASCII transcription rather than 201 UTF-8 text, e.g. ue in the word "ausgefuehrt" > 203 C: C001 LANGUAGE DE 204 S: * LANGUAGE (DE) 205 S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION" 206 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 207 "TRANSLATION" ("Gemeinsame Mailboxen/"))) 208 S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 210 < If a server does not support the requested primary language, 211 responses will continue to be returned in the current language 212 the server is using. > 214 C: D001 LANGUAGE FR 215 S: D001 NO Diese Sprache ist nicht unterstuetzt 216 C: D002 LANGUAGE DE-IT 217 S: * LANGUAGE (DE-IT) 218 S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION" 219 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 220 "TRANSLATION" ("Gemeinsame Mailboxen/"))) 221 S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 222 C: D003 LANGUAGE "*" 223 S: * LANGUAGE (DE) 224 S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 226 < Server does not speak French, but does speak English. User 227 speaks Canadian French and Canadian English. > 229 C: E001 LANGUAGE FR-CA EN-CA 230 S: * LANGUAGE (EN) 231 S: E001 OK Now speaking English 233 3.3 LANGUAGE Response 235 Contents: A list of one or more language tags. 237 The LANGUAGE response occurs as a result of a LANGUAGE command. A 238 LANGUAGE response with a list containing a single language tag 239 indicates that the server is now using that language. A LANGUAGE 240 response with a list containing multiple language tags indicates the 241 server is communicating a list of available languages to the client, 242 and no change in the active language has been made. 244 3.4 TRANSLATION Extension to the NAMESPACE Response 246 If localized representations of the namespace prefixes are available 247 in the selected language, the server SHOULD include these in the 248 TRANSLATION extension to the NAMESPACE response. 250 The TRANSLATION extension to the NAMESPACE response returns a single 251 string, containing the modified UTF-7 [RFC3501] encoded translation 252 of the namespace prefix. It is the responsibility of the client to 253 convert between the namespace prefix and the translation of the 254 namespace prefix when presenting mailbox names to the user. 256 In this example a server supports the IMAP4 NAMESPACE command. It 257 uses no prefix to the user's Personal Namespace, a prefix of "Other 258 Users" to its Other Users' Namespace and a prefix of "Public 259 Folders" to its only Shared Namespace. Since a client will often 260 display these prefixes to the user, the server includes a 261 translation of them that can be presented to the user. 263 C: A001 LANGUAGE DE-IT 264 S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION" 265 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 266 "TRANSLATION" ("Gemeinsame Mailboxen/"))) 267 S: A001 OK LANGUAGE-Befehl ausgefuehrt 269 3.5 Formal Syntax 271 The following syntax specification inherits ABNF [RFC4234] rules 272 from IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the 273 Identifying Languages [RFC4646], and UTF-8 [RFC3629]. 275 command-any =/ language-cmd 276 ; LANGUAGE command is valid in all states 278 language-cmd = "LANGUAGE" *(SP lang-range-quoted) 279 response-payload =/ language-data / comparator-data 281 language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP lang-tag- 282 quoted) ")" 284 namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")" 285 ; the string is encoded in Modified UTF-7. 286 ; this is a subset of the syntax permitted by 287 ; the Namespace_Response_Extension rule in [RFC2342] 289 lang-range-quoted = astring 290 ; Once any literal wrapper or quoting is removed, this 291 ; follows the language-range rule in [RFC4647] 293 lang-tag-quoted = astring 294 ; Once any literal wrapper or quoting is removed, this follows 295 ; the Language-Tag rule in [RFC4646] 297 resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR 298 *(UTF8-TEXT-CHAR / "[") 299 ; After the server is changed to a language other than 300 ; i-default, this resp-text rule replaces the resp-text 301 ; rule from [RFC3501]. 303 UTF8-TEXT-CHAR = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4 304 ; UTF-8 excluding 7-bit control characters and "[" 306 4. COMPARATOR Extension 308 IMAP4rev1 [RFC3501] includes the SEARCH command which can be used to 309 locate messages matching criteria including human-readable text. 310 The SORT extension [SORT] to IMAP allows the client to ask the 311 server to determine the order of messages based on criteria 312 including human-readable text. These mechanisms require the ability 313 to support non-English search and sort functions. 315 This section defines an IMAP extension to negotiate use of 316 comparators [RFC4790] to internationalize IMAP SEARCH, SORT and 317 THREAD. The IMAP extension consists of a new command to determine 318 or change the active comparator and a new response to indicate the 319 active comparator and possibly other available comparators. 321 The term "default comparator" refers to the comparator which is used 322 by SEARCH and SORT absent any negotiation using the COMPARATOR 323 command. The term "active comparator" refers to the comparator 324 which will be used within a session e.g. by SEARCH and SORT. The 325 COMPARATOR command is used to change the active comparator. 327 The active comparator applies to the following SEARCH keys: "BCC", 328 "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER". If the 329 server also advertises the "SORT" extension, then the active 330 comparator applies to the following SORT keys: "CC", "FROM", 331 "SUBJECT" and "TO". If the server advertises THREAD=ORDEREDSUBJECT, 332 then the active comparator applies to the ORDEREDSUBJECT threading 333 algorithm. If the server advertises THREAD=REFERENCES, then the 334 active comparator applies to the subject field comparisons done by 335 REFERENCES threading algorithm. Future extensions may choose to 336 apply the active comparator to their SEARCH keys. 338 For SORT and THREAD, the pre-processing necessary to extract the 339 base subject text from a Subject header occurs prior to the 340 application of a comparator. 342 4.1 COMPARATOR Extension Requirements 344 IMAP servers that support this extension MUST list the keyword 345 COMPARATOR in their CAPABILITY data once IMAP enters authenticated 346 state, and MAY list that keyword in other states. 348 A server that advertises this extension MUST implement the i;ascii- 349 casemap and i;octet comparators, as defined in [RFC4790]. A server 350 intended to be deployed globally MUST implement the i;unicode- 351 casemap comparator, as defined in [UCM]. 353 A server that advertises this extension SHOULD use i;ascii-casemap 354 as the default comparator. The selection of the default comparator 355 MAY be adjustable by the server administrator, and MAY be sensitive 356 to the current user. Once the IMAP connection enters authenticated 357 state, the default comparator MUST remain static for the remainder 358 of that connection. 360 A server that advertises this extension MUST support UTF-8 as a 361 SEARCH charset. 363 The COMPARATOR command is valid in authenticated and selected 364 states. 366 4.2 Comparators and Character Encodings 368 When SEARCH, SORT, THREAD or another command needs to perform 369 collation operations on messages (or on the command's arguments), 370 the server MUST remove MIME encoding (see [RFC2047] for headers and 371 [RFC2045] for bodyparts) and convert character encodings compatibly 372 before doing the collation operation. 374 Strings encoded using unknown character encodings should never match 375 when using the SEARCH command, and should sort together with invalid 376 input for the SORT and THREAD commands. 378 4.3 COMPARATOR Command 380 Arguments: Optional comparator order arguments. 382 Response: A possible COMPARATOR response (see Section 4.4). 384 Result: OK - Command completed 385 NO - No matching comparator found 386 BAD - arguments invalid 388 The COMPARATOR command is used to determine or change the active 389 comparator. When issued with no arguments, it results in a 390 COMPARATOR response indicating the currently active comparator. 391 When issued with one or more comparator order argument, it will 392 change the active comparator if any comparator matches any argument. 393 The COMPARATOR response will list other matching comparators if more 394 than one matches the specified patterns. 396 The argument "*" refers to the server's default comparator. 397 Otherwise each argument is an comparator specification as defined in 398 the Internet Application Protocol Comparator Registry [RFC4790]. 400 < The client requests activating a Czech comparator if possible, 401 or else a generic international comparator which it considers 402 suitable for Czech. The server picks the first supported 403 comparator. > 405 C: A001 COMPARATOR cz;* i;basic 406 S: * COMPARATOR i;basic 407 S: A001 OK Will use i;basic for collation 409 < The client requests pure octet matching, then does a search 410 for potential GIF files, then switches back to its usual 411 comparator. Note that this may not work on all IMAP servers, 412 see RFC 3501, page 50, second paragraph. > 414 C: B123 COMPARATOR i;octet 415 S: * COMPARATOR i;octet 416 S: B123 OK 417 C: B124 SEARCH OR BODY GIF87A BODY GIF89A 418 S: * SEARCH 42 69 419 S: B124 OK 420 C: B125 COMPARATOR cz;* i;basic 421 S: * COMPARATOR i;basic 422 S: B125 OK. 424 4.4 COMPARATOR Response 426 Contents: The active comparator. 427 An optional list of available matching comparators 429 The COMPARATOR response occurs as a result of a COMPARATOR command. 430 The first argument in the comparator response is the name of the 431 active comparator. The second argument is a list of comparators 432 which matched any of the arguments to the COMPARATOR command and is 433 present only if more than one match is found. 435 4.5 Formal Syntax 437 The following syntax specification inherits ABNF [RFC4234] rules 438 from IMAP4rev1 [RFC3501], and Internet Application Protocol 439 Comparator Registry [RFC4790]. 441 command-auth =/ comparator-cmd 443 resp-text-code =/ "BADCOMPARATOR" / "BADMATCH" 445 comparator-cmd = "COMPARATOR" *(SP comp-order-quoted) 447 comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "(" 448 comp-name-quoted *(SP comp-name-quoted) ")"] 450 comp-name-quoted = astring 451 ; Once any literal wrapper or quoting is removed, this 452 ; follows the collation-name rule from [RFC4790] 454 comp-order-quoted = astring 455 ; Once any literal wrapper or quoting is removed, this 456 ; follows the collation-order rule from [RFC4790] 458 comp-sel-quoted = astring 459 ; Once any literal wrapper or quoting is removed, this 460 ; follows the collation-sel rule from [RFC4790] 462 5. Other IMAP Internationalization Issues 464 The following sections provide an overview of various other IMAP 465 internationalization issues. These issues are not resolved by this 466 specification, but could be resolved by other standards work, such 467 as that being done by the EAI group (see [IMAP-EAI]). 469 5.1 Unicode Userids and Passwords 471 IMAP4rev1 presently restricts the userid and password fields of the 472 LOGIN command to US-ASCII. The "userid" and "password" fields of the 473 IMAP LOGIN command are restricted to US-ASCII only until a future 474 standards track RFC states otherwise. Servers are encouraged to 475 validate both fields to make sure they conform to the formal syntax 476 of UTF-8 and to reject the LOGIN command if that syntax is violated. 477 Servers MAY reject the use of any 8-bit in the "userid" or 478 "password" field. 480 When AUTHENTICATE is used, some servers may support userids and 481 passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows 482 that. However, such userids cannot be used as part of email 483 addresses. 485 5.2 UTF-8 Mailbox Names 487 The modified UTF-7 mailbox naming convention described in section 488 5.1.3 of RFC 3501 is best viewed as an transition from the status 489 quo in 1996 when modified UTF-7 was first specified. At that time, 490 there was widespread unofficial use of local character sets such as 491 ISO-8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant 492 non-interoperability. 494 The requirements in section 5.1 of RFC 3501 are very important if 495 we're ever going to be able to deploy UTF-8 mailbox names. Servers 496 are encouraged to enforce them. 498 5.3 UTF-8 Domains, Addresses and Mail Headers 500 There is now an IETF standard for Internationalizing Domain Names in 501 Applications [RFC3490]. While IMAP clients are free to support this 502 standard, an argument can be made that it would be helpful to simple 503 clients if the IMAP server could perform this conversion (the same 504 argument would apply to MIME header encoding [RFC2047]). However, 505 it would be unwise to move forward with such work until the work in 506 progress to define the format of international email addresses is 507 complete. 509 6. IANA Considerations 511 The IANA is requested to add LANGUAGE and COMPARATOR to the IMAP 512 Extensions registry, 513 http://www.iana.org/assignments/imap4-capabilities. 515 7. Security Considerations 517 The LANGUAGE extension makes a new command available in "Not 518 Authenticated" state in IMAP. Some IMAP implementations run with 519 root privilege when the server is in "Not Authenticated" state and 520 do not revoke that privilege until after authentication is complete. 521 Such implementations are particularly vulnerable to buffer overflow 522 security errors at this stage and need to implement parsing of this 523 command with extra care. 525 A LANGUAGE command issued prior to activation of a security layer is 526 subject to an active attack which suppresses or modifies the 527 negotiation and thus makes STARTTLS or authentication error messages 528 more difficult to interpret. This is not a new attack as the error 529 messages themselves are subject to active attack. Clients MUST re- 530 issue the LANGUAGE command once a security layer is active, so this 531 does not impact subsequent protocol operations. 533 Both the LANGUAGE and COMPARATOR extensions use the UTF-8 charset, 534 thus the security considerations for UTF-8 [RFC3629] are relevent. 535 However, neither uses UTF-8 for identifiers so the most serious 536 concerns do not apply. 538 8. Acknowledgements 540 The LANGUAGE extension is based on a previous Internet draft by Mike 541 Gahrns and Alexey Melnikov, a substantial portion of the text in 542 that section was written by them. Many people have participated in 543 discussions about an IMAP Language extension in the various fora of 544 the IETF and Internet working groups, so any list of contributors is 545 bound to be incomplete. However, the authors would like to thank 546 Andrew McCown for early work on the original proposal, John Myers 547 for suggestions regarding the namespace issue, along with Jutta 548 Degener, Mark Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo 549 and Martin Duerst for their many suggestions that have been 550 incorporated into this document. 552 Initial discussion of the COMPARATOR extension involved input from 553 Mark Crispin and other participants of the IMAP Extensions WG. 555 9. Relevant Standards for i18n IMAP Implementations 557 This is a non-normative list of standards to consider when 558 implementing i18n aware IMAP software. 560 o The LANGUAGE and COMPARATOR extensions to IMAP (this 561 specification). 562 o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501. 563 o The Mailbox International Naming Convention in section 5.1.3 of 564 RFC 3501. 565 o MIME [RFC2045] for message bodies. 566 o MIME header encoding [RFC2047] for message headers. 567 o The IETF EAI working group. 568 o MIME Parameter Value and Encoded Word Extensions [RFC2231] for 569 filenames. Quality IMAP server implementations will 570 automatically combine multipart parameters when generating the 571 BODYSTRUCTURE. There is also some deployed non-standard use of 572 MIME header encoding inside double-quotes for filenames. 573 o IDNA [RFC3490] and punycode [RFC3492] for domain names 574 (presently only relevant to IMAP clients). 575 o The UTF-8 charset [RFC3629]. 576 o The IETF policy on Character Sets and Languages [RFC2277]. 578 Normative References 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14, RFC 2119, March 1997. 583 [RFC2277] Alvestrand, "IETF Policy on Character Sets and 584 Languages", BCP 18, RFC 2277, January 1998. 586 [RFC2342] Gahrns, Newman, "IMAP4 Namespace", RFC 2342, May 1998. 588 [RFC3501] Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 589 4rev1", RFC 3501, March 2003. 591 [RFC3629] Yergeau, "UTF-8, a transformation format of ISO 10646", 592 STD 63, RFC 3629, November 2003. 594 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 595 Specifications: ABNF", RFC 4234, Brandenburg 596 Internetworking, Demon Internet Ltd, October 2005. 598 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 599 Layer (SASL)", RFC 4422, June 2006. 601 [RFC4646] Philips, Davis, "Tags for Identifying Languages", BCP 47, 602 RFC 4646, September 2006. 604 [RFC4647] Philips, Davis, "Matching of Language Tags", BCP 47, RFC 605 4647, September 2006. 607 [RFC4790] Newman, Duerst, Gulbrandsen, "Internet Application 608 Protocol Comparator Registry", RFC 4790, February 2007 610 Informative References 612 [RFC2045] Freed, Borenstein, "Multipurpose Internet Mail Extensions 613 (MIME) Part One: Format of Internet Message Bodies", RFC 614 2045, November 1996. 616 [RFC2047] Moore, "MIME (Multipurpose Internet Mail Extensions) Part 617 Three: Message Header Extensions for Non-ASCII Text", RFC 618 2047, November 1996. 620 [RFC2231] Freed, Moore, "MIME Parameter Value and Encoded Word 621 Extensions: Character Sets, Languages, and 622 Continuations", RFC 2231, November 1997. 624 [RFC3490] Faltstrom, Hoffman, Costello, "Internationalizing Domain 625 Names in Applications (IDNA)", RFC 3490, March 2003. 627 [RFC3492] Costello, "Punycode: A Bootstring encoding of Unicode for 628 Internationalized Domain Names in Applications (IDNA)", 629 RFC 3492, March 2003. 631 [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 632 PROTOCOL - SORT AND THREAD EXTENSION", draft-ietf- 633 imapext-sort-17 (work in progress), May 2004. 635 [METADATA] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap- 636 annotatemore-10 (work in progress), November 2006. 638 [UCM] Crispin,, "i;unicode-casemap - Simple Unicode Collation 639 Algorithm", draft-crispin-collation-unicasemap-00.txt, 640 December 2006. 642 [IMAP-EAI] Resnick, Newman, "IMAP Support for UTF-8", draft-ietf- 643 iea-imap-utf8 (work in progress), May 2006. 645 Authors' Addresses 647 Chris Newman 648 Sun Microsystems 649 3401 Centrelake Dr., Suite 410 650 Ontario, CA 91761 651 US 653 Email: chris.newman@sun.com 655 Arnt Gulbrandsen 656 Oryx Mail Systems GmbH 657 Schweppermannstr. 8 658 D-81671 Muenchen 659 Germany 661 Email: arnt@oryx.com 663 Fax: +49 89 4502 9758 665 Intellectual Property Statement 667 The IETF takes no position regarding the validity or scope of any 668 Intellectual Property Rights or other rights that might be claimed 669 to pertain to the implementation or use of the technology described 670 in this document or the extent to which any license under such 671 rights might or might not be available; nor does it represent that 672 it has made any independent effort to identify any such rights. 673 Information on the procedures with respect to rights in RFC 674 documents can be found in BCP 78 and BCP 79. 676 Copies of IPR disclosures made to the IETF Secretariat and any 677 assurances of licenses to be made available, or the result of an 678 attempt made to obtain a general license or permission for the use 679 of such proprietary rights by implementers or users of this 680 specification can be obtained from the IETF on-line IPR repository 681 at http://www.ietf.org/ipr. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights that may cover technology that may be required to implement 686 this standard. Please address the information to the IETF at ietf- 687 ipr@ietf.org. 689 Full Copyright Statement 691 Copyright (C) The IETF Trust (2007). This document is subject to 692 the rights, licenses and restrictions contained in BCP 78, and 693 except as set forth therein, the authors retain all their rights. 695 This document and the information contained herein are provided on 696 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 697 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 698 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 699 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 700 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 701 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 702 FOR A PARTICULAR PURPOSE. 704 Acknowledgment 706 Funding for the RFC Editor function is currently provided by the 707 Internet Society.