idnits 2.17.1 draft-gahrns-imap-language-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC-2060]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2001) is 8471 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3066' is mentioned on line 84, but not defined ** Obsolete undefined reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3066 (ref. 'LANG-TAGS') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 2060 (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Unexpected draft version: The latest known version of draft-alvestrand-charset-policy is -01, but you're referring to -02. Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Gahrns, Microsoft 3 Internet Draft A. Melnikov, ACI WorldWide/MessagingDirect 4 Document: draft-gahrns-imap-language-02.txt February 2001 6 IMAP4 Language Extension 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 0. Meta Information on this draft 31 This information is intended to facilitate discussion. It will be 32 removed when this document leaves the Internet-Draft stage. 34 This draft is being discussed on the IMAPEXT mailing list at ietf- 35 imapext@imc.org. Subscription requests can be sent to ietf- 36 imapext-request@imc.org (send an email message with the word 37 "subscribe" in the body). More information on the mailing list 38 along with a WWW archive of back messages is available at 39 HTTP://www.imc.org 41 Changes since -00 43 1) Now define an extension mechanism to allow additional parameters 44 to be passed so that this draft could serve as a framework for full 45 internationalization of other drafts such as SORT. This approach 46 would allow the language draft to proceed and solve the immediate 47 and easy case of allowing an IMAP user to read server responses in 48 their language. At the IMC interop event some vendors have already 49 implemented to language-draft-00. These implementations would 50 remain unaffected by future extensions to this language draft, since 51 a client would not include any additional extension parameters in 52 the LANGUAGE command unless the server advertised these extensions 53 IMAP4 Language Extension February 2001 55 in its capability response. At the IMAPEXT Working Group at the 56 45th IETF in Oslo, it was proposed that an extension mechanism be 57 added to this draft and then have the working group debate the 58 merits of continuing with this existing draft versus starting a new 59 draft to tackle the more daunting problem of trying to solve all 60 internationalization issues in a single draft. 62 2) Included John Myers' suggestion to add to the requirements 63 section that a client that supports this extension must be prepared 64 for a NAMESPACE response. 66 3) Included John Myers' suggestion that if the server supports the 67 namespace extension it must send a NAMESPACE response when a 68 language is negotiated. 70 4) Included John Myers' suggestion that a TRANSLATION extension be 71 included to the NAMESPACE response to allow for localized version of 72 the NAMESPACE prefixes. 74 5) Included Jutta Degener's corrections to the grammar (e.g. 1# is 75 not defined in RFC2234-BNF, missing ] in grammar) along with her 76 minor editorial suggestions. 78 6) Included Mark Crispin's suggestion of allowing the server to 79 substitute a primary language if the sublanguage asked for is not 80 available. 82 Changes since -01 84 1) formally defined as an , [RFC 3066] only 85 described it. 87 2) Grammar for EXTENSION updated to show the parts of the extension. 89 3) Incorporated text about MUL, UND and hierarchy. 91 4) References to RFC 1766 were replaced with RFC 3066 that obsoleted it. 93 5) ABNF declaration for NAMESPACE_TRANSLATION_RESPONSE is now linked 94 to NAMESPACE extension [RFC-2342]. 96 6) Server MUST NOT return a NAMESPACE response if it is in 97 non-authenticated state. 99 IMAP4 Language Extension February 2001 101 1. Abstract 103 The Internet Message Access Protocol [RFC-2060] allows server 104 responses to include human-readable text that in many cases needs to 105 be presented to the user. This document specifies a way for a 106 client to negotiate which language the server should use when 107 sending human-readable text. It provides an extensible mechanism so 108 that it may be used as a framework for full internationalization of 109 other IMAP extensions. 111 2. Conventions used in this document 113 In examples, "C:" and "S:" indicate lines sent by the client and 114 server respectively. If such lines are wrapped without a new "C:" 115 or "S:" label, then the wrapping is for editorial clarity and is not 116 part of the command. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 120 this document are to be interpreted as described in [RFC-2119]. 122 3. Requirements 124 IMAP4 servers that support this extension MUST list the keyword 125 LANGUAGE in their CAPABILITY response. 127 A server that supports this extension SHOULD use the language "i- 128 default" as described in [CHARSET-POLICY] as its default language 129 until another supported language is negotiated by the client. A 130 server MUST include "i-default" as one of its supported languages. 132 A client that supports this extension MUST be prepared for a 133 possible NAMESPACE response [RFC-2342] from the server. 135 The LANGUAGE command is valid in the non-authenticated, 136 authenticated and selected state. 138 4. LANGUAGE Command 140 Arguments: Zero or one language tag as described by [LANG-TAGS]. 142 Response: A possible LANGUAGE response containing the list of 143 server supported languages. 145 A possible NAMESPACE response as defined by [RFC-2342]. 147 IMAP4 Language Extension February 2001 149 Result: OK - Command completed 150 NO - Could not complete command 151 BAD - arguments invalid 153 The LANGUAGE command requests that human-readable text emitted by 154 the server be localized to the language specified in the language 155 tag argument. 157 If the command succeeds, the server will return human-readable 158 responses in the specified language starting with the tagged OK 159 response to the LANGUAGE command. These responses will be in UTF-8 160 [RFC-2044]. 162 If the command fails, the server will continue to return human- 163 readable responses in the language it was previously using. 165 Example 4.1 166 =========== 168 < The server defaults to using English responses until the user 169 explicitly changes the language. > 171 C: A001 LOGIN KAREN PASSWORD 172 S: A001 OK LOGIN completed 174 < Once the client changes the language, all responses will be in 175 that language starting with the tagged OK to the LANGUAGE command. > 177 C: A002 LANGUAGE FR 178 S: A002 OK La Language commande a ete execute avec success 180 < If a server does not support the requested primary language, 181 responses will continue to be returned in the current language the 182 server is using. > 184 C: A003 LANGUAGE DE 185 S: A003 NO Ce Language n'est pas supporte 187 < Client requested MUL language. Server MUST reply with BAD > 189 C: A003 LANGUAGE MUL 190 S: A003 BAD Invalid language MUL 192 If the client requests a sublanguage that is not available, but the 193 primary language is available, the server SHOULD switch to the 194 primary language and return a LANGUAGE response indicating that it 195 switched to the primary language instead. 197 Server SHOULD recognize languages that have multiple different tags 198 (for example "ru" and "rus"). 200 IMAP4 Language Extension February 2001 202 Note 1. Client MUST NOT use MUL (Multiple languages) and 203 UND(Undetermined) language tags and server MUST return BAD 204 to the LANG command that is used with such parameter. 206 Note 2. [LANG-TAGS] warns that there is no guaranteed 207 relationship between languages whose tags start out with 208 the same series of subtags. However it is believed that 209 for the purpose of this document it is safe to treat all 210 languages, whose tags starts with primary languages 211 described in ISO 639-1 and ISO 639-2 (i.e. all 2 or 3 212 letters primary languages) as hierarchical. For all 213 languages with other primary tags, the described fallback 214 rule MUST NOT be used. In particular, language tags 215 starting with 'i-' and 'x-' MUST NOT be treated as 216 hierarchical. 218 Example 4.2 219 =========== 221 C: A002 LANGUAGE FR-CA 222 S: * LANGUAGE (FR) 223 S: A002 OK La Language commande a ete execute avec success 225 If the language tag argument is omitted, the server SHOULD send an 226 untagged LANGUAGE response listing the languages it supports. If 227 the server is unable to enumerate the list of languages it supports 228 it MAY return a tagged NO response to the enumeration request. 230 Example 4.3 231 =========== 233 < A LANGUAGE command with no arguments is a request to enumerate the 234 list of languages the server supports. > 236 C: A001 LANGUAGE 237 S: * LANGUAGE (EN DE IT i-default) 238 S: A001 OK Supported languages have been enumerated 240 C: A001 LANGUAGE 241 S: A002 NO Server is unable to enumerate supported languages 243 5. TRANSLATION extension to the NAMESPACE response 245 If the server supports the IMAP4 NAMESPACE command [RFC-2342], the 246 server MUST return an untagged NAMESPACE response when a language is 247 negotiated. However server MUST NOT return a NAMESPACE response if it 248 is in non-authenticated state. 250 If as a result of the newly negotiated language, localized 251 representations of the namespace prefixes are available, the server 252 IMAP4 Language Extension February 2001 254 SHOULD include these in the TRANSLATION extension to the NAMESPACE 255 response. 257 The TRANSLATION extension to the NAMESPACE response returns a single 258 string, containing the Modified UTF-7 [RFC-2060] encoded translation 259 of the namespace prefix. It is the responsibility of the client to 260 convert between the namespace prefix and the translation of the 261 namespace prefix when presenting mailbox names to the user. 263 Example 5.1 264 =========== 266 < In this example a server supports the IMAP4 NAMESPACE command. It 267 uses no prefix to the user's Personal Namespace, a prefix of "Other 268 Users" to its Other Users' Namespace and a prefix of "Public 269 Folders" to its only Shared Namespace. Since a client will often 270 display these prefixes to the user, the server includes a 271 translation of them that can be presented to the user. > 273 C: A001 LANGUAGE FR-CA 274 S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION" ("Autres 275 Utilisateurs/"))) (("Public Folders/" "/" "TRANSLATION" ("R&Aok- 276 pertoires Publics/"))) 277 S: A001 OK La Language commande a ete executee avec success 279 6. Formal Syntax 281 The following syntax specification uses the augmented Backus-Naur 282 Form (BNF) as described in [RFC-2234]. 284 LANGUAGE_Command = "LANGUAGE" [SP ] [*EXTENSION] 285 ; A client should not issue the optional extension parameter 286 ; unless a server has indicated in its capabilities that it 287 ; supports that extension 289 EXTENSION = SP "(" LANG-EXT-NAME SP LANG-EXT-VALUES ")" 291 LANG-EXT-NAME = string 292 ; Name of LANG extension 294 LANG-EXT-VALUES = "(" LANG-EXT-VALUE *(SP LANG-EXT-VALUE)")" 295 ; List of LANG extension specific values 297 LANG-EXT-VALUE = string 299 string = 300 ; string as defined in [RFC-2060] 301 IMAP4 Language Extension February 2001 303 LANGUAGE_Response = "*" SP "LANGUAGE" SP "(" *(SP 304 ) ")" 305 ; Note: the server is required to support the language i-default 306 ; and as such i-default must appear in the language response. 308 Namespace_Response_Extension =/ NAMESPACE_TRANSLATION_RESPONSE 309 ; Namespace_Response_Extension is defined in [RFC-2342] 311 NAMESPACE_TRANSLATION_RESPONSE = SP <"> TRANSLATION <"> SP "(" 312 string ")" 313 ; the string is encoded in Modified UTF-7 315 = as defined in [RFC-2060] 316 ; is described in [LANG-TAGS] 318 ; After the server is changed to a language other than i-default, 319 the resp_text as defined by [RFC-2060] becomes: 321 resp_text = ["[" "]" SP ] 1*UTF8_CHAR 322 ;