idnits 2.17.1 draft-ietf-imapext-i18n-07.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 733. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 719. ** 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 (November 2006) is 6372 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 November 2006 7 Internet Message Access Protocol Internationalization 8 draft-ietf-imapext-i18n-07.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 November 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 November 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 A client that supports this extension MUST be prepared for a 138 possible NAMESPACE response [RFC2342] from the server. 140 The LANGUAGE command is valid in all states. 142 Internet-draft November 2006 144 3.2 LANGUAGE Command 146 Arguments: Optional language range arguments. 148 Response: A possible LANGUAGE response (see Section 3.3). 150 Result: OK - Command completed 151 NO - Could not complete command 152 BAD - arguments invalid 154 The LANGUAGE command requests that human-readable text emitted by 155 the server be localized to a language matching one of the language 156 range argument as described by section 2.5 of RFC 3066. 158 If the command succeeds, the server will return human-readable 159 responses in the first supported language specified. The first 160 response affected by the change is the tagged OK response to the 161 LANGUAGE command. These responses will be in UTF-8 [RFC3629]. 163 If the command fails, the server will continue to return human- 164 readable responses in the language it was previously using. 166 The client MUST NOT use MUL (Multiple languages) or UND 167 (Undetermined) language tags and the server MUST return BAD if 168 either tag is used, even if other, legal, arguments are also 169 supplied. The special "*" language range argument indicates a 170 request to use a language designated as preferred by the server 171 administrator. The preferred language MAY vary based on the 172 currently active user. 174 If a language range does not match a known language tag exactly but 175 does match a language by the rules of [RFC4647], the server MUST 176 send an untagged LANGUAGE response indicating the language selected. 178 If there aren't any arguments, the server SHOULD send an untagged 179 LANGUAGE response listing the languages it supports. If the server 180 is unable to enumerate the list of languages it supports it MAY 181 return a tagged NO response to the enumeration request. 183 < The server defaults to using English i-default responses until 184 the user explicitly changes the language. > 186 C: A001 LOGIN KAREN PASSWORD 187 S: A001 OK LOGIN completed 189 < Client requested MUL language. Server MUST reply with BAD. > 191 C: A002 LANGUAGE MUL 193 Internet-draft November 2006 195 S: A002 BAD Invalid language MUL 197 < A LANGUAGE command with no arguments is a request to enumerate 198 the list of languages the server supports. > 200 C: A003 LANGUAGE 201 S: * LANGUAGE (EN DE IT i-default) 202 S: A003 OK Supported languages have been enumerated 204 C: B001 LANGUAGE 205 S: B001 NO Server is unable to enumerate supported languages 207 < Once the client changes the language, all responses will be in 208 that language starting with the tagged OK to the LANGUAGE 209 command. Because RFCs are in US-ASCII, this document uses an 210 ASCII transcription rather than UTF-8 text, e.g. ue in the 211 word "ausgefuehrt" > 213 C: A004 LANGUAGE DE 214 S: A004 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 216 < If a server does not support the requested primary language, 217 responses will continue to be returned in the current language 218 the server is using. > 220 C: A005 LANGUAGE FR 221 S: A005 NO Diese Sprache ist nicht unterstuetzt 223 C: A006 LANGUAGE DE-IT 224 S: * LANGUAGE (DE-IT) 225 S: A006 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 226 C: A007 LANGUAGE "*" 227 S: * LANGUAGE (DE) 228 S: A007 OK LANGUAGE-Befehl erfolgreich ausgefuehrt 230 < Server does not speak French, but does speak English. User 231 speaks Canadian French and Canadian English. > 233 C: A008 LANGUAGE FR-CA EN-CA 234 S: * LANGUAGE (EN) 235 S: A008 OK Now speaking English 237 3.3 LANGUAGE Response 239 Contents: A list of one or more language tags. 241 Internet-draft November 2006 243 The LANGUAGE response occurs as a result of a LANGUAGE command. A 244 LANGUAGE response with a list containing a single language tag 245 indicates that the server is now using that language. A LANGUAGE 246 response with a list containing multiple language tags indicates the 247 server is communicating a list of available languages to the client, 248 and no change in the active language has been made. 250 3.4 TRANSLATION Extension to the NAMESPACE Response 252 If as a result of the newly negotiated language, localized 253 representations of the namespace prefixes are available, the server 254 SHOULD include these in the TRANSLATION extension to the NAMESPACE 255 response. 257 OPEN ISSUE: I would appreciate concrete suggestions about how to do 258 NAMESPACE better. 260 The TRANSLATION extension to the NAMESPACE response returns a single 261 string, containing the modified UTF-7 [RFC3501] encoded translation 262 of the namespace prefix. It is the responsibility of the client to 263 convert between the namespace prefix and the translation of the 264 namespace prefix when presenting mailbox names to the user. 266 In this example a server supports the IMAP4 NAMESPACE command. It 267 uses no prefix to the user's Personal Namespace, a prefix of "Other 268 Users" to its Other Users' Namespace and a prefix of "Public 269 Folders" to its only Shared Namespace. Since a client will often 270 display these prefixes to the user, the server includes a 271 translation of them that can be presented to the user. 273 C: A001 LANGUAGE DE-IT 274 S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION" 275 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 276 "TRANSLATION" ("Gemeinsame Mailboxen/"))) 277 S: A001 OK LANGUAGE-Befehl ausgefuehrt 279 3.5 Formal Syntax 281 The following syntax specification inherits ABNF [RFC4234] rules 282 from IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the 283 Identifying Languages [RFC4646], and UTF-8 [RFC3629]. 285 command-any =/ language-cmd 286 ; LANGUAGE command is valid in all states 288 language-cmd = "LANGUAGE" *(SP lang-range-quoted) 290 Internet-draft November 2006 292 response-payload =/ language-data / comparator-data 294 language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP lang-tag- 295 quoted) ")" 297 namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")" 298 ; the string is encoded in Modified UTF-7. 299 ; this is a subset of the syntax permitted by 300 ; the Namespace_Response_Extension rule in [RFC2342] 302 lang-range-quoted = astring 303 ; Once any literal wrapper or quoting is removed, this 304 ; follows the language-range rule in [RFC4647] 306 lang-tag-quoted = astring 307 ; Once any literal wrapper or quoting is removed, this follows 308 ; the Language-Tag rule in [RFC4646] 310 resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR 311 *(UTF8-TEXT-CHAR / "[") 312 ; After the server is changed to a language other than 313 ; i-default, this resp-text rule replaces the resp-text 314 ; rule from [RFC3501]. 316 UTF8-TEXT-CHAR = %x20-%x5A / %x5C-%x7E / UTF8-2 / UTF8-3 / UTF8-4 317 ; UTF-8 excluding 7-bit control characters and "[" 319 4. COMPARATOR Extension 321 IMAP4rev1 [RFC3501] includes the SEARCH command which can be used to 322 locate messages matching criteria including human-readable text. 323 The SORT extension [SORT] to IMAP allows the client to ask the 324 server to determine the order of messages based on criteria 325 including human-readable text. These mechanisms require the ability 326 to support non-English search and sort functions. 328 This section defines an IMAP extension to negotiate use of 329 comparators [RFCxxxx] to internationalize IMAP SEARCH, SORT and 330 THREAD. The IMAP extension consists of a new command to determine 331 or change the active comparator and a new response to indicate the 332 active comparator and possibly other available comparators. 334 The term "default comparator" refers to the comparator which is used 335 by SEARCH and SORT absent any negotiation using the COMPARATOR 336 command. The term "active comparator" refers to the comparator 337 which will be used within a session e.g. by SEARCH and SORT. The 338 COMPARATOR command is used to change the active comparator. 340 Internet-draft November 2006 342 The active comparator applies to the following SEARCH keys: "BCC", 343 "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER". If the 344 server also advertises the "SORT" extension, then the active 345 comparator applies to the following SORT keys: "CC", "FROM", 346 "SUBJECT" and "TO". If the server advertises THREAD=ORDEREDSUBJECT, 347 then the active comparator applies to the ORDEREDSUBJECT threading 348 algorithm. If the server advertises THREAD=REFERENCES, then the 349 active comparator applies to the subject field comparisons done by 350 REFERENCES threading algorithm. Future extensions may choose to 351 apply the active comparator to their SEARCH keys. 353 For SORT and THREAD, the pre-processing necessary to extract the 354 base subject text from a Subject header occurs prior to the 355 application of a comparator. 357 4.1 COMPARATOR Extension Requirements 359 IMAP servers that support this extension MUST list the keyword 360 COMPARATOR in their CAPABILITY data once IMAP enters authenticated 361 state, and MAY list that keyword in other states. 363 A server that advertises this extension MUST implement the i;ascii- 364 casemap and i;octet comparators, as defined in [RFCxxxx]. A server 365 intended to be deployed globally MUST implement the i;basic 366 comparator, as defined in [BASIC]. 368 A server that advertises this extension SHOULD use i;ascii-casemap 369 as the default comparator. The selection of the default comparator 370 MAY be adjustable by the server administrator, and MAY be sensitive 371 to the current user. Once the IMAP connection enters authenticated 372 state, the default comparator MUST remain static for the remainder 373 of that connection. 375 A server that advertises this extension MUST support UTF-8 as a 376 SEARCH charset. 378 The COMPARATOR command is valid in authenticated and selected 379 states. 381 4.2 Comparators and Character Encodings 383 When SEARCH, SORT, THREAD or another command needs to perform 384 collation operations on messages (or on the command's arguments), 385 the server MUST remove MIME encoding (see [RFC2047] for headers and 386 [RFC2045] for bodyparts) and convert character encodings compatibly 387 before doing the collation operation. 389 Internet-draft November 2006 391 Strings encoded using unknown character encodings should never match 392 when using the SEARCH command, and should sort together with invalid 393 input for the SORT and THREAD commands. 395 4.3 COMPARATOR Command 397 Arguments: Optional comparator order arguments. 399 Response: A possible COMPARATOR response (see Section 4.4). 401 Result: OK - Command completed 402 NO - No matching comparator found 403 BAD - arguments invalid 405 The COMPARATOR command is used to determine or change the active 406 comparator. When issued with no arguments, it results in a 407 COMPARATOR response indicating the currently active comparator. 408 When issued with one or more comparator order argument, it will 409 change the active comparator if any comparator matches any argument. 410 The COMPARATOR response will list other matching comparators if more 411 than one matches the specified patterns. 413 The argument "*" refers to the server's default comparator. 414 Otherwise each argument is an comparator specification as defined in 415 the Internet Application Protocol Comparator Registry [RFCxxxx]. 417 < The client requests activating a Czech comparator if possible, 418 or else a generic international comparator which it considers 419 suitable for Czech. The server picks the first supported 420 comparator. > 422 C: A001 COMPARATOR cz;* i;basic* 423 S: * COMPARATOR i;basic;uca=3.1.1;uv=3.2 424 S: A001 OK Will use i;basic;uca=3.1.1;uv=3.2 for collation 426 < The client requests pure octet matching, then does a search 427 for potential GIF files, then switches back to its usual 428 comparator. Note that this may not work on all IMAP servers, 429 see RFC 3501, page 50, second paragraph. > 431 C: B123 COMPARATOR i;octet 432 S: * COMPARATOR i;octet 433 S: B123 OK 434 C: B124 SEARCH OR BODY GIF87A BODY GIF89A 435 S: * SEARCH 42 69 436 S: B124 OK 438 Internet-draft November 2006 440 C: B125 COMPARATOR cz;* i;basic* 441 S: * COMPARATOR i;basic;uca=3.1.1;uv=3.2 442 S: B125 OK. 444 4.4 COMPARATOR Response 446 Contents: The active comparator. 447 An optional list of available matching comparators 449 The COMPARATOR response occurs as a result of a COMPARATOR command. 450 The first argument in the comparator response is the name of the 451 active comparator. The second argument is a list of comparators 452 which matched any of the arguments to the COMPARATOR command and is 453 present only if more than one match is found. 455 4.5 Formal Syntax 457 The following syntax specification inherits ABNF [RFC4234] rules 458 from IMAP4rev1 [RFC3501], and Internet Application Protocol 459 Comparator Registry [RFCxxxx]. 461 command-auth =/ comparator-cmd 463 resp-text-code =/ "BADCOMPARATOR" / "BADMATCH" 465 comparator-cmd = "COMPARATOR" *(SP comp-order-quoted) 467 comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "(" 468 comp-name-quoted *(SP comp-name-quoted) ")"] 470 comp-name-quoted = astring 471 ; Once any literal wrapper or quoting is removed, this 472 ; follows the collation-name rule from [RFCxxxx] 474 comp-order-quoted = astring 475 ; Once any literal wrapper or quoting is removed, this 476 ; follows the collation-order rule from [RFCxxxx] 478 comp-sel-quoted = astring 479 ; Once any literal wrapper or quoting is removed, this 480 ; follows the collation-sel rule from [RFCxxxx] 482 Internet-draft November 2006 484 5. Other IMAP Internationalization Issues 486 The following sections provide an overview of various other IMAP 487 internationalization issues. These issues are not resolved by this 488 specification, but could be resolved by other standards work, such 489 as that being done by the EAI group (see [IMAP-EAI]). 491 5.1 Unicode Userids and Passwords 493 IMAP4rev1 presently restricts the userid and password fields of the 494 LOGIN command to US-ASCII. The "userid" and "password" fields of the 495 IMAP LOGIN command are restricted to US-ASCII only until a future 496 standards track RFC states otherwise. Servers are encouraged to 497 validate both fields to make sure they conform to the formal syntax 498 of UTF-8 and to reject the LOGIN command if that syntax is violated. 499 Servers MAY reject the use of any 8-bit in the "userid" or 500 "password" field. 502 When AUTHENTICATE is used, some servers may support userids and 503 passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows 504 that. However, such userids cannot be used as email 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, 526 it would be unwise to move forward with such work until the work in 527 progress to define the format of international email addresses is 528 complete. 530 Internet-draft November 2006 532 6. IANA Considerations 534 The IANA is requested to add LANGUAGE and COMPARATOR to the IMAP 535 Extensions registry. 537 7. Security Considerations 539 The LANGUAGE extension makes a new command available in "Not 540 Authenticated" state in IMAP. Some IMAP implementations run with 541 root privilege when the server is in "Not Authenticated" state and 542 do not revoke that privilege until after authentication is complete. 543 Such implementations are particularly vulnerable to buffer overflow 544 security errors at this stage and need to implement parsing of this 545 command with extra care. 547 A LANGUAGE command issued prior to activation of a security layer is 548 subject to an active attack which suppresses or modifies the 549 negotiation and thus makes STARTTLS or authentication error messages 550 more difficult to interpret. This is not a new attack as the error 551 messages themselves are subject to active attack. Clients MUST re- 552 issue the LANGUAGE command once a security layer is active, so this 553 does not impact subsequent protocol operations. 555 Both the LANGUAGE and COMPARATOR extensions use the UTF-8 charset, 556 thus the security considerations for UTF-8 [RFC3629] are relevent. 557 However, neither uses UTF-8 for identifiers so the most serious 558 concerns do not apply. 560 8. Acknowledgements 562 The LANGUAGE extension is based on a previous Internet draft by Mike 563 Gahrns and Alexey Melnikov, a substantial portion of the text in 564 that section was written by them. Many people have participated in 565 discussions about an IMAP Language extension in the various fora of 566 the IETF and Internet working groups, so any list of contributors is 567 bound to be incomplete. However, the authors would like to thank 568 Andrew McCown for early work on the original proposal, John Myers 569 for suggestions regarding the namespace issue, along with Jutta 570 Degener, Mark Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo 571 and Martin Duerst for their many suggestions that have been 572 incorporated into this document. 574 Initial discussion of the COMPARATOR extension involved input from 575 Mark Crispin and other participants of the IMAP Extensions WG. 577 Internet-draft November 2006 579 9. Relevant Standards for i18n IMAP Implementations 581 This is a non-normative list of standards to consider when 582 implementing i18n aware IMAP software. 584 o The LANGUAGE and COMPARATOR extensions to IMAP (this 585 specification). 586 o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501. 587 o The Mailbox International Naming Convention in section 5.1.3 of 588 RFC 3501. 589 o MIME [RFC2045] for message bodies. 590 o MIME header encoding [RFC2047] for message headers. 591 o The IETF EAI working group. 592 o MIME Parameter Value and Encoded Word Extensions [RFC2231] for 593 filenames. Quality IMAP server implementations will 594 automatically combine multipart parameters when generating the 595 BODYSTRUCTURE. There is also some deployed non-standard use of 596 MIME header encoding inside double-quotes for filenames. 597 o IDNA [RFC3490] and punycode [RFC3492] for domain names 598 (presently only relevant to IMAP clients). 599 o The UTF-8 charset [RFC3629]. 600 o The IETF policy on Character Sets and Languages [RFC2277]. 602 Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC2277] Alvestrand, "IETF Policy on Character Sets and 608 Languages", BCP 18, RFC 2277, January 1998. 610 [RFC2342] Gahrns, Newman, "IMAP4 Namespace", RFC 2342, May 1998. 612 [RFC3501] Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 613 4rev1", RFC 3501, March 2003. 615 [RFC3629] Yergeau, "UTF-8, a transformation format of ISO 10646", 616 STD 63, RFC 3629, November 2003. 618 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 619 Specifications: ABNF", RFC 4234, Brandenburg 620 Internetworking, Demon Internet Ltd, October 2005. 622 [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 623 Layer (SASL)", RFC 4422, June 2006. 625 Internet-draft November 2006 627 [RFC4646] Philips, Davis, "Tags for Identifying Languages", BCP 47, 628 RFC 4646, September 2006. 630 [RFC4647] Philips, Davis, "Matching of Language Tags", BCP 47, RFC 631 4647, September 2006. 633 [RFCxxxx] Newman, Duerst, Gulbrandsen, "Internet Application 634 Protocol Comparator Registry", RFC-draft-newman-i18n- 635 comparator, September 2006 637 Informative References 639 [RFC2045] Freed, Borenstein, "Multipurpose Internet Mail Extensions 640 (MIME) Part One: Format of Internet Message Bodies", RFC 641 2045, November 1996. 643 [RFC2047] Moore, "MIME (Multipurpose Internet Mail Extensions) Part 644 Three: Message Header Extensions for Non-ASCII Text", RFC 645 2047, November 1996. 647 [RFC2231] Freed, Moore, "MIME Parameter Value and Encoded Word 648 Extensions: Character Sets, Languages, and 649 Continuations", RFC 2231, November 1997. 651 [RFC3490] Faltstrom, Hoffman, Costello, "Internationalizing Domain 652 Names in Applications (IDNA)", RFC 3490, March 2003. 654 [RFC3492] Costello, "Punycode: A Bootstring encoding of Unicode for 655 Internationalized Domain Names in Applications (IDNA)", 656 RFC 3492, March 2003. 658 [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 659 PROTOCOL - SORT AND THREAD EXTENSION", draft-ietf- 660 imapext-sort-17 (work in progress), May 2004. 662 [METADATA] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap- 663 annotatemore-10 (work in progress), November 2006. 665 [BASIC] Newman, Duerst, Gulbrandsen, "i;basic - Registration of 666 the Unicode Collation Algorithm (UCA)", draft- 667 gulbrandsen-collation-basic (work in progress), November 668 2006. 670 [IMAP-EAI] Resnick, Newman, ""IMAP Support for UTF-8", draft-ietf- 671 iea-imap-utf8 (work in progress), May 2006. 673 Internet-draft November 2006 675 Authors' Addresses 677 Chris Newman 678 Sun Microsystems 679 3401 Centrelake Dr., Suite 410 680 Ontario, CA 91761 681 US 683 Email: chris.newman@sun.com 685 Arnt Gulbrandsen 686 Oryx Mail Systems GmbH 687 Schweppermannstr. 8 688 D-81781 Muenchen 689 Germany 691 Email: arnt@oryx.com 693 Fax: +49 89 4502 9758 695 Internet-draft November 2006 697 Intellectual Property Statement 699 The IETF takes no position regarding the validity or scope of any 700 Intellectual Property Rights or other rights that might be claimed 701 to pertain to the implementation or use of the technology described 702 in this document or the extent to which any license under such 703 rights might or might not be available; nor does it represent that 704 it has made any independent effort to identify any such rights. 705 Information on the procedures with respect to rights in RFC 706 documents can be found in BCP 78 and BCP 79. 708 Copies of IPR disclosures made to the IETF Secretariat and any 709 assurances of licenses to be made available, or the result of an 710 attempt made to obtain a general license or permission for the use 711 of such proprietary rights by implementers or users of this 712 specification can be obtained from the IETF on-line IPR repository 713 at http://www.ietf.org/ipr. 715 The IETF invites any interested party to bring to its attention any 716 copyrights, patents or patent applications, or other proprietary 717 rights that may cover technology that may be required to implement 718 this standard. Please address the information to the IETF at ietf- 719 ipr@ietf.org. 721 Full Copyright Statement 723 Copyright (C) The Internet Society (2006). This document is subject 724 to the rights, licenses and restrictions contained in BCP 78, and 725 except as set forth therein, the authors retain all their rights. 727 This document and the information contained herein are provided on 728 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 729 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 730 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 731 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 732 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 733 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 735 Acknowledgment 737 Funding for the RFC Editor function is currently provided by the 738 Internet Society.