idnits 2.17.1 draft-ietf-imapext-i18n-05.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 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 677. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** 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 ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 (July 2005) is 6865 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) == Unused Reference: '12' is defined on line 617, but no explicit reference was found in the text ** 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 (-14) exists of draft-newman-i18n-comparator-05 -- 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-17 == Outdated reference: A later version (-17) exists of draft-daboo-imap-annotatemore-07 Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 9 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 draft-ietf-imapext-i18n-05.txt Arnt Gulbrandsen 4 Oryx Mail Systems 5 July 2005 7 Internet Message Access Protocol Internationalization 9 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 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 29 Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society 2005. 36 Abstract 38 Internet Message Access Protocol (IMAP) version 4rev1 has basic 39 support for non-ASCII characters in mailbox names and search 40 substrings. It also supports non-ASCII message headers and content 41 encoded as specified by Multipurpose Internet Mail Extensions 42 (MIME). This specification defines a collection of IMAP extensions 43 which improve international support including comparator negotiation 44 for search, sort and thread, language negotiation for international 45 error text, and translations for namespace prefixes. 47 Table of Contents 49 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. LANGUAGE Extension . . . . . . . . . . . . . . . . . . . . . 3 52 3.1 LANGUAGE Extension Requirements . . . . . . . . . . . . . . . 3 53 3.2 LANGUAGE Command . . . . . . . . . . . . . . . . . . . . . . 4 54 3.3 LANGUAGE Response . . . . . . . . . . . . . . . . . . . . . . 5 55 3.4 TRANSLATION Extension to the NAMESPACE Response . . . . . . . 6 56 3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. COMPARATOR Extension . . . . . . . . . . . . . . . . . . . . 7 58 4.1 COMPARATOR Extension Requirements . . . . . . . . . . . . . . 8 59 4.2 Comparators and Charsets . . . . . . . . . . . . . . . . . . 9 60 4.3 COMPARATOR Command . . . . . . . . . . . . . . . . . . . . . 9 61 4.4 COMPARATOR Response . . . . . . . . . . . . . . . . . . . . . 10 62 4.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 63 5. Other IMAP Internationalization Issues . . . . . . . . . . . 11 64 5.1 UTF-8 Userids and Passwords . . . . . . . . . . . . . . . . . 11 65 5.2 UTF-8 Mailbox Names . . . . . . . . . . . . . . . . . . . . . 11 66 5.3 UTF-8 Domains, Addresses and Mail Headers . . . . . . . . . . 12 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 70 9. Relevant Standards for i18n IMAP Implementations . . . . . . 13 71 Normative References . . . . . . . . . . . . . . . . . . . . 14 72 Informative References . . . . . . . . . . . . . . . . . . . 14 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 74 Intellectual Property and Copyright Statements . . . . . . . 16 76 Conventions Used in This Document 78 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 79 in this document are to be interpreted as defined in "Key words for 80 use in RFCs to Indicate Requirement Levels" [1]. 82 The formal syntax use the Augmented Backus-Naur Form (ABNF) [2] 83 notation including the core rules defined in Appendix A of RFC 2234. 84 The UTF8-related productions are defined in RFC 3629 [7]. 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 104 specification's SEARCH command as well as the SORT and THREAD 105 extensions [15]. This 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 The LANGUAGE extension only provides a mechanism for altering fixed 117 server strings such as response text and NAMESPACE folder names. 118 Assigning localized language aliases to shared mailboxes would be 119 done with a separate mechanism such as the proposed ANNOTATEMORE 120 extension. [16] 122 3.1 LANGUAGE Extension Requirements 124 IMAP servers that support this extension MUST list the keyword 125 LANGUAGE in their CAPABILITY response as well as in the greeting 126 CAPABILITY data. 128 A server that advertises this extension MUST use the language "i- 129 default" as described in [3] as its default language until another 130 supported language is negotiated by the client. A server MUST 131 include "i-default" as one of its supported languages. 133 A client that supports this extension MUST be prepared for a 134 possible NAMESPACE response [4] from the server. 136 The LANGUAGE command is valid in all states. 138 3.2 LANGUAGE Command 140 Arguments: Optional language range argument. 142 Response: A possible LANGUAGE response (see Section 3.3). 143 A possible NAMESPACE response as defined by [4]. 145 Result: OK - Command completed 146 NO - Could not complete command 147 BAD - arguments invalid 149 The LANGUAGE command requests that human-readable text emitted by 150 the server be localized to a language matching the language range 151 argument as described by section 2.5 of RFC 3066. 153 If the command succeeds, the server will return human-readable 154 responses in the specified language starting with the tagged OK 155 response to the LANGUAGE command. These responses will be in UTF-8 156 [7]. 158 If the command fails, the server will continue to return human- 159 readable responses in the language it was previously using. 161 The client MUST NOT use MUL (Multiple languages) or UND 162 (Undetermined) language tags and the server MUST return BAD if 163 either tag is used. The special "*" language range argument 164 indicates a request to use a language designated as preferred by the 165 server administrator. The preferred language MAY vary based on the 166 currently active user. 168 If the language range does not match a known language tag exactly 169 but does match a language by the rules of section 2.5 of [5], the 170 server MUST send an untagged LANGUAGE response indicating the 171 language selected. 173 If the language range argument is omitted, the server SHOULD send an 174 untagged LANGUAGE response listing the languages it supports. If 175 the server is unable to enumerate the list of languages it supports 176 it MAY return a tagged NO response to the enumeration request. 178 < The server defaults to using English i-default responses until 179 the user explicitly changes the language. > 181 C: A001 LOGIN KAREN PASSWORD 182 S: A001 OK LOGIN completed 184 < Client requested MUL language. Server MUST reply with BAD. > 185 C: A002 LANGUAGE MUL 186 S: A002 BAD Invalid language MUL 188 < A LANGUAGE command with no arguments is a request to enumerate 189 the list of languages the server supports. > 191 C: A003 LANGUAGE 192 S: * LANGUAGE (EN DE IT i-default) 193 S: A003 OK Supported languages have been enumerated 195 C: B001 LANGUAGE 196 S: B001 NO Server is unable to enumerate supported languages 198 < Once the client changes the language, all responses will be in 199 that language starting with the tagged OK to the LANGUAGE 200 command. Because RFCs are in US-ASCII, this document uses an 201 ASCII transcription rather than UTF-8 text, e.g. ue in the 202 word "ausgefuehrt" > 204 C: A004 LANGUAGE DE 205 S: A004 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 207 < If a server does not support the requested primary language, 208 responses will continue to be returned in the current language 209 the server is using. > 211 C: A005 LANGUAGE FR 212 S: A005 NO Diese Sprache ist nicht unterstuetzt 214 C: A006 LANGUAGE DE-IT 215 S: * LANGUAGE (DE-IT) 216 S: A006 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 217 C: A007 LANGUAGE "*" 218 S: * LANGUAGE (DE) 219 S: A007 OK LANGUAGE-Befehl erfolgreich ausgefuehrt 221 3.3 LANGUAGE Response 223 Contents: A list of one or more language tags. 225 The LANGUAGE response occurs as a result of a LANGUAGE command. A 226 LANGUAGE response with a list containing a single language tag 227 indicates that the server is now using that language. A LANGUAGE 228 response with a list containing multiple language tags indicates the 229 server is communicating a list of available languages to the client, 230 and no change in the active language has been made. 232 3.4 TRANSLATION Extension to the NAMESPACE Response 234 If the server supports the IMAP4 NAMESPACE command [4], the server 235 MUST return an untagged NAMESPACE response when a language is 236 negotiated. However the server MUST NOT return a NAMESPACE response 237 if it is in not-authenticated state. 239 If as a result of the newly negotiated language, localized 240 representations of the namespace prefixes are available, the server 241 SHOULD include these in the TRANSLATION extension to the NAMESPACE 242 response. 244 The TRANSLATION extension to the NAMESPACE response returns a single 245 string, containing the modified UTF-7 [6] encoded translation of the 246 namespace prefix. It is the responsibility of the client to convert 247 between the namespace prefix and the translation of the namespace 248 prefix when presenting mailbox names to the user. 250 In this example a server supports the IMAP4 NAMESPACE command. It 251 uses no prefix to the user's Personal Namespace, a prefix of "Other 252 Users" to its Other Users' Namespace and a prefix of "Public 253 Folders" to its only Shared Namespace. Since a client will often 254 display these prefixes to the user, the server includes a 255 translation of them that can be presented to the user. 257 C: A001 LANGUAGE DE-IT 258 S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION" 259 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 260 "TRANSLATION" ("Gemeinsame Mailboxen/"))) 261 S: A001 OK LANGUAGE-Befehl ausgefuehrt 263 3.5 Formal Syntax 265 The following syntax specification inherits ABNF [2] rules from 266 IMAP4rev1 [6], IMAP4 Namespace [4], Tags for the Identification of 267 Languages [5], and UTF-8 [7]. 269 command-any =/ language-cmd 270 ; LANGUAGE command is valid in all states 272 language-cmd = "LANGUAGE" [SP lang-range-quoted] 274 language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP lang- 275 tag-quoted) ")" 277 namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string 278 ")" 279 ; the string is encoded in Modified UTF-7. 280 ; this is a subset of the syntax permitted by 281 ; the Namespace_Response_Extension rule in RFC 2342 283 lang-range-quoted = astring 284 ; Once any literal wrapper or quoting is removed, this 285 ; follows the language-range rule in section 2.5 of RFC 3066 287 lang-tag-quoted = astring 288 ; Once any literal wrapper or quoting is removed, this 289 follows 290 ; the Language-Tag rule in section 2.1 of RFC 3066 292 ; After the server is changed to a language other than 293 ; i-default, the resp-text rule from RFC 3501 is replaced 294 ; with the following: 296 resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR 297 *(UTF8-TEXT-CHAR / "[") 299 UTF8-TEXT-CHAR = %x20-%x5A / %x5C-%x7E / UTF8-2 / UTF8-3 / 300 UTF8-4 301 ; UTF-8 excluding 7-bit control characters and "[" 303 4. COMPARATOR Extension 305 IMAP4rev1 [6] includes the SEARCH command which can be used to 306 locate messages matching criteria including human-readable text. 307 The SORT extension [15] to IMAP allows the client to ask the server 308 to determine the order of messages based on criteria including 309 human-readable text. These mechanisms require the ability to 310 support non-English search and sort functions. 312 This section defines an IMAP extension to negotiate use of 313 comparators [8] to internationalize IMAP SEARCH, SORT and THREAD. 314 The IMAP extension consists of a new command to determine or change 315 the active comparator and a new response to indicate the active 316 comparator and possibly other available comparators. 318 The term "default comparator" refers to the comparator which is used 319 by SEARCH and SORT absent any negotiation using the COMPARATOR 320 command. The term "active comparator" refers to the comparator 321 which will be used within a session e.g. by SEARCH and SORT. The 322 COMPARATOR command is used to change the active comparator. 324 The active comparator applies to the following SEARCH keys: "BCC", 325 "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER". If the 326 server also advertises the "SORT" extension, then the active 327 comparator applies to the following SORT keys: "CC", "FROM", 328 "SUBJECT" and "TO". If the server advertises the 329 THREAD=ORDEREDSUBJECT, then the active comparator applies to the 330 ORDEREDSUBJECT threading algorithm. Future extensions may choose to 331 apply the active comparator to their SEARCH keys. 333 For SORT and THREAD, the pre-processing necessary to extract the 334 base subject text from a Subject header occurs prior to the 335 application of a comparator. 337 4.1 COMPARATOR Extension Requirements 339 IMAP servers that support this extension MUST list the keyword 340 COMPARATOR in their CAPABILITY data once IMAP enters authenticated 341 state, and MAY list that keyword in other states. 343 A server that advertises this extension MUST implement the en;ascii- 344 casemap and i;octet comparators, as defined in [8]. A server 345 intended to be deployed globally MUST implement the 346 i;basic;uca=3.1.1;uv=3.2 comparator. 348 A server that advertises this extension MUST use a registered case- 349 insensitive comparator which supports the substring matching 350 function as the default comparator. If the server also advertises 351 the SORT or THREAD=ORDEREDSUBJECT extensions, then the default 352 comparator MUST also support the ordering function. The selection 353 of the default comparator MAY be adjustable by the server 354 administrator, and MAY be sensitive to the current user. Once the 355 IMAP connection enters authenticated state, the default comparator 356 MUST remain static for the remainder of that connection. 358 A server that advertises this extension MUST support UTF-8 as a 359 SEARCH charset. 361 The COMPARATOR command is valid in authenticated and selected 362 states. 364 4.2 Comparators and Charsets 366 For SEARCH, SORT and THREAD operations that apply to message 367 headers, the server is responsible for removing the MIME header 368 encoding [10] and converting the text of any known charsets to UTF-8 369 prior to applying the comparator algorithm. Unknown charsets should 370 never match when using the SEARCH command, and should sort together 371 with 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 376 the text should be skipped by the SEARCH command unless the 377 comparator is 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 results in a 391 COMPARATOR response indicating the currently active comparator. 392 When issued with one or more comparator order argument, it will 393 change the active comparator if any comparator matches any argument. 394 The COMPARATOR response will list other matching comparators if more 395 than one matches the specified patterns. 397 The argument "*" refers to the server's default comparator. 398 Otherwise each argument is an comparator specification as defined in 399 the Internet Application Protocol Comparator Registry [8]. 401 < The client requests activating a Czech comparator if possible, 402 or else a generic international comparator which it considers 403 suitable for Czech. The server picks the first supported 404 comparator. > 406 C: A001 COMPARATOR cz;* i;basic* 407 S: * COMPARATOR i;basic;uca=3.1.1;uv=3.2 408 S: A001 OK Will use i;basic;uca=3.1.1;uv=3.2 for collation 409 < The client requests pure octet matching, then does a search 410 for potential GIF files, then switches back to its usual 411 comparator. > 413 C: B123 COMPARATOR i;octet 414 S: * COMPARATOR i;octet 415 S: B123 OK 416 C: B124 SEARCH OR BODY GIF87A BODY GIF89A 417 S: * SEARCH 42 69 418 S: B124 OK 419 C: B125 COMPARATOR cz;* i;basic* 420 S: * COMPARATOR i;basic;uca=3.1.1;uv=3.2 421 S: B125 OK 423 4.4 COMPARATOR Response 425 Contents: The active comparator. 426 An optional list of available matching comparators 428 The COMPARATOR response occurs as a result of a COMPARATOR command. 429 The first argument in the comparator response is the name of the 430 active comparator. The second argument is a list of comparators 431 which matched any of the arguments to the COMPARATOR command and is 432 present only if more than one match is found. 434 4.5 Formal Syntax 436 The following syntax specification inherits ABNF [2] rules from 437 IMAP4rev1 [6], and Internet Application Protocol Comparator Registry 438 [8]. 440 command-auth =/ comparator-cmd 442 resp-text-code =/ "BADCOMPARATOR" / "BADMATCH" 444 comparator-cmd = "COMPARATOR" *(SP comp-order-quoted) 446 comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "(" 447 comp-name-quoted *(SP comp-name-quoted) ")"] 449 comp-name-quoted = astring 450 ; Once any literal wrapper or quoting is removed, 451 ; this follows the comparator-name rule 453 comp-order-quoted = astring 454 ; Once any literal wrapper or quoting is removed, 455 ; this follows the comparator-order rule 457 comp-sel-quoted = astring 458 ; Once any literal wrapper or quoting is removed, 459 ; this follows the comparator-sel rule 461 5. Other IMAP Internationalization Issues 463 The following sections provide an overview of various other IMAP 464 internationalization issues. These issues are not resolved by this 465 specification, but could be resolved by future standards work. 467 5.1 Unicode Userids and Passwords 469 IMAP4rev1 presently restricts the userid and password fields of the 470 LOGIN command to US-ASCII. The "userid" and "password" fields of the 471 IMAP LOGIN command are restricted to US-ASCII only until a future 472 standards track RFC states otherwise. Servers are encouraged to 473 validate both fields to make sure they conform to the formal syntax 474 of UTF-8 and to reject the LOGIN command if that syntax is violated. 475 Servers MAY reject the use of any 8-bit in the "userid" or 476 "password" field. 478 When AUTHENTICATE is used, some servers may support userids and 479 passwords in Unicode [13]. However, such userids cannot be used as 480 email addresses, and at present also seem to be incompatible with 481 the current latest ACL drafts. Unless the ACL drafts resolve this, 482 server authors are cautioned against supporting ACL and unicode 483 userids simultaneously. 485 5.2 UTF-8 Mailbox Names 487 The modified UTF-7 mailbox naming convention described in section 488 5.1.3 of RFC 3501 is best viewed as an transition from the status 489 quo in 1996 when modified UTF-7 was first specified. At that time, 490 there was widespread unofficial use of local character sets such as 491 ISO-8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant 492 non-interoperability. 494 The requirements in section 5.1 of RFC 3501 are very important if 495 we're ever going to be able to deploy UTF-8 mailbox names. Servers 496 are encourated to enforce them. 498 5.3 UTF-8 Domains, Addresses and Mail Headers 500 There is now an IETF standard for Internationalizing Domain Names in 501 Applications [13]. While IMAP clients are free to support this 502 standard, an argument can be made that it would be helpful to simple 503 clients if the IMAP server could perform this conversion (the same 504 argument would apply to MIME header encoding [10]). However, it 505 would be unwise to move forward with such work until the work in 506 progress to define the format of international email addresses is 507 complete. 509 6. IANA Considerations 511 When this is published as an RFC, the IMAP extensions LANGUAGE and 512 COMPARATOR are registered. 514 7. Security Considerations 516 The LANGUAGE extension makes a new command available in "Not 517 Authenticated" state in IMAP. Some IMAP implementations run with 518 root privilege when the server is in "Not Authenticated" state and 519 do not revoke that privilege until after authentication is complete. 520 Such implementations are particularly vulnerable to buffer overflow 521 security errors at this stage and need to implement parsing of this 522 command with extra care. 524 A LANGUAGE command issued prior to activation of a security layer is 525 subject to an active attack which suppresses or modifies the 526 negotiation and thus makes STARTTLS or authentication error messages 527 more difficult to interpret. This is not a new attack as the error 528 messages themselves are subject to active attack. Clients MUST re- 529 issue the LANGUAGE command once a security layer is active, so this 530 does not impact subsequent protocol operations. 532 Both the LANGUAGE and COMPARATOR extensions use the UTF-8 charset, 533 thus the security considerations for UTF-8 [7] are relevent. 534 However, neither uses UTF-8 for identifiers so the most serious 535 concerns do not apply. 537 8. Acknowledgements 539 The LANGUAGE extension is based on a previous Internet draft by Mike 540 Gahrns and Alexey Melnikov, a substantial portion of the text in 541 that section was written by them. Many people have participated in 542 discussions about an IMAP Language extension in the various fora of 543 the IETF and Internet working groups, so any list of contributors is 544 bound to be incomplete. However, the authors would like to thank 545 Andrew McCown for early work on the original proposal, John Myers 546 for suggestions regarding the namespace issue, along with Jutta 547 Degener, Mark Crispin, Mark Pustilnik, Larry Osterman and Martin 548 Duerst for their many suggestions that have been incorporated into 549 this document. 551 Initial discussion of the COMPARATOR extension involved input from 552 Mark Crispin and other participants of the IMAP Extensions WG. 554 9. Relevant Standards for i18n IMAP Implementations 556 This is a non-normative list of standards to consider when 557 implementing i18n aware IMAP software. 559 o The LANGUAGE and COMPARATOR extensions to IMAP (this 560 specification). 561 o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501. 562 o The Mailbox International Naming Convention in section 5.1.3 of 563 RFC 3501. 564 o MIME [9] for message bodies. 565 o MIME header encoding [10] for message headers. 566 o MIME Parameter Value and Encoded Word Extensions [11] for 567 filenames. Quality IMAP server implementations will 568 automatically combine multipart parameters when generating the 569 BODYSTRUCTURE. There is also some deployed non-standard use of 570 MIME header encoding inside double-quotes for filenames. 571 o IDNA [13] and punycode [14] for domain names (presently only 572 relevant to IMAP clients). 573 o The UTF-8 charset [7]. 574 o The IETF policy on Character Sets and Languages [3]. 576 Normative References 578 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 579 Levels", BCP 14, RFC 2119, March 1997. 581 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 582 Specifications: ABNF", RFC 2234, November 1997. 584 [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", 585 BCP 18, RFC 2277, January 1998. 587 [4] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 588 1998. 590 [5] Alvestrand, H., "Tags for the Identification of Languages", BCP 591 47, RFC 3066, January 2001. 593 [6] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 594 4rev1", RFC 3501, March 2003. 596 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 597 63, RFC 3629, November 2003. 599 [8] Newman, C., "Internet Application Protocol Comparator 600 Registry", draft-newman-i18n-comparator-05 (work in progress), 601 May 2005. 603 Informative References 605 [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 606 Extensions (MIME) Part One: Format of Internet Message Bodies", 607 RFC 2045, November 1996. 609 [10] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 610 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 611 November 1996. 613 [11] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word 614 Extensions: Character Sets, Languages, and Continuations", RFC 615 2231, November 1997. 617 [12] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 618 Strings ("stringprep")", RFC 3454, December 2002. 620 [13] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 621 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 623 [14] Costello, A., "Punycode: A Bootstring encoding of Unicode for 624 Internationalized Domain Names in Applications (IDNA)", RFC 625 3492, March 2003. 627 [15] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL 628 - SORT AND THREAD EXTENSION", draft-ietf-imapext-sort-17 (work 629 in progress), May 2004. 631 [16] Daboo, C., "IMAP ANNOTATEMORE Extension", draft-daboo-imap- 632 annotatemore-07 (work in progress), February 2005. 634 Authors' Addresses 636 Chris Newman 637 Sun Microsystems 638 1050 Lakes Drive 639 West Covina, CA 91790 640 US 642 Email: chris.newman@sun.com 644 Arnt Gulbrandsen 645 Oryx Mail Systems GmbH 646 Schweppermannstr. 8 647 D-81781 Muenchen 648 Germany 650 Email: arnt@oryx.com 652 Phone: +49 89 4502 9757 653 Fax: +49 89 4502 9758 655 Intellectual Property Statement 657 The IETF takes no position regarding the validity or scope of any 658 Intellectual Property Rights or other rights that might be claimed 659 to pertain to the implementation or use of the technology described 660 in this document or the extent to which any license under such 661 rights might or might not be available; nor does it represent that 662 it has made any independent effort to identify any such rights. 663 Information on the procedures with respect to rights in RFC 664 documents can be found in BCP 78 and BCP 79. 666 Copies of IPR disclosures made to the IETF Secretariat and any 667 assurances of licenses to be made available, or the result of an 668 attempt made to obtain a general license or permission for the use 669 of such proprietary rights by implementers or users of this 670 specification can be obtained from the IETF on-line IPR repository 671 at http://www.ietf.org/ipr. 673 The IETF invites any interested party to bring to its attention any 674 copyrights, patents or patent applications, or other proprietary 675 rights that may cover technology that may be required to implement 676 this standard. Please address the information to the IETF at ietf- 677 ipr@ietf.org. 679 Full Copyright Statement 681 Copyright (C) The Internet Society (2005). This document is subject 682 to the rights, licenses and restrictions contained in BCP 78, and 683 except as set forth therein, the authors retain all their rights. 685 This document and the information contained herein are provided on 686 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 687 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 688 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 689 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 690 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 Acknowledgment 695 Funding for the RFC Editor function is currently provided by the 696 Internet Society.