idnits 2.17.1 draft-gahrns-imap-language-01.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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 480 lines 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. ** 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 (October 1999) is 8959 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 1766 (Obsoleted by RFC 3066, RFC 3282) ** 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: 10 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Gahrns, Microsoft 2 Internet Draft 3 Document: draft-gahrns-imap-language-01.txt October 1999 5 IMAP4 Language Extension 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC 2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 0. Meta Information on this draft 30 This information is intended to facilitate discussion. It will be 31 removed when this document leaves the Internet-Draft stage. 33 This draft is being discussed on the IMAPEXT mailing list at ietf- 34 imapext@imc.org. Subscription requests can be sent to ietf- 35 imapext-request@imc.org (send an email message with the word 36 "subscribe" in the body). More information on the mailing list 37 along with a WWW archive of back messages is available at 38 HTTP://www.imc.org 40 Changes since -00 42 1) Now define an extension mechanism to allow additional parameters 43 to be passed so that this draft could serve as a framework for full 44 internationalization of other drafts such as SORT. This approach 45 would allow the language draft to proceed and solve the immediate 46 and easy case of allowing an IMAP user to read server responses in 47 their language. At the IMC interop event some vendors have already 48 implemented to language-draft-00. These implementations would 49 remain unaffected by future extensions to this language draft, since 50 a client would not include any additional extension parameters in 51 the LANGUAGE command unless the server advertised these extensions 53 Gahrns Expires April 2000 1 55 IMAP4 Language Extension October 1999 57 in its capability response. At the IMAPEXT Working Group at the 58 45th IETF in Oslo, it was proposed that an extension mechanism be 59 added to this draft and then have the working group debate the 60 merits of continuing with this existing draft versus starting a new 61 draft to tackle the more daunting problem of trying to solve all 62 internationalization issues in a single draft. 64 2) Included John Myers' suggestion to add to the requirements 65 section that a client that supports this extension must be prepared 66 for a NAMESPACE response. 68 3) Included John Myers' suggestion that if the server supports the 69 namespace extension it must send a NAMESPACE response when a 70 language is negotiated. 72 4) Included John Myers' suggestion that a TRANSLATION extension be 73 included to the NAMESPACE response to allow for localized version of 74 the NAMESPACE prefixes. 76 5) Included Jutta Degener's corrections to the grammar (e.g. 1# is 77 not defined in RFC2234-BNF, missing ] in grammar) along with her 78 minor editorial suggestions. 80 6) Included Mark Crispin's suggestion of allowing the server to 81 substitute a primary language if the sublanguage asked for is not 82 available. 84 1. Abstract 86 The Internet Message Access Protocol [RFC-2060] allows server 87 responses to include human-readable text that in many cases needs to 88 be presented to the user. This document specifies a way for a 89 client to negotiate which language the server should use when 90 sending human-readable text. It provides an extensible mechanism so 91 that it may be used as a framework for full internationalization of 92 other IMAP extensions such as SORT. 94 2. Conventions used in this document 96 In examples, "C:" and "S:" indicate lines sent by the client and 97 server respectively. If such lines are wrapped without a new "C:" 98 or "S:" label, then the wrapping is for editorial clarity and is not 99 part of the command. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 103 this document are to be interpreted as described in [RFC-2119]. 105 3. Requirements 107 Gahrns Expires April 2000 2 109 IMAP4 Language Extension October 1999 111 IMAP4 servers that support this extension MUST list the keyword 112 LANGUAGE in their CAPABILITY response. 114 A server that supports this extension SHOULD use the language "i- 115 default" as described in [CHARSET-POLICY] as its default language 116 until another supported language is negotiated by the client. A 117 server MUST include "i-default" as one of its supported languages. 119 A client that supports this extension MUST be prepared for a 120 possible NAMESPACE response [RFC-2342] from the server. 122 The LANGUAGE command is valid in the non-authenticated, 123 authenticated and selected state. 125 4. LANGUAGE Command 127 Arguments: Zero or one language tag as defined by [RFC-1766]. 129 Response: A possible LANGUAGE response containing the list of 130 server supported languages. 132 If a sublanguage was asked for and not available but the 133 primary language is available, the server should switch to 134 the primary language and include a LANGUAGE response 135 containing the identifier of the primary language it 136 switched to. 138 A possible NAMESPACE response as defined by [RFC-2342]. 140 Result: OK - Command completed 141 NO - Could not complete command 142 BAD - arguments invalid 144 The LANGUAGE command requests that human-readable text emitted by 145 the server be localized to the language specified in the language 146 tag argument. 148 If the command succeeds, the server will return human-readable 149 responses in the specified language starting with the tagged OK 150 response to the LANGUAGE command. These responses will be in UTF-8 151 [RFC-2044]. 153 If the command fails, the server will continue to return human- 154 readable responses in the language it was previously using. 156 Example 4.1 157 =========== 159 < The server defaults to using English responses until the user 160 explicitly changes the language. > 162 Gahrns Expires April 2000 3 164 IMAP4 Language Extension October 1999 166 C: A001 LOGIN KAREN PASSWORD 167 S: A001 OK LOGIN completed 169 < Once the client changes the language, all responses will be in 170 that language starting with the tagged OK to the LANGUAGE command. > 172 C: A002 LANGUAGE FR 173 S: A002 OK La Language commande a ete executee avec success 175 < If a server does not support the requested primary language, 176 responses will continue to be returned in the current language the 177 server is using. > 179 C: A003 LANGUAGE DE 180 S: A003 NO Ce Language n'est pas supporte 182 Example 4.2 183 =========== 185 If the client requests a sublanguage that is not available, but the 186 primary language is available, the server SHOULD switch to the 187 primary language and return a LANGUAGE response indicating that it 188 switched to the primary language instead. 190 C: A002 LANGUAGE FR-CA 191 S: * LANGUAGE (FR) 192 S: A002 OK La Language commande a ete executee avec success 194 If the language tag argument is omitted, the server SHOULD send an 195 untagged LANGUAGE response listing the languages it supports. If 196 the server is unable to enumerate the list of languages it supports 197 it MAY return a tagged NO response to the enumeration request. 199 Example 4.3 200 =========== 202 < A LANGUAGE command with no arguments is a request to enumerate the 203 list of languages the server supports. > 205 C: A001 LANGUAGE 206 S: * LANGUAGE (EN DE IT i-default) 207 S: A001 OK Supported languages have been enumerated 209 C: A001 LANGUAGE 210 S: A002 NO Server is unable to enumerate supported languages 212 5. TRANSLATION extension to the NAMESPACE response 214 If the server supports the IMAP4 NAMESPACE command [RFC-2342], the 215 server MUST return an untagged NAMESPACE response when a language is 216 negotiated. 218 Gahrns Expires April 2000 4 220 IMAP4 Language Extension October 1999 222 If as a result of the newly negotiated language, localized 223 representations of the namespace prefixes are available, the server 224 SHOULD include these in the TRANSLATION extension to the NAMESPACE 225 response. 227 The TRANSLATION extension to the NAMESPACE response returns a single 228 string, containing the Modified UTF-7 [RFC-2060] encoded translation 229 of the namespace prefix. It is the responsibility of the client to 230 convert between the namespace prefix and the translation of the 231 namespace prefix when presenting mailbox names to the user. 233 Example 5.1 234 =========== 236 < In this example a server supports the IMAP4 NAMESPACE command. It 237 uses no prefix to the user's Personal Namespace, a prefix of "Other 238 Users" to its Other Users' Namespace and a prefix of "Public 239 Folders" to its only Shared Namespace. Since a client will often 240 display these prefixes to the user, the server includes a 241 translation of them that can be presented to the user. > 243 C: A001 LANGUAGE FR-CA 244 S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION" ("Autres 245 Utilisateurs/"))) (("Public Folders/" "/" "TRANSLATION" ("R&Aok- 246 pertoires Publics/"))) 247 S: A001 OK La Language commande a ete executee avec success 249 6. Formal Syntax 251 The following syntax specification uses the augmented Backus-Naur 252 Form (BNF) as described in [RFC-2234]. 254 LANGUAGE_Command = "LANGUAGE" [SP ] [*EXTENSION] 255 ; A client should not issue the optional extension parameter 256 ; unless a server has indicated in its capabilities that it 257 ; supports that extension 259 EXTENSION = SP "(" string SP "(" string *(SP string)")" ")" 261 string = 262 ;string as defined in [RFC-2060] 264 LANGUAGE_Response = "*" SP "LANGUAGE" SP "(" *(SP 265 ) ")" 266 ; Note: the server is required to support the language i-default 267 ; and as such i-default must appear in the language response. 269 Gahrns Expires April 2000 5 271 IMAP4 Language Extension October 1999 273 NAMESPACE_TRANSLATION_RESPONSE = SP <"> TRANSLATION <"> SP "(" 274 string ")" 275 ; the string is encoded in Modified UTF-7 277 = as defined in [RFC-1766] 279 ; After the server is changed to a language other than i-default, 280 the resp_text as defined by [RFC-2060] becomes: 282 resp_text = ["[" "]" SP ] 1*UTF8_CHAR 283 ;