idnits 2.17.1 draft-ietf-imapext-i18n-04.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 725. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 717), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** 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. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (October 2004) is 7133 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 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-02 -- 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-05 Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 6 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-04.txt Arnt Gulbrandsen 4 Oryx Mail Systems 5 October 2004 7 Internet Message Access Protocol Internationalization 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance 14 with RFC 3668. 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 2004. All Rights Reserved. 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 Internet-draft October 2004 49 Table of Contents 51 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. LANGUAGE Extension . . . . . . . . . . . . . . . . . . . . . 3 54 3.1 LANGUAGE Extension Requirements . . . . . . . . . . . . . . . 3 55 3.2 LANGUAGE Command . . . . . . . . . . . . . . . . . . . . . . 4 56 3.3 LANGUAGE Response . . . . . . . . . . . . . . . . . . . . . . 5 57 3.4 TRANSLATION Extension to the NAMESPACE Response . . . . . . . 6 58 3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. COMPARATOR Extension . . . . . . . . . . . . . . . . . . . . 7 60 4.1 COMPARATOR Extension Requirements . . . . . . . . . . . . . . 8 61 4.2 Comparators and Charsets . . . . . . . . . . . . . . . . . . 9 62 4.3 COMPARATOR Command . . . . . . . . . . . . . . . . . . . . . 9 63 4.4 COMPARATOR Response . . . . . . . . . . . . . . . . . . . . . 10 64 4.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Other IMAP Internationalization Issues . . . . . . . . . . . 11 66 5.1 UTF-8 Userids and Passwords . . . . . . . . . . . . . . . . . 11 67 5.2 UTF-8 Mailbox Names . . . . . . . . . . . . . . . . . . . . . 11 68 5.3 UTF-8 Domains, Addresses and Mail Headers . . . . . . . . . . 12 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 9. Relevant Standards for i18n IMAP Implementations . . . . . . 13 73 Normative References . . . . . . . . . . . . . . . . . . . . 14 74 Informative References . . . . . . . . . . . . . . . . . . . 14 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 76 Intellectual Property and Copyright Statements . . . . . . . 16 78 Conventions Used in This Document 80 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 81 in this document are to be interpreted as defined in "Key words for 82 use in RFCs to Indicate Requirement Levels" [1]. 84 The formal syntax use the Augmented Backus-Naur Form (ABNF) [2] 85 notation including the core rules defined in Appendix A of RFC 2234. 86 The UTF8-related productions are defined in RFC 3629 [7]. 88 In examples, "C:" and "S:" indicate lines sent by the client and 89 server respectively. If a single "C:" or "S:" label applies to 90 multiple lines, then the line breaks between those lines are for 91 editorial clarity only and are not part of the actual protocol 92 exchange. 94 Internet-draft October 2004 96 2. Introduction 98 This specification defines two IMAP4rev1 [6] extensions to enhance 99 international support. These extensions can be advertised and 100 implemented separately. 102 The LANGUAGE extension allows the client to request a suitable 103 language for protocol error messages and in combination with the 104 NAMESPACE extension [4] enables namespace translations. 106 The COMPARATOR extension allows the client to request a suitable 107 comparator which will modify the behavior of the base 108 specification's SEARCH command as well as the SORT and THREAD 109 extensions [15]. This leverages the comparator registry [8]. 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 [6] 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 ANNOTATEMORE 124 extension. [16] 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 [3] as its default language until another 134 supported language is negotiated by the client. A server MUST 135 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 [4] from the server. 140 The LANGUAGE command is valid in all states. 142 Internet-draft October 2004 144 3.2 LANGUAGE Command 146 Arguments: Optional language range argument. 148 Response: A possible LANGUAGE response (see Section 3.3). 149 A possible NAMESPACE response as defined by [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 the language range 157 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 specified language starting with the tagged OK 161 response to the LANGUAGE command. These responses will be in UTF-8 162 [7]. 164 If the command fails, the server will continue to return human- 165 readable responses in the language it was previously using. 167 The client MUST NOT use MUL (Multiple languages) or UND 168 (Undetermined) language tags and the server MUST return BAD if 169 either tag is used. The special "*" language range argument 170 indicates a request to use a language designated as preferred by the 171 server administrator. The preferred language MAY vary based on the 172 currently active user. 174 If the language range does not match a known language tag exactly 175 but does match a language by the rules of section 2.5 of [5], the 176 server MUST send an untagged LANGUAGE response indicating the 177 language selected. 179 If the language range argument is omitted, the server SHOULD send an 180 untagged LANGUAGE response listing the languages it supports. If 181 the server is unable to enumerate the list of languages it supports 182 it MAY return a tagged NO response to the enumeration request. 184 < The server defaults to using English i-default responses until 185 the user explicitly changes the language. > 187 C: A001 LOGIN KAREN PASSWORD 188 S: A001 OK LOGIN completed 190 < Client requested MUL language. Server MUST reply with BAD. > 192 Internet-draft October 2004 194 C: A002 LANGUAGE MUL 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 3.3 LANGUAGE Response 232 Contents: A list of one or more language tags. 234 The LANGUAGE response occurs as a result of a LANGUAGE command. A 235 LANGUAGE response with a list containing a single language tag 236 indicates that the server is now using that language. A LANGUAGE 237 response with a list containing multiple language tags indicates the 238 server is communicating a list of available languages to the client, 239 and no change in the active language has been made. 241 Internet-draft October 2004 243 3.4 TRANSLATION Extension to the NAMESPACE Response 245 If the server supports the IMAP4 NAMESPACE command [4], the server 246 MUST return an untagged NAMESPACE response when a language is 247 negotiated. However the server MUST NOT return a NAMESPACE response 248 if it is in not-authenticated state. 250 If as a result of the newly negotiated language, localized 251 representations of the namespace prefixes are available, the server 252 SHOULD include these in the TRANSLATION extension to the NAMESPACE 253 response. 255 The TRANSLATION extension to the NAMESPACE response returns a single 256 string, containing the modified UTF-7 [6] encoded translation of the 257 namespace prefix. It is the responsibility of the client to convert 258 between the namespace prefix and the translation of the namespace 259 prefix when presenting mailbox names to the user. 261 In this example a server supports the IMAP4 NAMESPACE command. It 262 uses no prefix to the user's Personal Namespace, a prefix of "Other 263 Users" to its Other Users' Namespace and a prefix of "Public 264 Folders" to its only Shared Namespace. Since a client will often 265 display these prefixes to the user, the server includes a 266 translation of them that can be presented to the user. 268 C: A001 LANGUAGE DE-IT 269 S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION" 270 ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 271 "TRANSLATION" ("Gemeinsame Mailboxen/"))) 272 S: A001 OK La Language commande a ete executee avec success 274 3.5 Formal Syntax 276 The following syntax specification inherits ABNF [2] rules from 277 IMAP4rev1 [6], IMAP4 Namespace [4], Tags for the Identification of 278 Languages [5], and UTF-8 [7]. 280 command-any =/ language-cmd 281 ; LANGUAGE command is valid in all states 283 language-cmd = "LANGUAGE" [SP lang-range-quoted] 285 language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP lang- 286 tag-quoted) ")" 288 Internet-draft October 2004 290 namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string 291 ")" 292 ; the string is encoded in Modified UTF-7. 293 ; this is a subset of the syntax permitted by 294 ; the Namespace_Response_Extension rule in RFC 2342 296 lang-range-quoted = astring 297 ; Once any literal wrapper or quoting is removed, this 298 ; follows the language-range rule in section 2.5 of RFC 3066 300 lang-tag-quoted = astring 301 ; Once any literal wrapper or quoting is removed, this 302 follows 303 ; the Language-Tag rule in section 2.1 of RFC 3066 305 ; After the server is changed to a language other than 306 ; i-default, the resp-text rule from RFC 3501 is replaced 307 ; with the following: 309 resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR 310 *(UTF8-TEXT-CHAR / "[") 312 UTF8-TEXT-CHAR = %x20-%x5A / %x5C-%x7E / UTF8-2 / UTF8-3 / 313 UTF8-4 314 ; UTF-8 excluding 7-bit control characters and "[" 316 4. COMPARATOR Extension 318 IMAP4rev1 [6] includes the SEARCH command which can be used to 319 locate messages matching criteria including human-readable text. 320 The SORT extension [15] to IMAP allows the client to ask the server 321 to determine the order of messages based on criteria including 322 human-readable text. These mechanisms require the ability to 323 support non-English search and sort functions. 325 This section defines an IMAP extension to negotiate use of 326 comparators [8] to internationalize IMAP SEARCH, SORT and THREAD. 327 The IMAP extension consists of a new command to determine or change 328 the active comparator and a new response to indicate the active 329 comparator and possibly other available comparators. 331 The term "default comparator" refers to the comparator which is used 332 by SEARCH and SORT absent any negotiation using the COMPARATOR 333 command. The term "active comparator" refers to the comparator 334 which will be used within a session e.g. by SEARCH and SORT. The 335 COMPARATOR command is used to change the active comparator. 337 Internet-draft October 2004 339 The active comparator applies to the following SEARCH keys: "BCC", 340 "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER". If the 341 server also advertises the "SORT" extension, then the active 342 comparator applies to the following SORT keys: "CC", "FROM", 343 "SUBJECT" and "TO". If the server advertises the 344 THREAD=ORDEREDSUBJECT, then the active comparator applies to the 345 ORDEREDSUBJECT threading algorithm. Future extensions may choose to 346 apply the active comparator to their SEARCH keys. 348 For SORT and THREAD, the pre-processing necessary to extract the 349 base subject text from a Subject header occurs prior to the 350 application of a comparator. 352 4.1 COMPARATOR Extension Requirements 354 IMAP servers that support this extension MUST list the keyword 355 COMPARATOR in their CAPABILITY data once IMAP enters authenticated 356 state, and MAY list that keyword in other states. 358 A server that advertises this extension MUST implement the en;ascii- 359 casemap and i;octet comparators, as defined in [8]. A server 360 intended to be deployed globally MUST implement the 361 i;basic;uca=3.1.1;uv=3.2 comparator. 363 A server that advertises this extension MUST use a registered case- 364 insensitive comparator which supports the substring matching 365 function as the default comparator. If the server also advertises 366 the SORT or THREAD=ORDEREDSUBJECT extensions, then the default 367 comparator MUST also support the ordering function. The selection 368 of the default comparator MAY be adjustable by the server 369 administrator, and MAY be sensitive to the current user. Once the 370 IMAP connection enters authenticated state, the default comparator 371 MUST remain static for the remainder of that connection. 373 A server that advertises this extension MUST support UTF-8 as a 374 SEARCH charset. 376 The COMPARATOR command is valid in authenticated and selected 377 states. 379 Internet-draft October 2004 381 4.2 Comparators and Charsets 383 For SEARCH, SORT and THREAD operations that apply to message 384 headers, the server is responsible for removing the MIME header 385 encoding [10] and converting the text of any known charsets to UTF-8 386 prior to applying the comparator algorithm. Unknown charsets should 387 never match when using the SEARCH command, and should sort together 388 with invalid comparator input for the SORT and THREAD commands. 390 When message text is in a known charset other than UTF-8, the server 391 is responsible for converting that text to UTF-8 prior to applying 392 the comparator. When message text is in an unknown charset, then 393 the text should be skipped by the SEARCH command unless the 394 comparator is i;octet. 396 4.3 COMPARATOR Command 398 Arguments: Optional comparator order arguments. 400 Response: A possible COMPARATOR response (see Section 4.4). 402 Result: OK - Command completed 403 NO - No matching comparator found 404 BAD - arguments invalid 406 The COMPARATOR command is used to determine or change the active 407 comparator. When issued with no arguments, it will result in a 408 COMPARATOR response indicating the currently active comparator. 409 When issued with one or more comparator order argument, it will 410 change the active comparator if any comparator matches any argument. 411 The COMPARATOR response will list other matching comparators if more 412 than one matches the specified patterns. 414 The argument "*" refers to the server's default comparator. 415 Otherwise each argument is an comparator specification as defined in 416 the Internet Application Protocol Comparator Registry [8]. 418 < The client requests activating a Czech comparator if possible, 419 or else a generic international comparator which it considers 420 suitable for Czech. The server picks the first supported 421 comparator. > 423 C: A001 COMPARATOR cz;* i;basic* 424 S: * COMPARATOR i;basic;uca=3.1.1;uv=3.2 425 S: A001 OK Will use i;basic;uca=3.1.1;uv=3.2 for collation 427 Internet-draft October 2004 429 < The client requests pure octet matching, then does a search 430 for potential GIF files, then switches back to its usual 431 comparator. > 433 C: B123 COMPARATOR i;octet 434 S: * COMPARATOR i;octet 435 S: B123 OK 436 C: B124 SEARCH OR BODY GIF87A BODY GIF89A 437 S: * SEARCH 42 69 438 S: B124 OK 439 C: B125 COMPARATOR cz;* i;basic* 440 S: * COMPARATOR i;basic;uca=3.1.1;uv=3.2 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 [2] rules from 457 IMAP4rev1 [6], and Internet Application Protocol Comparator Registry 458 [8]. 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, 471 ; this follows the comparator-name rule 473 Internet-draft October 2004 475 comp-order-quoted = astring 476 ; Once any literal wrapper or quoting is removed, 477 ; this follows the comparator-order rule 479 comp-sel-quoted = astring 480 ; Once any literal wrapper or quoting is removed, 481 ; this follows the comparator-sel rule 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 future standards work. 489 5.1 UTF-8 Userids and Passwords 491 IMAP4rev1 presently restricts the userid and password fields of the 492 LOGIN command to US-ASCII. Because the ability to enter a userid 493 and password is necessary to use IMAP at all for most authentication 494 mechanisms, the potential inability to enter userid and password 495 with some clients is a serious interoperability concern. However, 496 because of the visibility of these fields to end-users, it is 497 expected that supporting unicode login names and passwords will 498 eventually be practical and necessary. 500 This has been left out of this document, because the SASL-related 501 profile of stringprep [12] has not yet been published as an RFC, and 502 the impact on ACLs and email addresses has not been assessed. 504 The "userid" and "password" fields of the IMAP LOGIN command are 505 restricted to US-ASCII only until a future standards track RFC 506 states otherwise. Servers are encouraged to validate both fields to 507 make sure they conform to the formal syntax of UTF-8 and to reject 508 the LOGIN command if that syntax is violated. Servers MAY reject 509 the use of any 8-bit in the "userid" or "password" field. 511 5.2 UTF-8 Mailbox Names 513 The modified UTF-7 mailbox naming convention described in section 514 5.1.3 of RFC 3501 is best viewed as an transition from the status 515 quo in 1996 when modified UTF-7 was first specified. At that time, 516 there was widespread unofficial use of local character sets such as 517 ISO-8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant 518 non-interoperability. 520 Internet-draft October 2004 522 The requirements in section 5.1 of RFC 3501 are very important if 523 we're ever going to be able to deploy UTF-8 mailbox names. Servers 524 are encourated to enforce them. 526 5.3 UTF-8 Domains, Addresses and Mail Headers 528 There is now an IETF standard for Internationalizing Domain Names in 529 Applications [13]. While IMAP clients are free to support this 530 standard, an argument can be made that it would be helpful to simple 531 clients if the IMAP server could perform this conversion (the same 532 argument would apply to MIME header encoding [10]). However, it 533 would be unwise to move forward with such work until the work in 534 progress to define the format of international email addresses is 535 complete. 537 6. IANA Considerations 539 When this is published as an RFC, the IMAP extensions LANGUAGE and 540 COMPARATOR are registered. 542 7. Security Considerations 544 The LANGUAGE extension makes a new command available in "Not 545 Authenticated" state in IMAP. Some IMAP implementations run with 546 root privilege when the server is in "Not Authenticated" state and 547 do not revoke that privilege until after authentication is complete. 548 Such implementations are particularly vulnerable to buffer overflow 549 security errors at this stage and need to implement parsing of this 550 command with extra care. 552 A LANGUAGE command issued prior to activation of a security layer is 553 subject to an active attack which suppresses or modifies the 554 negotiation and thus makes STARTTLS or authentication error messages 555 more difficult to interpret. This is not a new attack as the error 556 messages themselves are subject to active attack. Clients MUST re- 557 issue the LANGUAGE command once a security layer is active, so this 558 does not impact subsequent protocol operations. 560 Both the LANGUAGE and COMPARATOR extensions use the UTF-8 charset, 561 thus the security considerations for UTF-8 [7] are relevent. 562 However, neither uses UTF-8 for identifiers so the most serious 563 concerns do not apply. 565 Internet-draft October 2004 567 8. Acknowledgements 569 The LANGUAGE extension is based on a previous Internet draft by Mike 570 Gahrns and Alexey Melnikov, a substantial portion of the text in 571 that section was written by them. Many people have participated in 572 discussions about an IMAP Language extension in the various fora of 573 the IETF and Internet working groups, so any list of contributors is 574 bound to be incomplete. However, the authors would like to thank 575 Andrew McCown for early work on the original proposal, John Myers 576 for suggestions regarding the namespace issue, along with Jutta 577 Degener, Mark Crispin, Mark Pustilnik, Larry Osterman and Martin 578 Duerst for their many suggestions that have been incorporated into 579 this document. 581 Initial discussion of the COMPARATOR extension involved input from 582 Mark Crispin and other participants of the IMAP Extensions WG. 584 9. Relevant Standards for i18n IMAP Implementations 586 This is a non-normative list of standards to consider when 587 implementing i18n aware IMAP software. 589 o The LANGUAGE and COMPARATOR extensions to IMAP (this 590 specification). 591 o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501. 592 o The Mailbox International Naming Convention in section 5.1.3 of 593 RFC 3501. 594 o MIME [9] for message bodies. 595 o MIME header encoding [10] for message headers. 596 o MIME Parameter Value and Encoded Word Extensions [11] for 597 filenames. Quality IMAP server implementations will 598 automatically combine multipart parameters when generating the 599 BODYSTRUCTURE. There is also some deployed non-standard use of 600 MIME header encoding inside double-quotes for filenames. 601 o IDNA [13] and punycode [14] for domain names (presently only 602 relevant to IMAP clients). 603 o The UTF-8 charset [7]. 604 o The IETF policy on Character Sets and Languages [3]. 606 Internet-draft October 2004 608 Normative References 610 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 611 Levels", BCP 14, RFC 2119, March 1997. 613 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 614 Specifications: ABNF", RFC 2234, November 1997. 616 [3] Alvestrand, H., "IETF Policy on Character Sets and Languages", 617 BCP 18, RFC 2277, January 1998. 619 [4] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 620 1998. 622 [5] Alvestrand, H., "Tags for the Identification of Languages", BCP 623 47, RFC 3066, January 2001. 625 [6] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 626 4rev1", RFC 3501, March 2003. 628 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 629 63, RFC 3629, November 2003. 631 [8] Newman, C., "Internet Application Protocol Comparator 632 Registry", draft-newman-i18n-comparator-02 (work in progress), 633 July 2004. 635 Informative References 637 [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 638 Extensions (MIME) Part One: Format of Internet Message Bodies", 639 RFC 2045, November 1996. 641 [10] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 642 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 643 November 1996. 645 [11] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word 646 Extensions: Character Sets, Languages, and Continuations", RFC 647 2231, November 1997. 649 [12] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 650 Strings ("stringprep")", RFC 3454, December 2002. 652 [13] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 653 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 655 Internet-draft October 2004 657 [14] Costello, A., "Punycode: A Bootstring encoding of Unicode for 658 Internationalized Domain Names in Applications (IDNA)", RFC 659 3492, March 2003. 661 [15] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL 662 - SORT AND THREAD EXTENSION", draft-ietf-imapext-sort-17 (work 663 in progress), May 2004. 665 [16] Daboo, C., "IMAP ANNOTATEMORE Extension", draft-daboo-imap- 666 annotatemore-05 (work in progress), April 2004. 668 Authors' Addresses 670 Chris Newman 671 Sun Microsystems 672 1050 Lakes Drive 673 West Covina, CA 91790 674 US 676 Email: chris.newman@sun.com 678 Arnt Gulbrandsen 679 Oryx Mail Systems GmbH 680 Joseph-Dollinger-Bogen 14 681 D-80807 Muenchen 682 Germany 684 Email: arnt@oryx.com 686 Phone: +49 89 32356-401 687 Fax: +49 89 32356-409 689 Internet-draft October 2004 691 Intellectual Property Statement 693 The IETF takes no position regarding the validity or scope of any 694 intellectual property or other rights that might be claimed to 695 pertain to the implementation or use of the technology described in 696 this document or the extent to which any license under such rights 697 might or might not be available; neither does it represent that it 698 has made any effort to identify any such rights. Information on the 699 IETF's procedures with respect to rights in standards-track and 700 standards-related documentation can be found in BCP-11. Copies of 701 claims of rights made available for publication and any assurances 702 of licenses to be made available, or the result of an attempt made 703 to obtain a general license or permission for the use of such 704 proprietary rights by implementors or users of this specification 705 can be obtained from the IETF Secretariat. 707 The IETF invites any interested party to bring to its attention any 708 copyrights, patents or patent applications, or other proprietary 709 rights which may cover technology that may be required to practice 710 this standard. Please address the information to the IETF Executive 711 Director. 713 Full Copyright Statement 715 Copyright (C) The Internet Society (2004). This document is subject 716 to the rights, licenses and restrictions contained in BCP 78, and 717 except as set forth therein, the authors retain all their rights. 719 This document and the information contained herein are provided on 720 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 721 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 722 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 723 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 724 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 725 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 727 Acknowledgment 729 Funding for the RFC Editor function is currently provided by the 730 Internet Society.