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