idnits 2.17.1 draft-gahrns-imap-language-00.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 59 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 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 (November 1997) is 9658 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) -- No information found for draft-drums-abnf - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ABNF' -- Unexpected draft version: The latest known version of draft-alvestrand-charset-policy is -01, but you're referring to -02. (However, the state information for draft-drums-abnf is not up-to-date. The last update was unsuccessful) == Outdated reference: A later version (-06) exists of draft-gahrns-imap-namespace-05 Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Gahrns, Microsoft 2 A. McCown, Mitsubishi Electric ITA 3 Internet Draft 4 Document: draft-gahrns-imap-language-00.txt November 1997 6 IMAP4 Language Extension 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 "working draft" or "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the 27 RFC editor as a Proposed Standard for the Internet Community. 28 Discussion and suggestions for improvement are requested. This 29 document will expire before June 1998. Distribution of this draft is 30 unlimited. 32 1. Abstract 34 The Internet Message Access Protocol [RFC-2060] allows server 35 responses to include human-readable text that in many cases needs to 36 be presented to the user. This document specifies a way for a 37 client to negotiate which language the server should use when 38 sending human-readable text. 40 2. Conventions used in this document 42 In examples, "C:" and "S:" indicate lines sent by the client and 43 server respectively. If such lines are wrapped without a new "C:" 44 or "S:" label, then the wrapping is for editorial clarity and is not 45 part of the command. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in [RFC-2119]. 51 Gahrns and McCown 1 52 IMAP4 Language Extension November 1997 54 3. Requirements 56 IMAP4 servers that support this extension MUST list the keyword 57 LANGUAGE in their CAPABILITY response. 59 A server that supports this extension SHOULD use the language "i- 60 default" as described in [CHARSET-POLICY] as its default language 61 until another supported language is negotiated by the client. A 62 server MUST include "i-default" as one of its supported languages. 64 The LANGUAGE command is valid in the non-authenticated, 65 authenticated and selected state. 67 4. LANGUAGE Command 69 Arguments: Zero or one language tag as defined by [RFC-1766]. 71 Response: A possible LANGUAGE response containing the list of 72 server supported languages. 73 A possible NAMESPACE response as defined by [IMAP- 74 NAMESPACE]. 76 Result: OK - Command completed 77 NO - Could not complete command 78 BAD - arguments invalid 80 The LANGUAGE command requests that human-readable text emitted by 81 the server be localized to the language specified in the language 82 tag argument. 84 If the command succeeds, the server will return human-readable 85 responses in the specified language starting with the tagged OK 86 response to the LANGUAGE command. These responses will be in UTF-8 87 [RFC-2044]. 89 If the command fails, the server will continue to return human- 90 readable responses in the language it was previously using. 92 Example 4.1 93 =========== 95 < The server defaults to using English responses until the user 96 explicitly changes the language. > 98 C: A001 LOGIN KAREN PASSWORD 99 S: A001 OK LOGIN completed 101 < Once the client changes the language, all responses will be in 102 that language starting with the tagged OK to the LANGUAGE command. > 104 Gahrns and McCown 2 105 IMAP4 Language Extension November 1997 107 C: A002 LANGUAGE FR 108 S: A002 OK La Language commande a ete executee avec success 110 < If a server does not support the requested language, responses 111 will continue to be returned in the current language the server is 112 using. > 114 C: A003 LANGUAGE DE 115 S: A003 NO Ce Language n'est pas supporte 117 If the language tag argument is omitted, the server SHOULD send an 118 untagged LANGUAGE response listing the languages it supports. If 119 the server is unable to enumerate the list of languages it supports 120 it MAY return a tagged NO response to the enumeration request. 122 Example 4.2 123 =========== 125 < A LANGUAGE command with no arguments is a request to enumerate the 126 list of languages the server supports. > 128 C: A001 LANGUAGE 129 S: * LANGUAGE (EN DE IT i-default) 130 S: A001 OK Supported languages have been enumerated 132 C: A001 LANGUAGE 133 S: A002 NO Server is unable to enumerate supported languages 135 If the server supports the IMAP4 NAMESPACE command [IMAP-NAMESPACE], 136 the server SHOULD return an untagged NAMESPACE response if namespace 137 information changed as a result of the LANGUAGE command. Note that 138 the namespace prefix is to a mailbox and following IMAP4 convention, 139 any international string in the NAMESPACE response MUST be of 140 modified UTF-7 format as described in [RFC-2060]. 142 Example 4.3 143 =========== 145 < In this example a server supports the IMAP4 NAMESPACE command. It 146 uses no prefix to the user's Personal Namespace, a prefix of "Other 147 Users" to its Other Users' Namespace and a prefix of "Public 148 Folders" to its only Shared Namespace. Since a client will often 149 display these prefixes to the user, the server changes these based 150 on the language of the connecting client. > 152 C: A001 LANGUAGE FR-CA 153 S: * NAMESPACE (("" "/"))(("Autres Utilisateurs/" "/")) (("Dossiers 154 Publics" "/") 155 S: A001 OK La Language commande a ete executee avec success 157 Gahrns and McCown 3 158 IMAP4 Language Extension November 1997 160 Note: A server should be aware that changing the namespace prefixes 161 based upon the language of the connecting client can invalidate 162 mailbox URLs that are shared by clients of various languages. 163 Addressing this issue is outside the scope of this document, and is 164 part of a much larger problem of how a client should share/send urls 165 to a particular mailbox that may be represented differently by the 166 server based upon the identity of the connected user. 168 5. Formal Syntax 170 The following syntax specification uses the augmented Backus-Naur 171 Form (BNF) as described in [ABNF]. 173 LANGUAGE_Command = "LANGUAGE" [SP ] 175 LANGUAGE_Response = "*" SP "LANGUAGE" SP "(" 1* ")" 176 ; Note: the server is required to support the language i-default 177 ; and as such i-default must appear in the language response. 178 ; Although primarily English text, the "i-default" language may 179 ; contain some non-English text. 180 ; Any international characters in the "i-default" response 181 ; text MUST be encoded as per as defined in 182 ; [RFC-2060] and not as 184 = as defined in [RFC-1766] 186 ; After the server is changed to a language other than English, the 187 resp_text as defined by [RFC-2060] becomes: 189 resp_text = ["[" "]" SP 190 ; any valid UTF-8 character as defined in [RFC-2044] 193 6. Security Considerations 195 This extension allows the negotiation of a language for the human- 196 readable text returned by a server. A user is able to query the 197 languages that a server supports. 199 7. References 201 [RFC-1766], Alvestrand, H., "Tags for the Identification of 202 Languages", RFC 1766, UNINETT, March 1995 204 Gahrns and McCown 4 205 IMAP4 Language Extension November 1997 207 [RFC-2044], Yergeau, F., " UTF-8, a transformation format of Unicode 208 and ISO 10646, RFC 2044, Alis Technologies, October, 1996 210 [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version 211 4rev1", RFC 2060, University of Washington, December 1996. 213 [RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate 214 Requirement Levels", RFC 2119, Harvard University, March 1997 216 [ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for 217 Syntax Specifications: ABNF", draft-drums-abnf-04.txt (work in 218 progress), Internet Mail Consortium, September 1997 220 [CHARSET-POLICY], Alvestrand, H., "IETF Policy on Character Sets and 221 Languages", draft-alvestrand-charset-policy-02.txt (work in 222 progress), UNINETT, October 1997 224 [IMAP-NAMESPACE], Gahrns, M., "IMAP4 Namespace", draft-gahrns-imap- 225 namespace-05.txt (work in progress), Microsoft, November 1997 227 8. Acknowledgments 229 Many people have participated in discussions about an IMAP Language 230 extension in the various fora of the IETF and the internet working 231 groups, so any list of contributors is bound to be incomplete. 232 However, the authors would like to thank John Myers and Chris Newman 233 for their suggestions regarding the namespace issue and Larry 234 Osterman for his review of this document. 236 9. Author's Address 238 Mike Gahrns 239 Microsoft 240 One Microsoft Way 241 Redmond, WA, 98072 243 Phone: (425) 936-9833 244 Email: mikega@microsoft.com 246 Andrew McCown 247 Mitsubishi Electric ITA 248 1432 Main St. 249 Waltham MA, 02154 251 Email: andy@meitca.com 253 Gahrns and McCown 5