idnits 2.17.1 draft-newman-url-imap-06.txt: 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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 are 7 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and 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? RFC 2119 keyword, line 76: '...ing the IMAP URL SHOULD request one fr...' RFC 2119 keyword, line 81: '...ated, the client SHOULD request approp...' RFC 2119 keyword, line 84: '... SHOULD be obtained from the mecha...' RFC 2119 keyword, line 87: '...cates that the client SHOULD select an...' RFC 2119 keyword, line 88: '...n mechanism. It MAY use any mechanism...' (23 more instances...) 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 (March 1997) is 9903 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 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1808 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) Summary: 15 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: IMAP URL Scheme Innosoft 4 Document: draft-newman-url-imap-06.txt March 1997 6 IMAP URL Scheme 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 six months after publication. Distribution of 30 this draft is unlimited. 32 1. Introduction 34 IMAP [IMAP4] is a rich protocol for accessing remote message 35 stores. It provides an ideal mechanism for accessing public 36 mailing list archives as well as private and shared message stores. 37 This document defines a URL scheme for referencing objects on an 38 IMAP server. 40 2. Conventions used in this document 42 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 43 in this document are to be interpreted as defined in RFC XXXX- 44 draft-bradner-key-words-03.txt. 46 3. IMAP scheme 48 The IMAP URL scheme is used to designate mailboxes, messages, MIME 49 bodies [MIME], and search programs on Internet hosts accessible 50 using the IMAP protocol. 52 The IMAP URL follows the common Internet scheme syntax as defined 53 in RFC 1738 [RFC1738]. If : is omitted, the port defaults to 54 143. 56 An IMAP URL takes one of the following forms: 58 imap:///;TYPE= 59 imap:///[uidvalidity][?] 60 imap:///[uidvalidity][isection] 62 The first form is used to refer to a list of mailboxes, the second 63 form refers to the contents of a mailbox or a set of messages 64 resulting from a search, and the final form refers to a specific 65 message or message part. 67 4. IMAP User Name, Authentication Mechanism and Password 69 A user name, authentication mechanism and/or password may be 70 supplied. They are used in the "LOGIN" or "AUTHENTICATE" commands 71 after making the connection to the IMAP server. If no user name, 72 authentication mechanism or password is supplied, the user name 73 "anonymous" is used with the "LOGIN" command and the password is 74 supplied as the Internet e-mail address of the end user accessing 75 the resource. If the URL supplies a user name but no password, the 76 program interpreting the IMAP URL SHOULD request one from the user 77 if necessary. 79 An authentication mechanism can be expressed by adding 80 ";AUTH=" to the end of the user name. When such an 81 is indicated, the client SHOULD request appropriate 82 credentials from that mechanism and use the "AUTHENTICATE" command 83 instead of the "LOGIN" command. If no user name is specified, one 84 SHOULD be obtained from the mechanism or requested from the user as 85 appropriate. 87 The string ";AUTH=*" indicates that the client SHOULD select an 88 appropriate authentication mechanism. It MAY use any mechanism 89 listed in the CAPABILITY command or use an out of band security 90 service resulting in a PREAUTH connection. If no user name is 91 specified and no appropriate authentication mechanisms are 92 available, the client SHOULD fall back to anonymous login as 93 described above. This allows a URL which grants read-write access 94 to authorized users, and read-only anonymous access to other users. 96 Note that if unsafe or reserved characters such as " " or ";" are 97 present in the user name, authentication mechanism or password, 98 they MUST be encoded as described in RFC 1738 [RFC1738]. 100 5. Lists of mailboxes 102 An IMAP URL referring to a list of mailboxes has the following 103 form: 105 imap:///;TYPE= 107 The may be either "LIST" or "LSUB", and is case 108 insensitive. The field ";TYPE=" MUST be included. 110 The is any argument suitable for the 111 list_mailbox field of the IMAP [IMAP4] LIST or LSUB commands. The 112 field may be omitted, in which case the program 113 interpreting the IMAP URL may use "*" or "%" as the 114 . The program SHOULD use "%" if it supports a 115 hierarchical view, otherwise it SHOULD use "*". 117 Note that if unsafe or reserved characters such as " " or "%" are 118 present in they MUST be encoded as described in 119 RFC 1738 [RFC1738]. If the character "/" is present in 120 enc_list_mailbox, it SHOULD NOT be encoded. 122 6. Lists of messages 124 An IMAP URL referring to a list of messages has the following form: 126 imap:///[uidvalidity][?] 128 The field is used as the argument to the IMAP4 129 "SELECT" command. Note that if unsafe or reserved characters such 130 as " ", ";", or "?" are present in they MUST be 131 encoded as described in RFC 1738 [RFC1738]. If the character "/" 132 is present in enc_mailbox, it SHOULD NOT be encoded. 134 The [uidvalidity] field is optional. If it is present, it MUST be 135 the argument to the IMAP4 UIDVALIDITY status response at the time 136 the URL was created. This SHOULD be used by the program 137 interpreting the IMAP URL to determine if the URL is stale. 139 The [?] field is optional. If it is not present, the 140 contents of the mailbox SHOULD be presented by the program 141 interpreting the URL. If it is present, it SHOULD be used as the 142 arguments following an IMAP4 SEARCH command with unsafe characters 143 such as " " (which are likely to be present in the ) 144 encoded as described in RFC 1738 [RFC1738]. 146 7. A specific message or message part 148 An IMAP URL referring to a specific message or message part has the 149 following form: 151 imap:///[uidvalidity][isection] 153 The and [uidvalidity] are as defined above. 155 If [uidvalidity] is present in this form, it SHOULD be used by the 156 program interpreting the URL to determine if the URL is stale. 158 The refers to an IMAP4 message UID, and SHOULD be used as the 159 argument to the IMAP4 "UID FETCH" command. 161 The [isection] field is optional. If not present, the URL refers 162 to the entire RFC 822 message as returned by the IMAP command "UID 163 FETCH RFC822.PEEK". If present, the URL refers to the object 164 returned by a "UID FETCH BODY.PEEK[
]" command. The 165 type of the object may be determined with a "UID FETCH 166 BODYSTRUCTURE" command and locating the appropriate part in the 167 resulting BODYSTRUCTURE. Note that unsafe characters in 168 [isection], such as " " MUST be encoded as described in RFC 1738 169 [RFC1738]. 171 8. Relative IMAP URLs 173 Relative IMAP URLs are permitted and are resolved according to the 174 rules defined in RFC 1808 [RFC1808] with one exception. When the 175 relative URL includes a "SECTION=" parameter and does not include a 176 "UID=" parameter, then the "UID=" parameter is inherited from the 177 base URL. The following observations are also important: 179 The grammar element is considered part of the user name for 180 purposes of resolving relative IMAP URLs. This means that unless a 181 new login/server specification is included in the relative URL, the 182 authentication mechanism is inherited from a base IMAP URL. 184 URLs always use "/" as the hierarchy delimiter for the purpose of 185 resolving paths in relative URLs. IMAP4 permits the use of any 186 hierarchy delimiter in mailbox names. For this reason, relative 187 mailbox paths will only work if the mailbox uses "/" as the 188 hierarchy delimiter. Relative URLs may be used on mailboxes which 189 use other delimiters, but in that case, the entire mailbox name 190 MUST be specified in the relative URL or inherited as a whole from 191 the base URL. 193 The base URL for a list of mailboxes or messages which was referred 194 to by an IMAP URL is always the referring IMAP URL itself. The 195 base URL for a message or message part which was referred to by an 196 IMAP URL may be more complicated to determine. The program 197 interpreting the relative URL will have to check the headers of the 198 MIME entity and any enclosing MIME entities in order to locate the 199 "Content-Base" and "Content-Location" headers. These headers are 200 used to determine the base URL as defined in [HTTP]. For example, 201 if the referring IMAP URL contains a ";SECTION=1.2" parameter, then 202 the MIME headers for section 1.2, for section 1, and for the 203 enclosing message itself SHOULD be checked in that order for 204 "Content-Base" or "Content-Location" headers. 206 9. Multinational Considerations 208 IMAP4 [IMAP4] section 5.1.3 includes a convention for encoding 209 non-US-ASCII characters in IMAP mailbox names. This convention MAY 210 be used in IMAP4 URLs, although this results in rather ugly URLs. 212 Proposals have been made within the IETF to standardize a single 213 encoding for multinational characters in URLs. Programs generating 214 and interpreting IMAP URLs may need to convert between IMAP's 215 international mailbox naming convention and any future standard for 216 multinational characters in URLs so that those characters can be 217 displayed unencoded to the user. 219 10. Examples 221 The following examples demonstrate how an IMAP4 client program 222 might translate various IMAP4 URL into a series of IMAP4 commands. 223 Commands sent from the client to the server are prefixed with "C:", 224 and responses sent from the server to the client are prefixed with 225 "S:". 227 The URL: 229 231 Results in the following client commands: 233 234 C: A001 LOGIN ANONYMOUS sheridan@babylon5.org 235 C: A002 SELECT gray-council 236 237 C: A003 UID FETCH 20 RFC822.PEEK 239 The URL: 241 243 Results in the following client commands: 245 246 247 C: A001 LOGIN MICHAEL zipper 248 C: A002 LIST "" users.* 250 The URL: 252 254 Results in the following client commands: 256 257 C: A001 AUTHENTICATE KERBEROS_V4 258 259 C: A002 SELECT gray-council 260 C: A003 UID FETCH 20 BODY.PEEK[1.2] 262 If the following relative URL is located in that body part: 264 <;section=1.4> 266 This could result in the following client commands: 268 C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME] 269 BODY.PEEK[1.MIME] 270 BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)]) 271 273 C: A005 UID FETCH 20 BODY.PEEK[1.4] 275 The URL: 277 279 Could result in the following: 281 282 C: A001 CAPABILITY 283 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI 284 S: A001 OK 285 C: A002 AUTHENTICATE GSSAPI 286 287 S: A002 OK user lennier authenticated 288 C: A003 SELECT "gray council" 289 ... 290 C: A004 SEARCH SUBJECT shadows 291 S: * SEARCH 8 10 13 14 15 16 292 S: A004 OK SEARCH completed 293 C: A005 FETCH 8,10,13:16 ALL 294 ... 296 NOTE: In this final example, the client has implementation dependent 297 choices. The authentication mechanism could be anything, including 298 PREAUTH. And the final FETCH command could fetch more or less 299 information about the messages, depending on what it wishes to display 300 to the user. 302 11. ABNF for IMAP URL scheme 304 This uses ABNF as used in the IMAP specification [IMAP4]. 305 Terminals from the BNF for URLs [RFC1738] are also used. Strings 306 are not case sensitive. 308 achar ::= uchar / "&" / "=" / "~" 309 ; see RFC 1738 for "uchar" definition 311 bchar ::= achar / ":" / "@" / "/" 313 enc_auth_type ::= 1*achar 314 ; encoded version of [IMAP-AUTH] "auth_type" 316 enc_list_mailbox ::= 1*bchar 317 ; encoded version of [IMAP4] "list_mailbox" 319 enc_mailbox ::= 1*bchar 320 ; encoded version of [IMAP4] "mailbox" 322 enc_pass ::= *achar 323 ; encoded version of [IMAP4] "password" 325 enc_search ::= 1*bchar 326 ; encoded version of search_program below 328 enc_section ::= 1*bchar 329 ; encoded version of section below 331 enc_user ::= *achar 332 ; encoded version of [IMAP4] "userid" 334 imapurl ::= "imap://" iserver "/" [ icommand ] [ iauth ] 336 iauth ::= ";AUTH=" ( "*" / enc_auth_type ) 338 icommand ::= imailboxlist / ipath / isearch 340 imailboxlist ::= [enc_list_mailbox] [ ";TYPE=" list_type ] 342 ipath ::= enc_mailbox [uidvalidity] iuid [isection] 344 isearch ::= enc_mailbox [ "?" enc_search ] [uidvalidity] 346 isection ::= ";SECTION=" enc_section 348 iserver ::= [enc_user [ iauth ] [ ":" enc_pass ] "@"] hostport 349 ; See RFC 1738 for "hostport" definition 351 iuid ::= ";UID=" nz_number 352 ; See [IMAP4] for "nz_number" definition 354 list_type ::= "LIST" / "LSUB" 356 search_program ::= ["CHARSET" SPACE astring SPACE] 1#search_key 357 ; IMAP4 literals may not be used 358 ; See [IMAP4] for "astring" and "search_key" 360 section ::= section_text / (nz_number *["." nz_number] 361 ["." (section_text / "MIME")]) 362 ; See [IMAP4] for "section_text" and "nz_number" 364 uidvalidity ::= ";UIDVALIDITY=" nz_number 365 ; See [IMAP4] for "nz_number" definition 367 12. References 369 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 370 4rev1", RFC 2060, University of Washington, December 1996. 372 374 [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, 375 Carnegie-Mellon University, December 1994. 377 379 [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail 380 Extensions", RFC 2045, Innosoft, First Virtual, November 1996. 382 384 [RFC1738] Berners-Lee, Masinter, McCahill, "Uniform Resource 385 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 386 Minnesota, December 1994. 388 390 [RFC1808] Fielding, "Relative Uniform Resource Locators", RFC 1808, 391 UC Irvine, June 1995. 393 395 [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext 396 Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS, 397 January 1997. 399 401 13. Security Considerations 403 IMAP URLs have the same security considerations as general Internet 404 URLs [RFC1738]. Specifically, including passwords in the URL makes 405 the password vulnerable to network eavesdroppers both when the URL 406 is transmitted and when the "LOGIN" command is sent to the IMAP 407 server. Some web browsers store URLs in history files which may 408 expose them further. For these reasons, passwords SHOULD NOT be in 409 the URL. 411 Security considerations discussed in the IMAP specification [IMAP4] 412 are also relevant. 414 Client authors SHOULD be careful when selecting an authentication 415 mechanism if ";AUTH=*" is specified. Clients SHOULD NOT fall back 416 to the "LOGIN" command with a user other than "anonymous". A 417 client which violates this rule is vulnerable to an active attacker 418 which spoofs the server and does not declare support for any 419 AUTHENTICATE mechanisms. 421 Many email clients store the plain text password for later use 422 after logging into an IMAP server. Such clients MUST NOT use a 423 stored password in response to an IMAP URL without explicit 424 permission from the user to supply that password to the specified 425 host name. 427 14. Author's Address 429 Chris Newman 430 Innosoft International, Inc. 431 1050 East Garvey Ave. South 432 West Covina, CA 91790 USA 434 Email: chris.newman@innosoft.com