imapext-2007
diff docs/draft/i18n.txt @ 0:ada5e610ab86
imap-2007e
| author | yuuji@gentei.org |
|---|---|
| date | Mon, 14 Sep 2009 15:17:45 +0900 |
| parents | |
| children |
line diff
1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 1.2 +++ b/docs/draft/i18n.txt Mon Sep 14 15:17:45 2009 +0900 1.3 @@ -0,0 +1,1140 @@ 1.4 + 1.5 + 1.6 + 1.7 + 1.8 + 1.9 + 1.10 +Network Working Group Chris Newman 1.11 +Internet-Draft Sun Microsystems 1.12 +Intended Status: Proposed Standard Arnt Gulbrandsen 1.13 + Oryx Mail Systems GmhH 1.14 + Alexey Melnikov 1.15 + Isode Limited 1.16 + February 1, 2008 1.17 + 1.18 + Internet Message Access Protocol Internationalization 1.19 + draft-ietf-imapext-i18n-15.txt 1.20 + 1.21 + 1.22 +Status of this Memo 1.23 + By submitting this Internet-Draft, each author represents that any 1.24 + applicable patent or other IPR claims of which he or she is aware 1.25 + have been or will be disclosed, and any of which he or she becomes 1.26 + aware will be disclosed, in accordance with Section 6 of BCP 79. 1.27 + 1.28 + Internet-Drafts are working documents of the Internet Engineering 1.29 + Task Force (IETF), its areas, and its working groups. Note that 1.30 + other groups may also distribute working documents as Internet- 1.31 + Drafts. 1.32 + 1.33 + Internet-Drafts are draft documents valid for a maximum of six 1.34 + months and may be updated, replaced, or obsoleted by other documents 1.35 + at any time. It is inappropriate to use Internet-Drafts as 1.36 + reference material or to cite them other than as "work in progress". 1.37 + 1.38 + The list of current Internet-Drafts can be accessed at 1.39 + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 1.40 + Draft Shadow Directories can be accessed at 1.41 + http://www.ietf.org/shadow.html. 1.42 + 1.43 + This Internet-Draft expires in August 2008. 1.44 + 1.45 + 1.46 +Copyright Notice 1.47 + 1.48 + Copyright (C) The IETF Trust (2008). 1.49 + 1.50 + 1.51 +Abstract 1.52 + 1.53 + Internet Message Access Protocol (IMAP) version 4rev1 has basic 1.54 + support for non-ASCII characters in mailbox names and search 1.55 + substrings. It also supports non-ASCII message headers and content 1.56 + encoded as specified by Multipurpose Internet Mail Extensions 1.57 + (MIME). This specification defines a collection of IMAP extensions 1.58 + 1.59 + 1.60 + 1.61 +Newman & Co Expires August 2008 FF[Page 1] 1.62 + 1.63 + 1.64 + 1.65 + 1.66 + 1.67 +Internet-draft February 2008 1.68 + 1.69 + 1.70 + which improve international support including comparator negotiation 1.71 + for search, sort and thread, language negotiation for international 1.72 + error text, and translations for namespace prefixes. 1.73 + 1.74 + 1.75 +Table of Contents 1.76 + 1.77 + 1. Conventions Used in this Document . . . . . . . . . . . . . . 2 1.78 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.79 + 3. LANGUAGE Extension . . . . . . . . . . . . . . . . . . . . . 3 1.80 + 3.1 LANGUAGE Extension Requirements . . . . . . . . . . . . . . . 3 1.81 + 3.2 LANGUAGE Command . . . . . . . . . . . . . . . . . . . . . . 4 1.82 + 3.3 LANGUAGE Response . . . . . . . . . . . . . . . . . . . . . . 6 1.83 + 3.4 TRANSLATION Extension to the NAMESPACE Response . . . . . . . 6 1.84 + 3.5 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 1.85 + 4. I18NLEVEL=1 and I18NLEVEL=2 Extensions . . . . . . . . . . . 7 1.86 + 4.1 Introduction and Overview . . . . . . . . . . . . . . . . . . 8 1.87 + 4.2 Requirements common to both I18NLEVEL=1 and I18NLEVEL=2 . . . 1.88 + 4.3 I18NLEVEL=1 Extension Requirements . . . . . . . . . . . . . 8 1.89 + 4.4 I18NLEVEL=2 Extension Requirements . . . . . . . . . . . . . 8 1.90 + 4.5 Compatibility Notes 1.91 + 4.6 Comparators and Charsets . . . . . . . . . . . . . . . . . . 9 1.92 + 4.7 COMPARATOR Command . . . . . . . . . . . . . . . . . . . . . 9 1.93 + 4.8 COMPARATOR Response . . . . . . . . . . . . . . . . . . . . . 10 1.94 + 4.9 BADCOMPARATOR Response Code . . . . . . . . . . . . . . . . . 1.95 + 4.10 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 10 1.96 + 5. Other IMAP Internationalization Issues . . . . . . . . . . . 11 1.97 + 5.1 UTF-8 Userids and Passwords . . . . . . . . . . . . . . . . . 11 1.98 + 5.2 UTF-8 Mailbox Names . . . . . . . . . . . . . . . . . . . . . 11 1.99 + 5.3 UTF-8 Domains, Addresses and Mail Headers . . . . . . . . . . 11 1.100 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 1.101 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 1.102 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 1.103 + 9. Relevant Standards for i18n IMAP Implementations . . . . . . 13 1.104 + Normative References . . . . . . . . . . . . . . . . . . . . 13 1.105 + Informative References . . . . . . . . . . . . . . . . . . . 14 1.106 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 1.107 + Intellectual Property and Copyright Statements . . . . . . . 16 1.108 + 1.109 + 1.110 +Conventions Used in This Document 1.111 + 1.112 + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1.113 + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1.114 + document are to be interpreted as described in [RFC2119]. 1.115 + 1.116 + The formal syntax use the Augmented Backus-Naur Form (ABNF) 1.117 + [RFC4234] notation including the core rules defined in Appendix A. 1.118 + 1.119 + 1.120 + 1.121 +Newman & Co Expires August 2008 FF[Page 2] 1.122 + 1.123 + 1.124 + 1.125 + 1.126 + 1.127 +Internet-draft February 2008 1.128 + 1.129 + 1.130 + The UTF8-related productions are defined in [RFC3629]. 1.131 + 1.132 + In examples, "C:" and "S:" indicate lines sent by the client and 1.133 + server respectively. If a single "C:" or "S:" label applies to 1.134 + multiple lines, then the line breaks between those lines are for 1.135 + editorial clarity only and are not part of the actual protocol 1.136 + exchange. 1.137 + 1.138 + 1.139 +2. Introduction 1.140 + 1.141 + This specification defines two IMAP4rev1 [RFC3501] extensions to 1.142 + enhance international support. These extensions can be advertised 1.143 + and implemented separately. 1.144 + 1.145 + The LANGUAGE extension allows the client to request a suitable 1.146 + language for protocol error messages and in combination with the 1.147 + NAMESPACE extension [RFC2342] enables namespace translations. 1.148 + 1.149 + The I18NLEVEL=2 extension allows the client to request a suitable 1.150 + collation which will modify the behavior of the base specification's 1.151 + SEARCH command as well as the SORT and THREAD extensions [SORT]. 1.152 + This leverages the collation registry [RFC4790]. 1.153 + 1.154 + 1.155 +3. LANGUAGE Extension 1.156 + 1.157 + IMAP allows server responses to include human-readable text that in 1.158 + many cases needs to be presented to the user. But that text is 1.159 + limited to US-ASCII by the IMAP specification [RFC3501] in order to 1.160 + preserve backwards compatibility with deployed IMAP implementations. 1.161 + This section specifies a way for an IMAP client to negotiate which 1.162 + language the server should use when sending human-readable text. 1.163 + 1.164 + The LANGUAGE extension only provides a mechanism for altering fixed 1.165 + server strings such as response text and NAMESPACE folder names. 1.166 + Assigning localized language aliases to shared mailboxes would be 1.167 + done with a separate mechanism such as the proposed METADATA 1.168 + extension (see [METADATA]). 1.169 + 1.170 + 1.171 +3.1 LANGUAGE Extension Requirements 1.172 + 1.173 + IMAP servers that support this extension MUST list the keyword 1.174 + LANGUAGE in their CAPABILITY response as well as in the greeting 1.175 + CAPABILITY data. 1.176 + 1.177 + A server that advertises this extension MUST use the language "i- 1.178 + 1.179 + 1.180 + 1.181 +Newman & Co Expires August 2008 FF[Page 3] 1.182 + 1.183 + 1.184 + 1.185 + 1.186 + 1.187 +Internet-draft February 2008 1.188 + 1.189 + 1.190 + default" as described in [RFC2277] as its default language until 1.191 + another supported language is negotiated by the client. A server 1.192 + MUST include "i-default" as one of its supported languages. 1.193 + 1.194 + Clients and servers that support this extension MUST also support 1.195 + the NAMESPACE extension [RFC2342]. 1.196 + 1.197 + The LANGUAGE command is valid in all states. Clients are urged to 1.198 + issue LANGUAGE before authentication, since some servers send 1.199 + valuable user information as part of authentication (e.g. "password 1.200 + is correct, but expired"). If a security layer (such as SASL or 1.201 + TLS) is subsequently negotiated by the client, it MUST re-issue the 1.202 + LANGUAGE command in order to make sure that no previous active 1.203 + attack (if any) on LANGUAGE negotiation has effect on subsequent 1.204 + error messages. (See Section 7 for a more detailed explanation of 1.205 + the attack.) 1.206 + 1.207 + 1.208 + 1.209 +3.2 LANGUAGE Command 1.210 + 1.211 + Arguments: Optional language range arguments. 1.212 + 1.213 + Response: A possible LANGUAGE response (see section 3.3). 1.214 + A possible NAMESPACE response (see section 3.4). 1.215 + 1.216 + Result: OK - Command completed 1.217 + NO - Could not complete command 1.218 + BAD - arguments invalid 1.219 + 1.220 + The LANGUAGE command requests that human-readable text emitted by 1.221 + the server be localized to a language matching one of the language 1.222 + range argument as described by section 2 of [RFC4647]. 1.223 + 1.224 + If the command succeeds, the server will return human-readable 1.225 + responses in the first supported language specified. These 1.226 + responses will be in UTF-8 [RFC3629]. The server MUST send a 1.227 + LANGUAGE response specifying the language used, and the change takes 1.228 + effect immediately after the LANGUAGE response. 1.229 + 1.230 + If the command fails, the server continues to return human-readable 1.231 + responses in the language it was previously using. 1.232 + 1.233 + The special "default" language range argument indicates a request to 1.234 + use a language designated as preferred by the server administrator. 1.235 + The preferred language MAY vary based on the currently active user. 1.236 + 1.237 + If a language range does not match a known language tag exactly but 1.238 + 1.239 + 1.240 + 1.241 +Newman & Co Expires August 2008 FF[Page 4] 1.242 + 1.243 + 1.244 + 1.245 + 1.246 + 1.247 +Internet-draft February 2008 1.248 + 1.249 + 1.250 + does match a language by the rules of [RFC4647], the server MUST 1.251 + send an untagged LANGUAGE response indicating the language selected. 1.252 + 1.253 + If there aren't any arguments, the server SHOULD send an untagged 1.254 + LANGUAGE response listing the languages it supports. If the server 1.255 + is unable to enumerate the list of languages it supports it MAY 1.256 + return a tagged NO response to the enumeration request. 1.257 + 1.258 + < The server defaults to using English i-default responses until 1.259 + the user explicitly changes the language. > 1.260 + 1.261 + C: A001 LOGIN KAREN PASSWORD 1.262 + S: A001 OK LOGIN completed 1.263 + 1.264 + < Client requested MUL language, which no server supports. > 1.265 + 1.266 + C: A002 LANGUAGE MUL 1.267 + S: A002 NO Unsupported language MUL 1.268 + 1.269 + < A LANGUAGE command with no arguments is a request to enumerate 1.270 + the list of languages the server supports. > 1.271 + 1.272 + C: A003 LANGUAGE 1.273 + S: * LANGUAGE (EN DE IT i-default) 1.274 + S: A003 OK Supported languages have been enumerated 1.275 + 1.276 + C: B001 LANGUAGE 1.277 + S: B001 NO Server is unable to enumerate supported languages 1.278 + 1.279 + < Once the client changes the language, all responses will be in 1.280 + that language starting after the LANGUAGE response. Note that 1.281 + this includes the NAMESPACE response. Because RFCs are in US- 1.282 + ASCII, this document uses an ASCII transcription rather than 1.283 + UTF-8 text, e.g. ue in the word "ausgefuehrt" > 1.284 + 1.285 + C: C001 LANGUAGE DE 1.286 + S: * LANGUAGE (DE) 1.287 + S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION" 1.288 + ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 1.289 + "TRANSLATION" ("Gemeinsame Postf&AM8-cher/"))) 1.290 + S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 1.291 + 1.292 + < If a server does not support the requested primary language, 1.293 + responses will continue to be returned in the current language 1.294 + the server is using. > 1.295 + 1.296 + C: D001 LANGUAGE FR 1.297 + S: D001 NO Diese Sprache ist nicht unterstuetzt 1.298 + 1.299 + 1.300 + 1.301 +Newman & Co Expires August 2008 FF[Page 5] 1.302 + 1.303 + 1.304 + 1.305 + 1.306 + 1.307 +Internet-draft February 2008 1.308 + 1.309 + 1.310 + C: D002 LANGUAGE DE-IT 1.311 + S: * LANGUAGE (DE-IT) 1.312 + S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION" 1.313 + ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 1.314 + "TRANSLATION" ("Gemeinsame Postf&AM8-cher/"))) 1.315 + S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 1.316 + C: D003 LANGUAGE "default" 1.317 + S: * LANGUAGE (DE) 1.318 + S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt 1.319 + 1.320 + < Server does not speak French, but does speak English. User 1.321 + speaks Canadian French and Canadian English. > 1.322 + 1.323 + C: E001 LANGUAGE FR-CA EN-CA 1.324 + S: * LANGUAGE (EN) 1.325 + S: E001 OK Now speaking English 1.326 + 1.327 + 1.328 + 1.329 +3.3 LANGUAGE Response 1.330 + 1.331 + Contents: A list of one or more language tags. 1.332 + 1.333 + The LANGUAGE response occurs as a result of a LANGUAGE command. A 1.334 + LANGUAGE response with a list containing a single language tag 1.335 + indicates that the server is now using that language. A LANGUAGE 1.336 + response with a list containing multiple language tags indicates the 1.337 + server is communicating a list of available languages to the client, 1.338 + and no change in the active language has been made. 1.339 + 1.340 + 1.341 +3.4 TRANSLATION Extension to the NAMESPACE Response 1.342 + 1.343 + If localized representations of the namespace prefixes are available 1.344 + in the selected language, the server SHOULD include these in the 1.345 + TRANSLATION extension to the NAMESPACE response. 1.346 + 1.347 + The TRANSLATION extension to the NAMESPACE response returns a single 1.348 + string, containing the modified UTF-7 [RFC3501] encoded translation 1.349 + of the namespace prefix. It is the responsibility of the client to 1.350 + convert between the namespace prefix and the translation of the 1.351 + namespace prefix when presenting mailbox names to the user. 1.352 + 1.353 + In this example a server supports the IMAP4 NAMESPACE command. It 1.354 + uses no prefix to the user's Personal Namespace, a prefix of "Other 1.355 + Users" to its Other Users' Namespace and a prefix of "Public 1.356 + Folders" to its only Shared Namespace. Since a client will often 1.357 + display these prefixes to the user, the server includes a 1.358 + 1.359 + 1.360 + 1.361 +Newman & Co Expires August 2008 FF[Page 6] 1.362 + 1.363 + 1.364 + 1.365 + 1.366 + 1.367 +Internet-draft February 2008 1.368 + 1.369 + 1.370 + translation of them that can be presented to the user. 1.371 + 1.372 + C: A001 LANGUAGE DE-IT 1.373 + S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION" 1.374 + ("Andere Ben&APw-tzer/"))) (("Public Folders/" "/" 1.375 + "TRANSLATION" ("Gemeinsame Postf&AM8-cher/"))) 1.376 + S: A001 OK LANGUAGE-Befehl ausgefuehrt 1.377 + 1.378 + 1.379 +3.5 Formal Syntax 1.380 + 1.381 + The following syntax specification inherits ABNF [RFC4234] rules 1.382 + from IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the 1.383 + Identifying Languages [RFC4646], UTF-8 [RFC3629] and Collected 1.384 + Extensions to IMAP4 ABNF [RFC4466]. 1.385 + 1.386 + command-any =/ language-cmd 1.387 + ; LANGUAGE command is valid in all states 1.388 + 1.389 + language-cmd = "LANGUAGE" *(SP lang-range-quoted) 1.390 + 1.391 + response-payload =/ language-data 1.392 + 1.393 + language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP 1.394 + lang-tag-quoted) ")" 1.395 + 1.396 + namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")" 1.397 + ; the string is encoded in Modified UTF-7. 1.398 + ; this is a subset of the syntax permitted by 1.399 + ; the Namespace-Response-Extension rule in [RFC4466] 1.400 + 1.401 + lang-range-quoted = astring 1.402 + ; Once any literal wrapper or quoting is removed, this 1.403 + ; follows the language-range rule in [RFC4647] 1.404 + 1.405 + lang-tag-quoted = astring 1.406 + ; Once any literal wrapper or quoting is removed, this follows 1.407 + ; the Language-Tag rule in [RFC4646] 1.408 + 1.409 + resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR 1.410 + *(UTF8-TEXT-CHAR / "[") 1.411 + ; After the server is changed to a language other than 1.412 + ; i-default, this resp-text rule replaces the resp-text 1.413 + ; rule from [RFC3501]. 1.414 + 1.415 + UTF8-TEXT-CHAR = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4 1.416 + ; UTF-8 excluding 7-bit control characters and "[" 1.417 + 1.418 + 1.419 + 1.420 + 1.421 +Newman & Co Expires August 2008 FF[Page 7] 1.422 + 1.423 + 1.424 + 1.425 + 1.426 + 1.427 +Internet-draft February 2008 1.428 + 1.429 + 1.430 +4. I18NLEVEL=1 and I18NLEVEL=2 Extensions 1.431 + 1.432 + 1.433 +4.1 Introduction and Overview 1.434 + 1.435 + IMAP4rev1 [RFC3501] includes the SEARCH command which can be used to 1.436 + locate messages matching criteria including human-readable text. 1.437 + The SORT extension [SORT] to IMAP allows the client to ask the 1.438 + server to determine the order of messages based on criteria 1.439 + including human-readable text. These mechanisms require the ability 1.440 + to support non-English search and sort functions. 1.441 + 1.442 + Section 4 defines two IMAP extensions for internationalizing IMAP 1.443 + SEARCH, SORT and THREAD [SORT] using the comparator framework 1.444 + [RFC4790]. 1.445 + 1.446 + The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use 1.447 + i;unicode-casemap comparator, as defined in [UCM]. See Sections 4.2 1.448 + and 4.3 for more details. 1.449 + 1.450 + The I18NLEVEL=2 extension is a superset of the I18NLEVEL=1 1.451 + extension. It adds to I18NLEVEL=1 extension the ability to determine 1.452 + the active comparator (see definition below) and negotiate use of 1.453 + comparators using the COMPARATOR command. It also adds the 1.454 + COMPARATOR response that indicates the active comparator and 1.455 + possibly other available comparators. See Sections 4.2 and 4.4 for 1.456 + more details. 1.457 + 1.458 + 1.459 +4.2 Requirements common to both I18NLEVEL=1 and I18NLEVEL=2 1.460 + 1.461 + The term "default comparator" refers to the comparator which is used 1.462 + by SEARCH and SORT absent any negotiation using the COMPARATOR (see 1.463 + Section 4.7) command. The term "active comparator" refers to the 1.464 + comparator which will be used within a session e.g. by SEARCH and 1.465 + SORT. The COMPARATOR command is used to change the active 1.466 + comparator. 1.467 + 1.468 + The active comparator applies to the following SEARCH keys: "BCC", 1.469 + "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO" and "HEADER". If the 1.470 + server also advertises the "SORT" extension, then the active 1.471 + comparator applies to the following SORT keys: "CC", "FROM", 1.472 + "SUBJECT" and "TO". If the server advertises THREAD=ORDEREDSUBJECT, 1.473 + then the active comparator applies to the ORDEREDSUBJECT threading 1.474 + algorithm. If the server advertises THREAD=REFERENCES, then the 1.475 + active comparator applies to the subject field comparisons done by 1.476 + REFERENCES threading algorithm. Future extensions may choose to 1.477 + apply the active comparator to their SEARCH keys. 1.478 + 1.479 + 1.480 + 1.481 +Newman & Co Expires August 2008 FF[Page 8] 1.482 + 1.483 + 1.484 + 1.485 + 1.486 + 1.487 +Internet-draft February 2008 1.488 + 1.489 + 1.490 + For SORT and THREAD, the pre-processing necessary to extract the 1.491 + base subject text from a Subject header occurs prior to the 1.492 + application of a comparator. 1.493 + 1.494 + A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST 1.495 + implement the i;unicode-casemap comparator, as defined in [UCM]. 1.496 + 1.497 + A server that advertises I18NLEVEL=1 or I18NLEVEL=2 extension MUST 1.498 + support UTF-8 as a SEARCH charset. 1.499 + 1.500 + 1.501 +4.3 I18NLEVEL=1 Extension Requirements 1.502 + 1.503 + An IMAP server that satisfies all requirements specified in sections 1.504 + 4.2 and 4.6 (and doesn't support/advertise any other I18NLEVEL=<n> 1.505 + extension, where n > 1) MUST list the keyword I18NLEVEL=1 in its 1.506 + CAPABILITY data once IMAP enters the authenticated state, and MAY 1.507 + list that keyword in other states. 1.508 + 1.509 + 1.510 + 1.511 +4.4 I18NLEVEL=2 Extension Requirements 1.512 + 1.513 + IMAP server that satisfies all requirements specified in sections 1.514 + 4.2, 4.4, 4.6-4.10 (and doesn't support/advertise any other 1.515 + I18NLEVEL=<n> extension, where n > 2) MUST list the keyword 1.516 + I18NLEVEL=2 in its CAPABILITY data once IMAP enters the 1.517 + authenticated state, and MAY list that keyword in other states. 1.518 + 1.519 + A server that advertises this extension MUST implement the 1.520 + i;unicode-casemap comparator, as defined in [UCM]. It MAY implement 1.521 + other comparators from the IANA registry established by [RFC4790]. 1.522 + See also section 4.5 of this document. 1.523 + 1.524 + A server that advertises this extension SHOULD use i;unicode-casemap 1.525 + as the default comparator. (Note that i;unicode-casemap is the 1.526 + default comparator for I18NLEVEL=1, but not necessarily the default 1.527 + for I18NLEVEL=2.) The selection of the default comparator MAY be 1.528 + adjustable by the server administrator, and MAY be sensitive to the 1.529 + current user. Once the IMAP connection enters authenticated state, 1.530 + the default comparator MUST remain static for the remainder of that 1.531 + connection. 1.532 + 1.533 + Note that since SEARCH uses the substring operation, IMAP servers 1.534 + can only implement collations that offer the substring operation 1.535 + (see [RFC4790 section 4.2.2). Since SORT uses ordering operation 1.536 + (and by implication equality), IMAP servers which advertise the SORT 1.537 + extension can only implement collations that offer all three 1.538 + 1.539 + 1.540 + 1.541 +Newman & Co Expires August 2008 FF[Page 9] 1.542 + 1.543 + 1.544 + 1.545 + 1.546 + 1.547 +Internet-draft February 2008 1.548 + 1.549 + 1.550 + operations (see [RFC4790] sections 4.2.2-4). 1.551 + 1.552 + If the active collation does not provide the operations needed by an 1.553 + IMAP command, the server MUST respond with a tagged BAD. 1.554 + 1.555 + 1.556 +4.5 Compatibility Notes 1.557 + 1.558 + Several server implementations deployed prior to the publication of 1.559 + this specification comply with I18NLEVEL=1 (see section 4.3), but do 1.560 + not advertise that. Other legacy servers use the i;ascii-casemap 1.561 + (see [RFC4790]) comparator. 1.562 + 1.563 + There is no good way for a client to know which comparator that a 1.564 + legacy server uses. If the client has to assume the worst, it may 1.565 + end up doing expensive local operations to obtain i;unicode-casemap 1.566 + comparisons even though the server implements it. 1.567 + 1.568 + Legacy server implementations which comply with I18NLEVEL=1 should 1.569 + be updated to advertise I18NLEVEL=1. All server implementations 1.570 + should eventually be updated to comply with the I18NLEVEL=2 1.571 + extension. 1.572 + 1.573 + 1.574 +4.6 Comparators and Character Encodings 1.575 + 1.576 + RFC 3501, section 6.4.4 says: 1.577 + 1.578 + In all search keys that use strings, a message matches 1.579 + the key if the string is a substring of the field. The 1.580 + matching is case-insensitive. 1.581 + 1.582 + When performing the SEARCH operation, the active comparator is 1.583 + applied instead of the case-insensitive matching specified above. 1.584 + 1.585 + An IMAP server which performs collation operations (e.g., as part of 1.586 + commands such as SEARCH, SORT, THREAD) does so according to the 1.587 + following procedure: 1.588 + 1.589 + (a) MIME encoding (for example see [RFC2047] for headers and 1.590 + [RFC2045] for body parts) MUST be removed in the texts being 1.591 + collated. 1.592 + 1.593 + If MIME encoding removal fails for a message (e.g., a body part 1.594 + of the message has an unsupported Content-Transfer-Encoding, 1.595 + uses characters not allowed by the Content-Transfer-Encoding, 1.596 + etc.), the collation of this message is undefined by this 1.597 + specification, and is handled in an implementation-dependent 1.598 + 1.599 + 1.600 + 1.601 +Newman & Co Expires August 2008 FF[Page 10] 1.602 + 1.603 + 1.604 + 1.605 + 1.606 + 1.607 +Internet-draft February 2008 1.608 + 1.609 + 1.610 + manner. 1.611 + 1.612 + (b) The decoded text from (a) MUST be converted to the charset 1.613 + expected by the active comparator. 1.614 + 1.615 + (c) For the substring operation: 1.616 + If step (b) failed (e.g., the text is in an unknown charset, 1.617 + contains a sequence which is not valid according in that 1.618 + charset, etc.), the original decoded text from (a) (i.e., 1.619 + before the charset conversion attempt) is collated using the 1.620 + i;octet comparator (see [RFC4790]). 1.621 + 1.622 + If step (b) was successful, the converted text from (b) is 1.623 + collated according to the active comparator. 1.624 + 1.625 + 1.626 + For the ordering operation: 1.627 + 1.628 + All strings that were successfully converted by step (b) are 1.629 + separated from all strings that failed step (b). Strings in 1.630 + each group are collated independently. All strings successfully 1.631 + converted by step (b) are then validated by the active 1.632 + comparator. Strings that pass validation are collated using the 1.633 + active comparator. All strings that either fail step (b) or fail 1.634 + the active collation's validity operation are collated (after 1.635 + applying step (a)) using the i;octet comparator (see [RFC4790]). 1.636 + The resulting sorted list is produced by appending all collated 1.637 + "failed" strings after all strings collated using the active 1.638 + comparator. 1.639 + 1.640 + 1.641 + Example: The following example demonstrates ordering of 4 1.642 + different strings using i;unicode-casemap [UCM] comparator. 1.643 + Strings are represented using hexadecimal notation used by 1.644 + ABNF [RFC4234]. 1.645 + 1.646 + (1) %xD0 %xC0 %xD0 %xBD %xD0 %xB4 %xD1 %x80 %xD0 %xB5 1.647 + %xD0 %xB9 (labeled with charset=UTF-8) 1.648 + (2) %xD1 %x81 %xD0 %x95 %xD0 %xA0 %xD0 %x93 %xD0 %x95 1.649 + %xD0 %x99 (labeled with charset=UTF-8) 1.650 + (3) %xD0 %x92 %xD0 %xB0 %xD1 %x81 %xD0 %xB8 %xD0 %xBB 1.651 + %xD0 %xB8 %xFF %xB9 (labeled with charset=UTF-8) 1.652 + (4) %xE1 %xCC %xC5 %xCB %xD3 %xC5 %xCA (labeled with 1.653 + charset=KOI8-R) 1.654 + 1.655 + Step (b) will convert string # 4 to the following 1.656 + sequence of octets (in UTF-8): 1.657 + 1.658 + 1.659 + 1.660 + 1.661 +Newman & Co Expires August 2008 FF[Page 11] 1.662 + 1.663 + 1.664 + 1.665 + 1.666 + 1.667 +Internet-draft February 2008 1.668 + 1.669 + 1.670 + %xD0 %x90 %xD0 %xBB %xD0 %xB5 %xD0 %xBA %xD1 %x81 %xD0 1.671 + %xB5 %xD0 %xB9 1.672 + 1.673 + and will reject strings (1) and (3), as they contain 1.674 + octets not allowed in charset=UTF-8. 1.675 + After that, using the i;unicode-casemap collation, 1.676 + string (4) will collate before string (2). Using the 1.677 + i;octet collation on the original strings, string (3) 1.678 + will collate before string (1). So the final ordering 1.679 + is as follows: (4) (2) (3) (1). 1.680 + 1.681 + If the substring operation (e.g., IMAP SEARCH) of the active 1.682 + comparator returns the "undefined" result (see section 4.2.3 of 1.683 + [RFC4790]) for either the text specified in the SEARCH command or 1.684 + the message text, then the operation is repeated on the result of 1.685 + step (a) using the i;octet comparator. 1.686 + 1.687 + The ordering operation (e.g., IMAP SORT and THREAD) SHOULD collate 1.688 + the following together: strings encoded using unknown or invalid 1.689 + character encodings, strings in unrecognized charsets, and invalid 1.690 + input (as defined by the active collation). 1.691 + 1.692 + 1.693 + 1.694 +4.7 COMPARATOR Command 1.695 + 1.696 + Arguments: Optional comparator order arguments. 1.697 + 1.698 + Response: A possible COMPARATOR response (see Section 4.8). 1.699 + 1.700 + Result: OK - Command completed 1.701 + NO - No matching comparator found 1.702 + BAD - arguments invalid 1.703 + 1.704 + The COMPARATOR command is valid in authenticated and selected 1.705 + states. 1.706 + 1.707 + The COMPARATOR command is used to determine or change the active 1.708 + comparator. When issued with no arguments, it results in a 1.709 + COMPARATOR response indicating the currently active comparator. 1.710 + 1.711 + When issued with one or more comparator argument, it changes the 1.712 + active comparator as directed. (If more than one installed 1.713 + comparator is matched by an argument, the first argument wins.) The 1.714 + COMPARATOR response lists all matching comparators if more than one 1.715 + matches the specified patterns. 1.716 + 1.717 + The argument "default" refers to the server's default comparator. 1.718 + 1.719 + 1.720 + 1.721 +Newman & Co Expires August 2008 FF[Page 12] 1.722 + 1.723 + 1.724 + 1.725 + 1.726 + 1.727 +Internet-draft February 2008 1.728 + 1.729 + 1.730 + Otherwise each argument is an collation specification as defined in 1.731 + the Internet Application Protocol Comparator Registry [RFC4790]. 1.732 + 1.733 + < The client requests activating a Czech comparator if possible, 1.734 + or else a generic international comparator which it considers 1.735 + suitable for Czech. The server picks the first supported 1.736 + comparator. > 1.737 + 1.738 + C: A001 COMPARATOR "cz;*" i;basic 1.739 + S: * COMPARATOR i;basic 1.740 + S: A001 OK Will use i;basic for collation 1.741 + 1.742 + 1.743 +4.8 COMPARATOR Response 1.744 + 1.745 + Contents: The active comparator. 1.746 + An optional list of available matching comparators 1.747 + 1.748 + The COMPARATOR response occurs as a result of a COMPARATOR command. 1.749 + The first argument in the comparator response is the name of the 1.750 + active comparator. The second argument is a list of comparators 1.751 + which matched any of the arguments to the COMPARATOR command and is 1.752 + present only if more than one match is found. 1.753 + 1.754 + 1.755 +4.9 BADCOMPARATOR response code 1.756 + 1.757 + This response code SHOULD be returned as a result of server failing 1.758 + an IMAP command (returning NO), when the server knows that none of 1.759 + the specified comparators match the requested comparator(s). 1.760 + 1.761 + 1.762 +4.10 Formal Syntax 1.763 + 1.764 + The following syntax specification inherits ABNF [RFC4234] rules 1.765 + from IMAP4rev1 [RFC3501], and Internet Application Protocol 1.766 + Comparator Registry [RFC4790]. 1.767 + 1.768 + command-auth =/ comparator-cmd 1.769 + 1.770 + resp-text-code =/ "BADCOMPARATOR" 1.771 + 1.772 + comparator-cmd = "COMPARATOR" *(SP comp-order-quoted) 1.773 + 1.774 + response-payload =/ comparator-data 1.775 + 1.776 + comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "(" 1.777 + comp-id-quoted *(SP comp-id-quoted) ")"] 1.778 + 1.779 + 1.780 + 1.781 +Newman & Co Expires August 2008 FF[Page 13] 1.782 + 1.783 + 1.784 + 1.785 + 1.786 + 1.787 +Internet-draft February 2008 1.788 + 1.789 + 1.790 + comp-id-quoted = astring 1.791 + ; Once any literal wrapper or quoting is removed, this 1.792 + ; follows the collation-id rule from [RFC4790] 1.793 + 1.794 + comp-order-quoted = astring 1.795 + ; Once any literal wrapper or quoting is removed, this 1.796 + ; follows the collation-order rule from [RFC4790] 1.797 + 1.798 + comp-sel-quoted = astring 1.799 + ; Once any literal wrapper or quoting is removed, this 1.800 + ; follows the collation-selected rule from [RFC4790] 1.801 + 1.802 + 1.803 +5. Other IMAP Internationalization Issues 1.804 + 1.805 + The following sections provide an overview of various other IMAP 1.806 + internationalization issues. These issues are not resolved by this 1.807 + specification, but could be resolved by other standards work, such 1.808 + as that being done by the EAI group (see [IMAP-EAI]). 1.809 + 1.810 + 1.811 +5.1 Unicode Userids and Passwords 1.812 + 1.813 + IMAP4rev1 currently restricts the userid and password fields of the 1.814 + LOGIN command to US-ASCII. The "userid" and "password" fields of the 1.815 + IMAP LOGIN command are restricted to US-ASCII only until a future 1.816 + standards track RFC states otherwise. Servers are encouraged to 1.817 + validate both fields to make sure they conform to the formal syntax 1.818 + of UTF-8 and to reject the LOGIN command if that syntax is violated. 1.819 + Servers MAY reject the use of any 8-bit in the "userid" or 1.820 + "password" field. 1.821 + 1.822 + When AUTHENTICATE is used, some servers may support userids and 1.823 + passwords in Unicode [RFC3490] since SASL (see [RFC4422]) allows 1.824 + that. However, such userids cannot be used as part of email 1.825 + addresses. 1.826 + 1.827 + 1.828 +5.2 UTF-8 Mailbox Names 1.829 + 1.830 + The modified UTF-7 mailbox naming convention described in section 1.831 + 5.1.3 of RFC 3501 is best viewed as an transition from the status 1.832 + quo in 1996 when modified UTF-7 was first specified. At that time, 1.833 + there was widespread unofficial use of local character sets such as 1.834 + ISO-8859-1 and Shift-JIS for non-ASCII mailbox names, with resultant 1.835 + non-interoperability. 1.836 + 1.837 + The requirements in section 5.1 of RFC 3501 are very important if 1.838 + 1.839 + 1.840 + 1.841 +Newman & Co Expires August 2008 FF[Page 14] 1.842 + 1.843 + 1.844 + 1.845 + 1.846 + 1.847 +Internet-draft February 2008 1.848 + 1.849 + 1.850 + we're ever going to be able to deploy UTF-8 mailbox names. Servers 1.851 + are encouraged to enforce them. 1.852 + 1.853 + 1.854 +5.3 UTF-8 Domains, Addresses and Mail Headers 1.855 + 1.856 + There is now an IETF standard for Internationalizing Domain Names in 1.857 + Applications [RFC3490]. While IMAP clients are free to support this 1.858 + standard, an argument can be made that it would be helpful to simple 1.859 + clients if the IMAP server could perform this conversion (the same 1.860 + argument would apply to MIME header encoding [RFC2047]). However, 1.861 + it would be unwise to move forward with such work until the work in 1.862 + progress to define the format of international email addresses is 1.863 + complete. 1.864 + 1.865 + 1.866 +6. IANA Considerations 1.867 + 1.868 + The IANA is requested to add LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2 1.869 + to the IMAP4 Capabilities Registry. [Note to IANA: 1.870 + http://www.iana.org/assignments/imap4-capabilities] 1.871 + 1.872 + 1.873 +7. Security Considerations 1.874 + 1.875 + The LANGUAGE extension makes a new command available in "Not 1.876 + Authenticated" state in IMAP. Some IMAP implementations run with 1.877 + root privilege when the server is in "Not Authenticated" state and 1.878 + do not revoke that privilege until after authentication is complete. 1.879 + Such implementations are particularly vulnerable to buffer overflow 1.880 + security errors at this stage and need to implement parsing of this 1.881 + command with extra care. 1.882 + 1.883 + A LANGUAGE command issued prior to activation of a security layer is 1.884 + subject to an active attack which suppresses or modifies the 1.885 + negotiation and thus makes STARTTLS or authentication error messages 1.886 + more difficult to interpret. This is not a new attack as the error 1.887 + messages themselves are subject to active attack. Clients MUST re- 1.888 + issue the LANGUAGE command once a security layer is active, so this 1.889 + does not impact subsequent protocol operations. 1.890 + 1.891 + LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2 extensions use the UTF-8 1.892 + charset, thus the security considerations for UTF-8 [RFC3629] are 1.893 + relevent. However, neither uses UTF-8 for identifiers so the most 1.894 + serious concerns do not apply. 1.895 + 1.896 + 1.897 +8. Acknowledgements 1.898 + 1.899 + 1.900 + 1.901 +Newman & Co Expires August 2008 FF[Page 15] 1.902 + 1.903 + 1.904 + 1.905 + 1.906 + 1.907 +Internet-draft February 2008 1.908 + 1.909 + 1.910 + The LANGUAGE extension is based on a previous Internet draft by Mike 1.911 + Gahrns, a substantial portion of the text in that section was 1.912 + written by him. Many people have participated in discussions about 1.913 + an IMAP Language extension in the various fora of the IETF and 1.914 + Internet working groups, so any list of contributors is bound to be 1.915 + incomplete. However, the authors would like to thank Andrew McCown 1.916 + for early work on the original proposal, John Myers for suggestions 1.917 + regarding the namespace issue, along with Jutta Degener, Mark 1.918 + Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo, Martin Duerst, 1.919 + Timo Sirainen, Ben Campbell and Magnus Nystrom for their many 1.920 + suggestions that have been incorporated into this document. 1.921 + 1.922 + Initial discussion of the I18NLEVEL=2 extension involved input from 1.923 + Mark Crispin and other participants of the IMAP Extensions WG. 1.924 + 1.925 + 1.926 +9. Relevant Standards for i18n IMAP Implementations 1.927 + 1.928 + This is a non-normative list of standards to consider when 1.929 + implementing i18n aware IMAP software. 1.930 + 1.931 + o The LANGUAGE and I18NLEVEL=2 extensions to IMAP (this 1.932 + specification). 1.933 + o The 8-bit rules for mailbox naming in section 5.1 of RFC 3501. 1.934 + o The Mailbox International Naming Convention in section 5.1.3 of 1.935 + RFC 3501. 1.936 + o MIME [RFC2045] for message bodies. 1.937 + o MIME header encoding [RFC2047] for message headers. 1.938 + o The IETF EAI working group. 1.939 + o MIME Parameter Value and Encoded Word Extensions [RFC2231] for 1.940 + filenames. Quality IMAP server implementations will 1.941 + automatically combine multipart parameters when generating the 1.942 + BODYSTRUCTURE. There is also some deployed non-standard use of 1.943 + MIME header encoding inside double-quotes for filenames. 1.944 + o IDNA [RFC3490] and punycode [RFC3492] for domain names 1.945 + (currently only relevant to IMAP clients). 1.946 + o The UTF-8 charset [RFC3629]. 1.947 + o The IETF policy on Character Sets and Languages [RFC2277]. 1.948 + 1.949 + 1.950 +Normative References 1.951 + 1.952 + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1.953 + Requirement Levels", BCP 14, RFC 2119, March 1997. 1.954 + 1.955 + [RFC2277] Alvestrand, "IETF Policy on Character Sets and 1.956 + Languages", BCP 18, RFC 2277, January 1998. 1.957 + 1.958 + 1.959 + 1.960 + 1.961 +Newman & Co Expires August 2008 FF[Page 16] 1.962 + 1.963 + 1.964 + 1.965 + 1.966 + 1.967 +Internet-draft February 2008 1.968 + 1.969 + 1.970 + [RFC2342] Gahrns, Newman, "IMAP4 Namespace", RFC 2342, May 1998. 1.971 + 1.972 + [RFC3501] Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1.973 + 4rev1", RFC 3501, March 2003. 1.974 + 1.975 + [RFC3629] Yergeau, "UTF-8, a transformation format of ISO 10646", 1.976 + STD 63, RFC 3629, November 2003. 1.977 + 1.978 + [RFC4234] Crocker, Overell, "Augmented BNF for Syntax 1.979 + Specifications: ABNF", RFC 4234, Brandenburg 1.980 + Internetworking, Demon Internet Ltd, October 2005. 1.981 + 1.982 + [RFC4422] Melnikov, Zeilenga, "Simple Authentication and Security 1.983 + Layer (SASL)", RFC 4422, June 2006. 1.984 + 1.985 + [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", 1.986 + RFC 4466, Isode Ltd., April 2006. 1.987 + 1.988 + [RFC4646] Philips, Davis, "Tags for Identifying Languages", BCP 47, 1.989 + RFC 4646, September 2006. 1.990 + 1.991 + [RFC4647] Philips, Davis, "Matching of Language Tags", BCP 47, RFC 1.992 + 4647, September 2006. 1.993 + 1.994 + [RFC4790] Newman, Duerst, Gulbrandsen, "Internet Application 1.995 + Protocol Comparator Registry", RFC 4790, February 2007. 1.996 + 1.997 + [SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS 1.998 + PROTOCOL - SORT AND THREAD EXTENSION", draft-ietf- 1.999 + imapext-sort-19 (work in progress), November 2006. 1.1000 + 1.1001 + [UCM] Crispin, "i;unicode-casemap - Simple Unicode Collation 1.1002 + Algorithm", RFC 5051, October 2007. 1.1003 + 1.1004 + [RFC2045] Freed, Borenstein, "Multipurpose Internet Mail Extensions 1.1005 + (MIME) Part One: Format of Internet Message Bodies", RFC 1.1006 + 2045, November 1996. 1.1007 + 1.1008 + [RFC2047] Moore, "MIME (Multipurpose Internet Mail Extensions) Part 1.1009 + Three: Message Header Extensions for Non-ASCII Text", RFC 1.1010 + 2047, November 1996. 1.1011 + 1.1012 + 1.1013 +Informative References 1.1014 + 1.1015 + 1.1016 + [RFC2231] Freed, Moore, "MIME Parameter Value and Encoded Word 1.1017 + Extensions: Character Sets, Languages, and 1.1018 + 1.1019 + 1.1020 + 1.1021 +Newman & Co Expires August 2008 FF[Page 17] 1.1022 + 1.1023 + 1.1024 + 1.1025 + 1.1026 + 1.1027 +Internet-draft February 2008 1.1028 + 1.1029 + 1.1030 + Continuations", RFC 2231, November 1997. 1.1031 + 1.1032 + [RFC3490] Faltstrom, Hoffman, Costello, "Internationalizing Domain 1.1033 + Names in Applications (IDNA)", RFC 3490, March 2003. 1.1034 + 1.1035 + [RFC3492] Costello, "Punycode: A Bootstring encoding of Unicode for 1.1036 + Internationalized Domain Names in Applications (IDNA)", 1.1037 + RFC 3492, March 2003. 1.1038 + 1.1039 + [METADATA] Daboo, C., "IMAP METADATA Extension", draft-daboo-imap- 1.1040 + annotatemore-12 (work in progress), December 2007. 1.1041 + 1.1042 + [IMAP-EAI] Resnick, Newman, "IMAP Support for UTF-8", draft-ietf- 1.1043 + eai-imap-utf8 (work in progress), May 2006. 1.1044 + 1.1045 + 1.1046 + 1.1047 +Authors' Addresses 1.1048 + 1.1049 + Chris Newman 1.1050 + Sun Microsystems 1.1051 + 3401 Centrelake Dr., Suite 410 1.1052 + Ontario, CA 91761 1.1053 + US 1.1054 + 1.1055 + Email: chris.newman@sun.com 1.1056 + 1.1057 + 1.1058 + Arnt Gulbrandsen 1.1059 + Oryx Mail Systems GmbH 1.1060 + Schweppermannstr. 8 1.1061 + D-81671 Muenchen 1.1062 + Germany 1.1063 + 1.1064 + Email: arnt@oryx.com 1.1065 + 1.1066 + Fax: +49 89 4502 9758 1.1067 + 1.1068 + 1.1069 + Alexey Melnikov 1.1070 + Isode Limited 1.1071 + 5 Castle Business Village, 36 Station Road, 1.1072 + Hampton, Middlesex, TW12 2BX, UK 1.1073 + 1.1074 + Email: Alexey.Melnikov@isode.com 1.1075 + 1.1076 + 1.1077 + 1.1078 + 1.1079 + 1.1080 + 1.1081 +Newman & Co Expires August 2008 FF[Page 18] 1.1082 + 1.1083 + 1.1084 + 1.1085 + 1.1086 + 1.1087 +Internet-draft February 2008 1.1088 + 1.1089 + 1.1090 +Intellectual Property Statement 1.1091 + 1.1092 + The IETF takes no position regarding the validity or scope of any 1.1093 + Intellectual Property Rights or other rights that might be claimed to 1.1094 + pertain to the implementation or use of the technology described in 1.1095 + this document or the extent to which any license under such rights 1.1096 + might or might not be available; nor does it represent that it has 1.1097 + made any independent effort to identify any such rights. Information 1.1098 + on the procedures with respect to rights in RFC documents can be found 1.1099 + in BCP 78 and BCP 79. 1.1100 + 1.1101 + Copies of IPR disclosures made to the IETF Secretariat and any 1.1102 + assurances of licenses to be made available, or the result of an 1.1103 + attempt made to obtain a general license or permission for the use of 1.1104 + such proprietary rights by implementers or users of this specification 1.1105 + can be obtained from the IETF on-line IPR repository at 1.1106 + http://www.ietf.org/ipr. 1.1107 + 1.1108 + The IETF invites any interested party to bring to its attention any 1.1109 + copyrights, patents or patent applications, or other proprietary 1.1110 + rights that may cover technology that may be required to implement 1.1111 + this standard. Please address the information to the IETF at 1.1112 + ietf-ipr@ietf.org. 1.1113 + 1.1114 + 1.1115 +Full Copyright Statement 1.1116 + 1.1117 + Copyright (C) The IETF Trust (2008). This document is subject to 1.1118 + the rights, licenses and restrictions contained in BCP 78, and 1.1119 + except as set forth therein, the authors retain all their rights. 1.1120 + 1.1121 + This document and the information contained herein are provided on 1.1122 + an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1.1123 + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1.1124 + IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1.1125 + WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1.1126 + WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1.1127 + ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1.1128 + FOR A PARTICULAR PURPOSE. 1.1129 + 1.1130 + 1.1131 +Acknowledgment 1.1132 + 1.1133 + Funding for the RFC Editor function is currently provided by the 1.1134 + Internet Society. 1.1135 + 1.1136 + 1.1137 + 1.1138 + 1.1139 + 1.1140 + 1.1141 +Newman & Co Expires August 2008 FF[Page 19] 1.1142 + 1.1143 +