idnits 2.17.1 draft-ietf-imapext-i18n-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 9, 2003) is 7651 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) -- Looks like a reference, but probably isn't: 'BADCOMPARATOR' on line 421 -- Looks like a reference, but probably isn't: 'BADMATCH' on line 427 -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 527 ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3066 (ref. '5') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3501 (ref. '6') (Obsoleted by RFC 9051) == Outdated reference: A later version (-05) exists of draft-yergeau-rfc2279bis-04 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-14) exists of draft-newman-i18n-comparator-00 -- Obsolete informational reference (is this intentional?): RFC 3454 (ref. '12') (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3490 (ref. '13') (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-20) exists of draft-ietf-imapext-sort-12 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet-Draft Sun Microsystems 4 Expires: November 7, 2003 May 9, 2003 6 Internet Message Access Protocol Internationalization 7 draft-ietf-imapext-i18n-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on November 7, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 Internet Message Access Protocol (IMAP) version 4rev1 has basic 38 support for non-ASCII characters in mailbox names and search 39 substrings. It also supports non-ASCII message headers and content 40 encoded as specified by Multipurpose Internet Mail Extensions (MIME). 41 This specification defines a collection of IMAP extensions which 42 improve international support including comparator negotiation for 43 search, sort and thread, language negotiation for international error 44 text, and translations for namespace prefixes. 46 Table of Contents 48 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. LANGUAGE Extension . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1 LANGUAGE Extension Requirements . . . . . . . . . . . . . . . 3 52 3.2 LANGUAGE Command . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.3 LANGUAGE Response . . . . . . . . . . . . . . . . . . . . . . 6 54 3.4 TRANSLATION Extension to the NAMESPACE Response . . . . . . . 6 55 3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4. COMPARATOR Extension . . . . . . . . . . . . . . . . . . . . . 7 57 4.1 COMPARATOR Extension Requirements . . . . . . . . . . . . . . 8 58 4.2 Comparators and Charsets . . . . . . . . . . . . . . . . . . . 9 59 4.3 COMPARATOR Command . . . . . . . . . . . . . . . . . . . . . . 9 60 4.4 COMPARATOR Response . . . . . . . . . . . . . . . . . . . . . 10 61 4.5 COMPARATOR SEARCH and SORT Key . . . . . . . . . . . . . . . . 10 62 4.6 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5. Other IMAP Internationalization Issues . . . . . . . . . . . . 11 64 5.1 UTF-8 Userids and Passwords . . . . . . . . . . . . . . . . . 11 65 5.2 UTF-8 Mailbox Names . . . . . . . . . . . . . . . . . . . . . 12 66 5.3 UTF-8 Domains, Addresses and Mail Headers . . . . . . . . . . 12 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 70 9. Relevant Standards for i18n IMAP Implementations . . . . . . . 14 71 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 Normative References . . . . . . . . . . . . . . . . . . . . . 14 73 Informative References . . . . . . . . . . . . . . . . . . . . 15 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 75 Intellectual Property and Copyright Statements . . . . . . . . 17 77 1. Conventions Used in this Document 79 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 80 in this document are to be interpreted as defined in "Key words for 81 use in RFCs to Indicate Requirement Levels" [1]. 83 The formal syntax use the Augmented Backus-Naur Form (ABNF) [2] 84 notation including the core rules defined in Appendix A of RFC 2234. 86 In examples, "C:" and "S:" indicate lines sent by the client and 87 server respectively. If a single "C:" or "S:" label applies to 88 multiple lines, then the line breaks between those lines are for 89 editorial clarity only and are not part of the actual protocol 90 exchange. 92 2. Introduction 94 This specification defines two IMAP4rev1 [6] extensions to enhance 95 international support. These extensions can be advertised and 96 implemented separately. 98 The LANGUAGE extension allows the client to request a suitable 99 language for protocol error messages and in combination with the 100 NAMESPACE extension [4] enables namespace translations. 102 The COMPARATOR extension allows the client to request a suitable 103 comparator which will modify the behavior of the base specification's 104 SEARCH command as well as the SORT and THREAD extensions [15]. This 105 leverages the comparator registry [8]. 107 3. LANGUAGE Extension 109 IMAP allows server responses to include human-readable text that in 110 many cases needs to be presented to the user. But that text is 111 limited to US-ASCII by the IMAP specification [6] in order to 112 preserve backwards compatibility with deployed IMAP implementations. 113 This section specifies a way for an IMAP client to negotiate which 114 language the server should use when sending human-readable text. 116 3.1 LANGUAGE Extension Requirements 118 IMAP servers that support this extension MUST list the keyword 119 LANGUAGE in their CAPABILITY response as well as in the greeting 120 CAPABILITY data. 122 A server that advertises this extension MUST use the language 123 "i-default" as described in [3] as its default language until another 124 supported language is negotiated by the client. A server MUST include 125 "i-default" as one of its supported languages. 127 A client that supports this extension MUST be prepared for a possible 128 NAMESPACE response [4] from the server. 130 The LANGUAGE command is valid in not-authenticated, authenticated and 131 selected states. 133 3.2 LANGUAGE Command 135 Arguments: Optional language range argument. 137 Response: A possible LANGUAGE response (see Section 3.3). 139 A possible NAMESPACE response as defined by [4]. 141 Result: OK - Command completed 142 NO - Could not complete command 143 BAD - arguments invalid 145 The LANGUAGE command requests that human-readable text emitted by the 146 server be localized to the language matching the language range 147 argument as described by section 2.5 of RFC 3066. 149 If the command succeeds, the server will return human-readable 150 responses in the specified language starting with the tagged OK 151 response to the LANGUAGE command. These responses will be in UTF-8 152 [7]. 154 If the command fails, the server will continue to return 155 human-readable responses in the language it was previously using. 157 The client MUST NOT use MUL (Multiple languages) or UND 158 (Undetermined) language tags and the server MUST return BAD if either 159 tag is used. The special "*" language range argument indicates a 160 request to use a language designated as preferred by the server 161 administrator. The preferred language MAY vary based on the 162 currently active user. 164 If the language range does not match a known language tag exactly but 165 does match a language by the rules of section 2.5 of [5], the server 166 MUST send an untagged LANGUAGE response indicating the language 167 selected. 169 If the language range argument is omitted, the server SHOULD send an 170 untagged LANGUAGE response listing the languages it supports. If the 171 server is unable to enumerate the list of languages it supports it 172 MAY return a tagged NO response to the enumeration request. 174 < The server defaults to using English i-default responses until 175 the user explicitly changes the language. > 177 C: A001 LOGIN KAREN PASSWORD 178 S: A001 OK LOGIN completed 180 < Client requested MUL language. Server MUST reply with BAD > 182 C: A002 LANGUAGE MUL 183 S: A002 BAD Invalid language MUL 185 < A LANGUAGE command with no arguments is a request to enumerate 186 the list of languages the server supports. > 188 C: A003 LANGUAGE 189 S: * LANGUAGE (EN DE IT i-default) 190 S: A003 OK Supported languages have been enumerated 192 C: B001 LANGUAGE 193 S: B001 NO Server is unable to enumerate supported languages 195 < Once the client changes the language, all responses will be in 196 that language starting with the tagged OK to the LANGUAGE 197 command. > 199 C: A004 LANGUAGE FR 200 S: A004 OK La Language commande a ete execute avec success 202 < If a server does not support the requested primary language, 203 responses will continue to be returned in the current language 204 the server is using. > 206 C: A005 LANGUAGE DE 207 S: A005 NO Ce Language n'est pas supporte 209 C: A006 LANGUAGE FR-CA 210 S: * LANGUAGE (FR) 211 S: A006 OK La Language commande a ete execute avec success 213 C: A007 LANGUAGE "*" 214 S: * LANGUAGE (FR) 215 S: A007 OK La Language commande a ete execute avec success 217 3.3 LANGUAGE Response 219 Contents: A list of one or more language tags. 221 The LANGUAGE response occurs as a result of a LANGUAGE command. A 222 LANGUAGE response with a list containing a single language tag 223 indicates that the server is now using that language. A LANGUAGE 224 response with a list containing multiple language tags indicates the 225 server is communicating a list of available languages to the client, 226 and no change in the active language has been made. 228 3.4 TRANSLATION Extension to the NAMESPACE Response 230 If the server supports the IMAP4 NAMESPACE command [4], the server 231 MUST return an untagged NAMESPACE response when a language is 232 negotiated. However the server MUST NOT return a NAMESPACE response 233 if it is in not-authenticated state. 235 If as a result of the newly negotiated language, localized 236 representations of the namespace prefixes are available, the server 237 SHOULD include these in the TRANSLATION extension to the NAMESPACE 238 response. 240 The TRANSLATION extension to the NAMESPACE response returns a single 241 string, containing the modified UTF-7 [6] encoded translation of the 242 namespace prefix. It is the responsibility of the client to convert 243 between the namespace prefix and the translation of the namespace 244 prefix when presenting mailbox names to the user. 246 In this example a server supports the IMAP4 NAMESPACE command. It 247 uses no prefix to the user's Personal Namespace, a prefix of "Other 248 Users" to its Other Users' Namespace and a prefix of "Public Folders" 249 to its only Shared Namespace. Since a client will often display 250 these prefixes to the user, the server includes a translation of them 251 that can be presented to the user. 253 C: A001 LANGUAGE FR-CA 254 S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION" 255 ("Autres Utilisateurs/"))) (("Public Folders/" "/" 256 "TRANSLATION" ("R&Aok-pertoires Publics/"))) 257 S: A001 OK La Language commande a ete executee avec success 259 3.5 Formal Syntax 261 The following syntax specification inherits ABNF [2] rules from 262 IMAP4rev1 [6], IMAP4 Namespace [4], Tags for the Identification of 263 Languages [5], and UTF-8 [7]. 265 command-any =/ language-cmd 266 ; LANGUAGE command is valid in all states 268 mailbox-data =/ language-data 270 language-cmd = "LANGUAGE" [SP lang-range-quoted] 272 language-data = "LANGUAGE" SP "(" 273 lang-tag-quoted *(SP lang-tag-quoted) ")" 275 namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")" 276 ; the string is encoded in Modified UTF-7. 277 ; this is a subset of the syntax permitted by 278 ; the Namespace_Response_Extension rule in RFC 2342 280 lang-range-quoted = astring 281 ; Once any literal wrapper or quoting is removed, this follows 282 ; the language-range rule in section 2.5 of RFC 3066 284 lang-tag-quoted = astring 285 ; Once any literal wrapper or quoting is removed, this follows 286 ; the Language-Tag rule in section 2.1 of RFC 3066 288 ; After the server is changed to a language other than i-default, 289 ; the resp-text rule from RFC 3501 is replaced with the following: 291 resp-text = ["[" resp-text-code "]" SP ] 292 UTF8-TEXT-CHAR *(UTF8-TEXT-CHAR / "[") 294 UTF8-TEXT-CHAR = %x20-%x5A / %x5C-%x7E / UTF8-2 / UTF8-3 / UTF8-4 295 ; UTF-8 excluding 7-bit control characters and "[" 297 4. COMPARATOR Extension 299 IMAP4rev1 [6] includes the SEARCH command which can be used to locate 300 messages matching criteria including human-readable text. The SORT 301 extension [15] to IMAP allows the client to ask the server to 302 determine the order of messages based on criteria including 303 human-readable text. These mechanisms require the ability to support 304 non-English search and sort functions. 306 This section defines an IMAP extension to negotiate use of 307 comparators [8] to internationalize IMAP SEARCH, SORT and THREAD. 308 The IMAP extension consists of a new command to determine or change 309 the active comparator, a new response to indicate the active 310 comparator and possibly other available comparators, SEARCH and SORT 311 keys which can be used to change comparators on-the-fly, and an 312 additional response code to indicate that the failure of a SEARCH or 313 SORT command was due to an invalid comparator. 315 The term "default comparator" refers to the comparator which is used 316 by SEARCH and SORT absent any negotiation using the COMPARATOR 317 command or SEARCH/SORT key. The term "active comparator" refers to 318 the comparator which will be used within a session by SEARCH and SORT 319 absent use of the COMPARATOR SEARCH/SORT key. The COMPARATOR command 320 is used to change the active comparator. The term "selected 321 comparator" refers to the comparator selected by the most recent 322 COMPARATOR SEARCH/SORT key within the context of the current SEARCH/ 323 SORT program or the active comparator if there is no COMPARATOR 324 SEARCH/SORT key yet seen in context. 326 The selected comparator applies to the following SEARCH keys: "BCC", 327 "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER". If the 328 server also advertises the "SORT" extension, then the selected 329 comparator applies to the following SORT keys: "CC", "FROM", 330 "SUBJECT" and "TO". If the server advertises the 331 THREAD=ORDEREDSUBJECT, then the active comparator applies to the 332 ORDEREDSUBJECT threading algorithm. 334 For SORT and THREAD, the pre-processing necessary to extract the base 335 subject text from a Subject header occurs prior to the application of 336 a comparator. 338 4.1 COMPARATOR Extension Requirements 340 IMAP servers that support this extension MUST list the keyword 341 COMPARATOR in their CAPABILITY data once IMAP enters authenticated 342 state. 344 A server that advertises this extension MUST implement the 345 en;ascii-casemap and i;octet comparators. A server intended to be 346 deployed globally MUST implement the i;basic-uca=3.1.1-uv=3.2 347 comparator. 349 A server that advertises this extension MUST use a registered 350 case-insensitive comparator which supports the substring matching 351 function as the default comparator. If the server also advertises 352 the SORT or THREAD=ORDEREDSUBJECT extensions, then the default 353 comparator MUST also support the ordering function. The selection of 354 the default comparator MAY be adjustable by the server administrator, 355 and MAY be sensitive to the current user. Once the IMAP connection 356 enters authenticated state, the default comparator MUST remain static 357 for the remainder of that connection. 359 A server that advertises this extension MUST support UTF-8 as a 360 SEARCH charset. 362 The COMPARATOR command is valid in authenticated and selected states. 364 4.2 Comparators and Charsets 366 For SEARCH, SORT and THREAD operations that apply to message headers, 367 the server is responsible for removing the MIME header encoding [10] 368 and converting the text of any known charsets to UTF-8 prior to 369 applying the comparator algorithm. Unknown charsets should never 370 match when using the SEARCH command, and will sort together with 371 invalid comparator input for the SORT and THREAD commands. 373 When message text is in a known charset other than UTF-8, the server 374 is responsible for converting that text to UTF-8 prior to applying 375 the comparator. When message text is in an unknown charset, then the 376 text should be skipped by the SEARCH command unless the comparator is 377 i;octet. 379 4.3 COMPARATOR Command 381 Arguments: Optional comparator order arguments. 383 Response: A possible COMPARATOR response (see Section 4.4). 385 Result: OK - Command completed 386 NO - No matching comparator found 387 BAD - arguments invalid 389 The COMPARATOR command is used to determine or change the active 390 comparator. When issued with no arguments, it will result in a 391 COMPARATOR response indicating the currently active comparator. When 392 issued with one or more comparator order argument, it will change the 393 active comparator if any comparator matches any argument. The 394 COMPARATOR response will list other matching comparators if more than 395 one matches the specified patterns. 397 When the single argument "*" is used with the COMPARATOR command, it 398 will set the active comparator to be the default comparator. 400 4.4 COMPARATOR Response 402 Contents: The active comparator. 403 An optional list of available matching comparators 405 The COMPARATOR response occurs as a result of a COMPARATOR command. 406 The first argument in the comparator response is the name of the 407 active comparator. The second argument is a list of comparators 408 which matched any of the arguments to the COMPARATOR command and is 409 present only if more than one match is found. 411 4.5 COMPARATOR SEARCH and SORT Key 413 The COMPARATOR SEARCH key takes a comparator order argument. That 414 argument will select the comparator to use for subsequent SEARCH keys 415 in the search program. The COMPARATOR SORT key works in a similar 416 fashion except that it applies to subsequent SORT keys in the SORT 417 criterion. 419 If no comparator matches the pattern specified by the COMPARATOR 420 SEARCH or SORT key, then the SEARCH or SORT command will fail with a 421 [BADCOMPARATOR] response code. This error code is also returned if a 422 comparator is found, but it does not support the necessary function 423 (substring matching for SEARCH, or ordering for SORT). 425 If an input string provided as part of a SEARCH program causes an 426 error when used with the selected comparator, the SEARCH command will 427 fail with a [BADMATCH] response code. 429 4.6 Formal Syntax 431 The following syntax specification inherits ABNF [2] rules from 432 IMAP4rev1 [6], and Internet Application Protocol Comparator Registry 433 [8]. 435 command-auth =/ comparator-cmd 437 mailbox-data =/ comparator-data 439 search-key =/ comparator-key 441 sort-criterion =/ comparator-key 442 ; this only applies to servers which advertise both 443 ; the COMPARATOR and SORT extensions. 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-name-quoted *(SP comp-name-quoted) ")"] 452 comparator-key = "COMPARATOR" SP comp-order-quoted 454 comp-name-quoted = astring 455 ; Once any literal wrapper or quoting is removed, 456 ; this follows the comparator-name rule 458 comp-order-quoted = astring 459 ; Once any literal wrapper or quoting is removed, 460 ; this follows the comparator-order rule 462 comp-sel-quoted = astring 463 ; Once any literal wrapper or quoting is removed, 464 ; this follows the comparator-sel rule 466 5. Other IMAP Internationalization Issues 468 The following sections provide an overview of various other IMAP 469 internationalization issues. These issues are not resolved by this 470 specification, but could be resolved by future standards work. 472 5.1 UTF-8 Userids and Passwords 474 IMAP4rev1 presently restricts the userid and password fields of the 475 LOGIN command to US-ASCII. Because the ability to enter a userid and 476 password is necessary to use IMAP at all for most authentication 477 mechanisms, the potential lack of input methods for non-ASCII text is 478 a serious interoperability concern. However, because of the 479 visibility of these fields to end-users, it is expected that pressure 480 to support UTF-8 login names and passwords will eventually become 481 irresistable. This specification defers such work until the 482 SASL-related profile of stringprep [12] is published as an RFC, and 483 the impact on ACLs and email addresses has been assessed. 485 The "userid" and "password" fields of the IMAP LOGIN command are 486 restricted to US-ASCII only until a future standards track RFC states 487 otherwise. Servers are encouraged to validate both fields to make 488 sure they conform to the formal syntax of UTF-8 and to reject the 489 LOGIN command if that syntax is violated. Servers MAY reject the use 490 of any 8-bit in the "userid" or "password" field. 492 5.2 UTF-8 Mailbox Names 494 There appears to be rough concensus in the IMAP community that the 495 modified UTF-7 mailbox naming convention was a mistake and we should 496 have used UTF-8 instead. However, the preliminary design discussions 497 to create a transitional mechanism for UTF-8 mailbox names suggests 498 that the cost of supporting both a UTF-8 mechanism and a modified 499 UTF-7 convention for mailbox names during a transition period might 500 exceed the benefit of the eventual goal. Because of this 501 controversy, UTF-8 mailbox name mechanisms are not included in this 502 specification. 504 The requirements in section 5.1 of RFC 3501 are very important if 505 we're ever going to be able to deploy UTF-8 mailbox names. 507 5.3 UTF-8 Domains, Addresses and Mail Headers 509 There is now an IETF standard for Internationalizing Domain Names in 510 Applications [13]. While IMAP clients are free to support this 511 standard and convert punycode [14] to UTF-8 at display time, an 512 argument can be made that it would be helpful to simple clients if 513 the IMAP server could perform this conversion (the same argument 514 would apply to MIME header encoding [10]). However, it would be 515 unwise to move forward with such work until the work in progress to 516 define the format of international email addresses is complete. 518 6. IANA Considerations 520 When this is published as an RFC, the following IMAP extensions will 521 be registered: 523 +-----------------+------------+ 524 | Capability Name | Reference | 525 +-----------------+------------+ 526 | LANGUAGE | [RFC XXXX] | 527 | COMPARATOR | [RFC XXXX] | 528 +-----------------+------------+ 530 7. Security Considerations 532 The LANGUAGE extension makes a new command available in "Not 533 Authenticated" state in IMAP. Some IMAP implementations run with 534 root privilege when the server is in "Not Authenticated" state and do 535 not revoke that privilege until after authentication is complete. 536 Such implementations are particularly vulnerable to buffer overflow 537 security errors at this stage and need to implement parsing of this 538 command with extra care. 540 A LANGUAGE command issued prior to activation of a security layer is 541 subject to an active attack which suppresses or modifies the 542 negotiation and thus makes STARTTLS or authentication error messages 543 more difficult to interpret. This is not a new attack as the error 544 messages themselves are subject to active attack. Clients MUST 545 re-issue the LANGUAGE command once a security layer is active, so 546 this does not impact subsequent protocol operations. 548 Both the LANGUAGE and COMPARATOR extensions use the UTF-8 charset, 549 thus the security considerations for UTF-8 [7] are relevent. 550 However, neither uses UTF-8 for identifiers so the most serious 551 concerns do not apply. 553 8. Acknowledgements 555 The LANGUAGE extension is based on a previous Internet draft by Mike 556 Gahrns and Alexey Melnikov, a substantial portion of the text in that 557 section was written by them. Many people have participated in 558 discussions about an IMAP Language extension in the various fora of 559 the IETF and Internet working groups, so any list of contributors is 560 bound to be incomplete. However, the authors would like to thank 561 Andrew McCown for early work on the original proposal, John Myers for 562 suggestions regarding the namespace issue, along with Jutta Degener, 563 Mark Crispin, Mark Pustilnik and Larry Osterman for their many 564 suggestions that have been incorporated into this document. 566 Initial discussion of the COMPARATOR extension involved input from 567 Mark Crispin and other participants of the IMAP Extensions WG. 569 9. Relevant Standards for i18n IMAP Implementations 571 This is a non-normative list of standards to consider when 572 implementing i18n aware IMAP software. 574 o The LANGUAGE and COMPARATOR extensions to IMAP (this 575 specification). 577 o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501. 579 o The Mailbox International Naming Convention in section 5.1.3 of 580 RFC 3501. 582 o MIME [9] for message bodies. 584 o MIME header encoding [10] for message headers. 586 o MIME Parameter Value and Encoded Word Extensions [11] for 587 filenames. Quality IMAP server implementations will automatically 588 combine multipart parameters when generating the BODYSTRUCTURE. 589 There is also some deployed non-standard use of MIME header 590 encoding inside double-quotes for filenames. 592 o IDNA [13] and punycode [14] for domain names (presently only 593 relevant to IMAP clients). 595 o The UTF-8 charset [7]. 597 o The IETF policy on Character Sets and Languages [3]. 599 10. Open Issues 601 1. Should there be an explicit request for the list of comparators 602 in the COMPARATOR response code? 604 2. Should we add a command to fetch the lookup tables associated 605 with a comparator? 607 3. Need examples for COMPARATOR extension. 609 Normative References 611 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 612 Levels", BCP 14, RFC 2119, March 1997. 614 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 615 Specifications: ABNF", RFC 2234, November 1997. 617 [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", 618 BCP 18, RFC 2277, January 1998. 620 [4] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998. 622 [5] Alvestrand, H., "Tags for the Identification of Languages", BCP 623 47, RFC 3066, January 2001. 625 [6] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 626 RFC 3501, March 2003. 628 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 629 draft-yergeau-rfc2279bis-04 (work in progress), February 2003. 631 [8] Newman, C., "Internet Application Protocol Comparator Registry", 632 draft-newman-i18n-comparator-00 (work in progress), May 2003. 634 Informative References 636 [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 637 Extensions (MIME) Part One: Format of Internet Message Bodies", 638 RFC 2045, November 1996. 640 [10] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 641 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 642 November 1996. 644 [11] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word 645 Extensions: Character Sets, Languages, and Continuations", RFC 646 2231, November 1997. 648 [12] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 649 Strings ("stringprep")", RFC 3454, December 2002. 651 [13] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 652 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 654 [14] Costello, A., "Punycode: A Bootstring encoding of Unicode for 655 Internationalized Domain Names in Applications (IDNA)", RFC 656 3492, March 2003. 658 [15] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL 659 - SORT AND THREAD EXTENSION", draft-ietf-imapext-sort-12 (work 660 in progress), March 2003. 662 Author's Address 664 Chris Newman 665 Sun Microsystems 666 1050 Lakes Drive 667 West Covina, CA 91790 668 US 670 EMail: chris.newman@sun.com 672 Intellectual Property Statement 674 The IETF takes no position regarding the validity or scope of any 675 intellectual property or other rights that might be claimed to 676 pertain to the implementation or use of the technology described in 677 this document or the extent to which any license under such rights 678 might or might not be available; neither does it represent that it 679 has made any effort to identify any such rights. Information on the 680 IETF's procedures with respect to rights in standards-track and 681 standards-related documentation can be found in BCP-11. Copies of 682 claims of rights made available for publication and any assurances of 683 licenses to be made available, or the result of an attempt made to 684 obtain a general license or permission for the use of such 685 proprietary rights by implementors or users of this specification can 686 be obtained from the IETF Secretariat. 688 The IETF invites any interested party to bring to its attention any 689 copyrights, patents or patent applications, or other proprietary 690 rights which may cover technology that may be required to practice 691 this standard. Please address the information to the IETF Executive 692 Director. 694 Full Copyright Statement 696 Copyright (C) The Internet Society (2003). All Rights Reserved. 698 This document and translations of it may be copied and furnished to 699 others, and derivative works that comment on or otherwise explain it 700 or assist in its implementation may be prepared, copied, published 701 and distributed, in whole or in part, without restriction of any 702 kind, provided that the above copyright notice and this paragraph are 703 included on all such copies and derivative works. However, this 704 document itself may not be modified in any way, such as by removing 705 the copyright notice or references to the Internet Society or other 706 Internet organizations, except as needed for the purpose of 707 developing Internet standards in which case the procedures for 708 copyrights defined in the Internet Standards process must be 709 followed, or as required to translate it into languages other than 710 English. 712 The limited permissions granted above are perpetual and will not be 713 revoked by the Internet Society or its successors or assignees. 715 This document and the information contained herein is provided on an 716 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 717 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 718 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 719 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 720 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 722 Acknowledgement 724 Funding for the RFC Editor function is currently provided by the 725 Internet Society.