idnits 2.17.1 draft-newman-url-imap-04.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-16) 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 10 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. RFC 2119 keyword, line 69: '...ing the IMAP URL SHOULD request one fr...' RFC 2119 keyword, line 74: '...ated, the client SHOULD request approp...' RFC 2119 keyword, line 77: '... SHOULD be obtained from the mecha...' RFC 2119 keyword, line 80: '...cates that the client SHOULD select an...' RFC 2119 keyword, line 81: '...n mechanism. It MAY use any mechanism...' (21 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 (December 1996) is 9984 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTP' Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 3 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-04.txt December 1996 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. IMAP scheme 42 The IMAP URL scheme is used to designate mailboxes, messages, MIME 43 bodies [MIME], and search programs on Internet hosts accessible 44 using the IMAP protocol. 46 The IMAP URL follows the common Internet scheme syntax as defined 47 in RFC 1738 [RFC1738]. If : is omitted, the port defaults to 48 143. 50 An IMAP URL takes one of the following forms: 52 imap:///;TYPE= 53 imap:///[uidvalidity]? 54 imap:///[uidvalidity][isection] 56 The first form is used to refer to a list of mailboxes, the second 57 form refers to a list of messages, and the final form refers to a 58 specific message or message part. 60 3. IMAP User Name, Authentication Mechanism and Password 62 A user name, authentication mechanism and/or password may be 63 supplied. They are used in the "LOGIN" or "AUTHENTICATE" commands 64 after making the connection to the IMAP server. If no user name, 65 authentication mechanism or password is supplied, the user name 66 "anonymous" is used with the "LOGIN" command and the password is 67 supplied as the Internet e-mail address of the end user accessing 68 the resource. If the URL supplies a user name but no password, the 69 program interpreting the IMAP URL SHOULD request one from the user 70 if necessary. 72 An authentication mechanism can be expressed by adding 73 ";AUTH=" to the end of the user name. When such an 74 is indicated, the client SHOULD request appropriate 75 credentials from that mechanism and use the "AUTHENTICATE" command 76 instead of the "LOGIN" command. If no user name is specified, one 77 SHOULD be obtained from the mechanism or requested from the user as 78 appropriate. 80 The string ";AUTH=*" indicates that the client SHOULD select an 81 appropriate authentication mechanism. It MAY use any mechanism 82 listed in the CAPABILITY command or use an out of band security 83 service resulting in a PREAUTH connection. If no user name is 84 specified and no appropriate authentication mechanisms are 85 available, the client SHOULD fall back to anonymous login as 86 described above. This allows a URL which grants read-write access 87 to authorized users, and read-only anonymous access to other users. 89 Note that if unsafe or reserved characters such as " " or ";" are 90 present in the user name, authentication mechanism or password, 91 they MUST be encoded as described in RFC 1738 [RFC1738]. 93 4. Lists of mailboxes 95 An IMAP URL referring to a list of mailboxes has the following 96 form: 98 imap:///;TYPE= 100 The may be either "LIST" or "LSUB", and is case 101 insensitive. The field ";TYPE=" MUST be included. 103 The is any argument suitable for the 104 list_mailbox field of the IMAP [IMAP4] LIST or LSUB commands. The 105 field may be omitted, in which case the program 106 interpreting the IMAP URL may use "*" or "%" as the 107 . The program SHOULD use "%" if it supports a 108 hierarchical view, otherwise it SHOULD use "*". 110 Note that if unsafe or reserved characters such as " " or "%" are 111 present in they MUST be encoded as described in 112 RFC 1738 [RFC1738]. If the character "/" is present in 113 enc_list_mailbox, it SHOULD NOT be encoded. 115 5. Lists of messages 117 An IMAP URL referring to a list of messages has the following form: 119 imap:///[uidvalidity]? 121 The field is used as the argument to the IMAP4 122 "SELECT" command. Note that if unsafe or reserved characters such 123 as " ", ";", or "?" are present in they MUST be 124 encoded as described in RFC 1738 [RFC1738]. If the character "/" 125 is present in enc_mailbox, it SHOULD NOT be encoded. 127 The [uidvalidity] field is optional. If it is present, it MUST be 128 the argument to the IMAP4 UIDVALIDITY status response at the time 129 the URL was created. This MAY be used by the program interpreting 130 the IMAP URL to determine if the URL is stale. 132 The "?" field is optional. If it is not 133 present, a list of all messages in the mailbox SHOULD be presented 134 by the program interpreting the URL. If it is present, it SHOULD 135 be used as the arguments following an IMAP4 SEARCH command with 136 unsafe characters such as " " (which are likely to be present in 137 the ) encoded as described in RFC 1738 138 [RFC1738]. 140 6. A specific message or message part 142 An IMAP URL referring to a specific message or message part has the 143 following form: 145 imap:///[uidvalidity][isection] 147 The and [uidvalidity] are as defined above. 149 If [uidvalidity] is present in this form, it SHOULD be used by the 150 program interpreting the URL to determine if the URL is stale. 152 The refers to an IMAP4 message UID, and SHOULD be used as the 153 argument to the IMAP4 "UID FETCH" command. 155 The [isection] field is optional. If not present, the URL refers 156 to the entire RFC 822 message as returned by the IMAP command "UID 157 FETCH RFC822.PEEK". If present, the URL refers to the object 158 returned by a "UID FETCH BODY.PEEK[
]" command. The 159 type of the object may be determined with a "UID FETCH 160 BODYSTRUCTURE" command and locating the appropriate part in the 161 resulting BODYSTRUCTURE. Note that unsafe characters in 162 [isection], such as " " MUST be encoded as described in RFC 1738 163 [RFC1738]. 165 7. Relative IMAP URLs 167 Relative IMAP URLs are permitted and are resolved according to the 168 rules defined in RFC 1808 [RFC1808] with one exception. When the 169 relative URL includes a "SECTION=" parameter and does not include a 170 "UID=" parameter, then the "UID=" parameter is inherited from the 171 base URL. The following observations are also important: 173 The grammar element is considered part of the user name for 174 purposes of resolving relative IMAP URLs. This means that unless a 175 new login/server specification is included in the relative URL, the 176 authentication mechanism is inherited from a base IMAP URL. 178 URLs always use "/" as the hierarchy delimiter for the purpose of 179 resolving paths in relative URLs. IMAP4 permits the use of any 180 hierarchy delimiter in mailbox names. For this reason, relative 181 mailbox paths will only work if the mailbox uses "/" as the 182 hierarchy delimiter. Relative URLs may be used on mailboxes which 183 use other delimiters, but in that case, the entire mailbox name 184 MUST be specified in the relative URL or inherited as a whole from 185 the base URL. 187 The base URL for a list of mailboxes or messages which was referred 188 to by an IMAP URL is always the referring IMAP URL itself. The 189 base URL for a message or message part which was referred to by an 190 IMAP URL may be more complicated to determine. The program 191 interpreting the relative URL will have to check the headers of the 192 MIME entity and any enclosing MIME entities in order to locate the 193 "Content-Base" and "Content-Location" headers. These headers are 194 used to determine the base URL as defined in [HTTP]. For example, 195 if the referring IMAP URL contains a ";SECTION=1.2" parameter, then 196 the MIME headers for section 1.2, for section 1, and for the 197 enclosing message itself SHOULD be checked in that order for 198 "Content-Base" or "Content-Location" headers. 200 8. Examples 202 The following examples demonstrate how an IMAP4 client program 203 might translate various IMAP4 URL into a series of IMAP4 commands. 204 Commands sent from the client to the server are prefixed with "C:", 205 and responses sent from the server to the client are prefixed with 206 "S:". 208 The URL: 210 212 Results in the following client commands: 214 215 C: A001 LOGIN ANONYMOUS sheridan@babylon5.org 216 C: A002 SELECT gray-council 217 218 C: A003 UID FETCH 20 RFC822.PEEK 220 The URL: 222 224 Results in the following client commands: 226 227 228 C: A001 LOGIN MICHAEL zipper 229 C: A002 LIST "" users.* 231 The URL: 233 235 Results in the following client commands: 237 238 C: A001 AUTHENTICATE KERBEROS_V4 239 240 C: A002 SELECT gray-council 241 C: A003 UID FETCH 20 BODY.PEEK[1.2] 243 If the following relative URL is located in that body part: 245 <;section=1.4> 247 This could result in the following client commands: 249 C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME] 250 BODY.PEEK[1.MIME] 251 BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)]) 252 254 C: A005 UID FETCH 20 BODY.PEEK[1.4] 256 The URL: 258 260 Could result in the following: 262 263 C: A001 CAPABILITY 264 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI 265 S: A001 OK 266 C: A002 AUTHENTICATE GSSAPI 267 268 S: A002 OK user lennier authenticated 269 C: A003 SELECT "gray council" 270 ... 271 C: A004 SEARCH SUBJECT shadows 272 S: * SEARCH 8 10 13 14 15 16 273 S: A004 OK SEARCH completed 274 C: A005 FETCH 8,10,13:16 ALL 275 ... 277 NOTE: In this final example, the client has implementation dependent 278 choices. The authentication mechanism could be anything, including 279 PREAUTH. And the final FETCH command could fetch more or less 280 information about the messages, depending on what it wishes to display 281 to the user. 283 9. ABNF for IMAP URL scheme 285 This uses ABNF as used in the IMAP specification [IMAP4]. 286 Terminals from the BNF for URLs [RFC1738] are also used. Strings 287 are not case sensitive. 289 achar ::= uchar / "&" / "=" / "~" 290 ; see RFC 1738 for "uchar" definition 292 bchar ::= achar / ":" / "@" / "/" 294 enc_auth_type ::= 1*achar 295 ; encoded version of [IMAP-AUTH] "auth_type" 297 enc_list_mailbox ::= 1*bchar 298 ; encoded version of [IMAP4] "list_mailbox" 300 enc_mailbox ::= 1*bchar 301 ; encoded version of [IMAP4] "mailbox" 303 enc_pass ::= *achar 304 ; encoded version of [IMAP4] "password" 306 enc_search_program 307 ::= 1*bchar 308 ; encoded version of search_program below 310 enc_section ::= 1*bchar 311 ; encoded version of section below 313 enc_user ::= *achar 314 ; encoded version of [IMAP4] "userid" 316 imapurl ::= "imap://" iserver "/" [ icommand ] [ iauth ] 318 iauth ::= ";AUTH=" ( "*" / enc_auth_type ) 320 icommand ::= imailboxlist / ipath / isearch 322 imailboxlist ::= [enc_list_mailbox] [ ";TYPE=" list_type ] 324 ipath ::= enc_mailbox [uidvalidity] iuid [isection] 325 isearch ::= enc_mailbox [ "?" enc_search_program ] [uidvalidity] 327 isection ::= ";SECTION=" enc_section 329 iserver ::= [enc_user [ iauth ] [ ":" enc_pass ] "@"] hostport 330 ; See RFC 1738 for "hostport" definition 332 iuid ::= ";UID=" nz_number 333 ; See [IMAP4] for "nz_number" definition 335 list_type ::= "LIST" / "LSUB" 337 search_program ::= ["CHARSET" SPACE astring SPACE] 1#search_key 338 ; IMAP4 literals may not be used 339 ; See [IMAP4] for "astring" and "search_key" 341 section ::= section_text / (nz_number *["." nz_number] 342 ["." (section_text / "MIME")]) 343 ; See [IMAP4] for "section_text" and "nz_number" 345 uidvalidity ::= ";UIDVALIDITY=" nz_number 346 ; See [IMAP4] for "nz_number" definition 348 10. References 350 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 351 4rev1", RFC 2060, University of Washington, December 1996. 353 355 [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, 356 Carnegie-Mellon University, December 1994. 358 360 [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail 361 Extensions", RFC 2045, Innosoft, First Virtual, November 1996. 363 365 [RFC1738] Berners-Lee, Masinter, McCahill, "Uniform Resource 366 Locators (URL)", RFC 1738, CERN, Xerox Coproration, University of 367 Minnesota, December 1994. 369 371 [RFC1808] Fielding, "Relative Uniform Resource Locators", RFC 1808, 372 UC Irvine, June 1995. 374 376 [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext 377 Transfer Protocol -- HTTP/1.1", Work in Progress, UC Irvine, Dec, 378 MIT/LCS, August 1996. 380 11. Security Considerations 382 IMAP URLs have the same security considerations as general Internet 383 URLs [RFC1738]. Specifically, including passwords in the URL makes 384 the password vulnerable to network eavesdroppers both when the URL 385 is transmitted and when the "LOGIN" command is sent to the IMAP 386 server. For this reason, including passwords in the URL is 387 discouraged. 389 Security considerations discussed in the IMAP specification [IMAP4] 390 are also relevant. 392 Client authors SHOULD be careful when selecting an authentication 393 mechanism if ";AUTH=*" is specified. Clients SHOULD NOT fall back 394 to the "LOGIN" command with a user other than "anonymous". A 395 client which violates this rule is vulnerable to an active attacker 396 which spoofs the server and does not declare support for any 397 AUTHENTICATE mechanisms. 399 Many email clients store the plain text password for later use 400 after logging into an IMAP server. Such clients MUST NOT use a 401 stored password in response to an IMAP URL without explicit 402 permission from the user to supply that password to the specified 403 host name. 405 12. Author's Address 407 Chris Newman 408 Innosoft International, Inc. 409 1050 East Garvey Ave. South 410 West Covina, CA 91790 USA 412 Email: chris.newman@innosoft.com