idnits 2.17.1 draft-newman-url-imap-05.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-03-28) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 45: '... 1. MUST This word means that th...' RFC 2119 keyword, line 48: '... 2. MUST NOT This phrase means t...' RFC 2119 keyword, line 51: '... 3. SHOULD This word means that ...' RFC 2119 keyword, line 56: '... 4. SHOULD NOT This phrase means...' RFC 2119 keyword, line 62: '... 5. MAY This word means that an ...' (29 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 (January 1997) is 9934 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-05.txt January 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 this section. 45 1. MUST This word means that the definition is an absolute 46 requirement of the specification. 48 2. MUST NOT This phrase means that the definition is an absolute 49 prohibition of the specification. 51 3. SHOULD This word means that there may exist valid reasons in 52 particular circumstances to ignore a particular item, but the 53 full implications must be understood and carefully weighed 54 before choosing a different course. 56 4. SHOULD NOT This phrase means that there may exist valid 57 reasons in particular circumstances when the particular behavior 58 is acceptable or even useful, but the full implications should 59 be understood and the case carefully weighed before implementing 60 any behavior described with this label. 62 5. MAY This word means that an item is truly optional. One 63 vendor may choose to include the item because a particular 64 marketplace requires it or because the vendor feels that it 65 enhances the product while another vendor may omit the same 66 item. An implementation which does not include a particular 67 option MUST be prepared to interoperate with another 68 implementation which does include the option, though perhaps 69 with reduced functionality. In the same vein an implementation 70 which does include a particular option MUST be prepared to 71 interoperate with another implementation which does not include 72 the option (except, of course, for the feature the option 73 provides.) 75 3. IMAP scheme 77 The IMAP URL scheme is used to designate mailboxes, messages, MIME 78 bodies [MIME], and search programs on Internet hosts accessible 79 using the IMAP protocol. 81 The IMAP URL follows the common Internet scheme syntax as defined 82 in RFC 1738 [RFC1738]. If : is omitted, the port defaults to 83 143. 85 An IMAP URL takes one of the following forms: 87 imap:///;TYPE= 88 imap:///[uidvalidity]? 89 imap:///[uidvalidity][isection] 91 The first form is used to refer to a list of mailboxes, the second 92 form refers to a list of messages, and the final form refers to a 93 specific message or message part. 95 4. IMAP User Name, Authentication Mechanism and Password 97 A user name, authentication mechanism and/or password may be 98 supplied. They are used in the "LOGIN" or "AUTHENTICATE" commands 99 after making the connection to the IMAP server. If no user name, 100 authentication mechanism or password is supplied, the user name 101 "anonymous" is used with the "LOGIN" command and the password is 102 supplied as the Internet e-mail address of the end user accessing 103 the resource. If the URL supplies a user name but no password, the 104 program interpreting the IMAP URL SHOULD request one from the user 105 if necessary. 107 An authentication mechanism can be expressed by adding 108 ";AUTH=" to the end of the user name. When such an 109 is indicated, the client SHOULD request appropriate 110 credentials from that mechanism and use the "AUTHENTICATE" command 111 instead of the "LOGIN" command. If no user name is specified, one 112 SHOULD be obtained from the mechanism or requested from the user as 113 appropriate. 115 The string ";AUTH=*" indicates that the client SHOULD select an 116 appropriate authentication mechanism. It MAY use any mechanism 117 listed in the CAPABILITY command or use an out of band security 118 service resulting in a PREAUTH connection. If no user name is 119 specified and no appropriate authentication mechanisms are 120 available, the client SHOULD fall back to anonymous login as 121 described above. This allows a URL which grants read-write access 122 to authorized users, and read-only anonymous access to other users. 124 Note that if unsafe or reserved characters such as " " or ";" are 125 present in the user name, authentication mechanism or password, 126 they MUST be encoded as described in RFC 1738 [RFC1738]. 128 5. Lists of mailboxes 130 An IMAP URL referring to a list of mailboxes has the following 131 form: 133 imap:///;TYPE= 135 The may be either "LIST" or "LSUB", and is case 136 insensitive. The field ";TYPE=" MUST be included. 138 The is any argument suitable for the 139 list_mailbox field of the IMAP [IMAP4] LIST or LSUB commands. The 140 field may be omitted, in which case the program 141 interpreting the IMAP URL may use "*" or "%" as the 142 . The program SHOULD use "%" if it supports a 143 hierarchical view, otherwise it SHOULD use "*". 145 Note that if unsafe or reserved characters such as " " or "%" are 146 present in they MUST be encoded as described in 147 RFC 1738 [RFC1738]. If the character "/" is present in 148 enc_list_mailbox, it SHOULD NOT be encoded. 150 6. Lists of messages 152 An IMAP URL referring to a list of messages has the following form: 154 imap:///[uidvalidity]? 156 The field is used as the argument to the IMAP4 157 "SELECT" command. Note that if unsafe or reserved characters such 158 as " ", ";", or "?" are present in they MUST be 159 encoded as described in RFC 1738 [RFC1738]. If the character "/" 160 is present in enc_mailbox, it SHOULD NOT be encoded. 162 The [uidvalidity] field is optional. If it is present, it MUST be 163 the argument to the IMAP4 UIDVALIDITY status response at the time 164 the URL was created. This SHOULD be used by the program 165 interpreting the IMAP URL to determine if the URL is stale. 167 The "?" field is optional. If it is not 168 present, a list of all messages in the mailbox SHOULD be presented 169 by the program interpreting the URL. If it is present, it SHOULD 170 be used as the arguments following an IMAP4 SEARCH command with 171 unsafe characters such as " " (which are likely to be present in 172 the ) encoded as described in RFC 1738 173 [RFC1738]. 175 7. A specific message or message part 177 An IMAP URL referring to a specific message or message part has the 178 following form: 180 imap:///[uidvalidity][isection] 182 The and [uidvalidity] are as defined above. 184 If [uidvalidity] is present in this form, it SHOULD be used by the 185 program interpreting the URL to determine if the URL is stale. 187 The refers to an IMAP4 message UID, and SHOULD be used as the 188 argument to the IMAP4 "UID FETCH" command. 190 The [isection] field is optional. If not present, the URL refers 191 to the entire RFC 822 message as returned by the IMAP command "UID 192 FETCH RFC822.PEEK". If present, the URL refers to the object 193 returned by a "UID FETCH BODY.PEEK[
]" command. The 194 type of the object may be determined with a "UID FETCH 195 BODYSTRUCTURE" command and locating the appropriate part in the 196 resulting BODYSTRUCTURE. Note that unsafe characters in 197 [isection], such as " " MUST be encoded as described in RFC 1738 198 [RFC1738]. 200 8. Relative IMAP URLs 202 Relative IMAP URLs are permitted and are resolved according to the 203 rules defined in RFC 1808 [RFC1808] with one exception. When the 204 relative URL includes a "SECTION=" parameter and does not include a 205 "UID=" parameter, then the "UID=" parameter is inherited from the 206 base URL. The following observations are also important: 208 The grammar element is considered part of the user name for 209 purposes of resolving relative IMAP URLs. This means that unless a 210 new login/server specification is included in the relative URL, the 211 authentication mechanism is inherited from a base IMAP URL. 213 URLs always use "/" as the hierarchy delimiter for the purpose of 214 resolving paths in relative URLs. IMAP4 permits the use of any 215 hierarchy delimiter in mailbox names. For this reason, relative 216 mailbox paths will only work if the mailbox uses "/" as the 217 hierarchy delimiter. Relative URLs may be used on mailboxes which 218 use other delimiters, but in that case, the entire mailbox name 219 MUST be specified in the relative URL or inherited as a whole from 220 the base URL. 222 The base URL for a list of mailboxes or messages which was referred 223 to by an IMAP URL is always the referring IMAP URL itself. The 224 base URL for a message or message part which was referred to by an 225 IMAP URL may be more complicated to determine. The program 226 interpreting the relative URL will have to check the headers of the 227 MIME entity and any enclosing MIME entities in order to locate the 228 "Content-Base" and "Content-Location" headers. These headers are 229 used to determine the base URL as defined in [HTTP]. For example, 230 if the referring IMAP URL contains a ";SECTION=1.2" parameter, then 231 the MIME headers for section 1.2, for section 1, and for the 232 enclosing message itself SHOULD be checked in that order for 233 "Content-Base" or "Content-Location" headers. 235 9. Examples 237 The following examples demonstrate how an IMAP4 client program 238 might translate various IMAP4 URL into a series of IMAP4 commands. 239 Commands sent from the client to the server are prefixed with "C:", 240 and responses sent from the server to the client are prefixed with 241 "S:". 243 The URL: 245 247 Results in the following client commands: 249 250 C: A001 LOGIN ANONYMOUS sheridan@babylon5.org 251 C: A002 SELECT gray-council 252 253 C: A003 UID FETCH 20 RFC822.PEEK 255 The URL: 257 259 Results in the following client commands: 261 262 263 C: A001 LOGIN MICHAEL zipper 264 C: A002 LIST "" users.* 266 The URL: 268 270 Results in the following client commands: 272 273 C: A001 AUTHENTICATE KERBEROS_V4 274 275 C: A002 SELECT gray-council 276 C: A003 UID FETCH 20 BODY.PEEK[1.2] 278 If the following relative URL is located in that body part: 280 <;section=1.4> 282 This could result in the following client commands: 284 C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME] 285 BODY.PEEK[1.MIME] 286 BODY.PEEK[HEADER.FIELDS (Content-Base Content-Location)]) 287 289 C: A005 UID FETCH 20 BODY.PEEK[1.4] 291 The URL: 293 295 Could result in the following: 297 298 C: A001 CAPABILITY 299 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI 300 S: A001 OK 301 C: A002 AUTHENTICATE GSSAPI 302 303 S: A002 OK user lennier authenticated 304 C: A003 SELECT "gray council" 305 ... 306 C: A004 SEARCH SUBJECT shadows 307 S: * SEARCH 8 10 13 14 15 16 308 S: A004 OK SEARCH completed 309 C: A005 FETCH 8,10,13:16 ALL 310 ... 312 NOTE: In this final example, the client has implementation dependent 313 choices. The authentication mechanism could be anything, including 314 PREAUTH. And the final FETCH command could fetch more or less 315 information about the messages, depending on what it wishes to display 316 to the user. 318 10. ABNF for IMAP URL scheme 320 This uses ABNF as used in the IMAP specification [IMAP4]. 321 Terminals from the BNF for URLs [RFC1738] are also used. Strings 322 are not case sensitive. 324 achar ::= uchar / "&" / "=" / "~" 325 ; see RFC 1738 for "uchar" definition 327 bchar ::= achar / ":" / "@" / "/" 329 enc_auth_type ::= 1*achar 330 ; encoded version of [IMAP-AUTH] "auth_type" 332 enc_list_mailbox ::= 1*bchar 333 ; encoded version of [IMAP4] "list_mailbox" 335 enc_mailbox ::= 1*bchar 336 ; encoded version of [IMAP4] "mailbox" 338 enc_pass ::= *achar 339 ; encoded version of [IMAP4] "password" 341 enc_search_program 342 ::= 1*bchar 343 ; encoded version of search_program below 345 enc_section ::= 1*bchar 346 ; encoded version of section below 348 enc_user ::= *achar 349 ; encoded version of [IMAP4] "userid" 351 imapurl ::= "imap://" iserver "/" [ icommand ] [ iauth ] 353 iauth ::= ";AUTH=" ( "*" / enc_auth_type ) 355 icommand ::= imailboxlist / ipath / isearch 357 imailboxlist ::= [enc_list_mailbox] [ ";TYPE=" list_type ] 359 ipath ::= enc_mailbox [uidvalidity] iuid [isection] 361 isearch ::= enc_mailbox [ "?" enc_search_program ] [uidvalidity] 363 isection ::= ";SECTION=" enc_section 364 iserver ::= [enc_user [ iauth ] [ ":" enc_pass ] "@"] hostport 365 ; See RFC 1738 for "hostport" definition 367 iuid ::= ";UID=" nz_number 368 ; See [IMAP4] for "nz_number" definition 370 list_type ::= "LIST" / "LSUB" 372 search_program ::= ["CHARSET" SPACE astring SPACE] 1#search_key 373 ; IMAP4 literals may not be used 374 ; See [IMAP4] for "astring" and "search_key" 376 section ::= section_text / (nz_number *["." nz_number] 377 ["." (section_text / "MIME")]) 378 ; See [IMAP4] for "section_text" and "nz_number" 380 uidvalidity ::= ";UIDVALIDITY=" nz_number 381 ; See [IMAP4] for "nz_number" definition 383 11. References 385 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 386 4rev1", RFC 2060, University of Washington, December 1996. 388 390 [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, 391 Carnegie-Mellon University, December 1994. 393 395 [MIME] Freed, N., Borenstein, N., "Multipurpose Internet Mail 396 Extensions", RFC 2045, Innosoft, First Virtual, November 1996. 398 400 [RFC1738] Berners-Lee, Masinter, McCahill, "Uniform Resource 401 Locators (URL)", RFC 1738, CERN, Xerox Coproration, University of 402 Minnesota, December 1994. 404 406 [RFC1808] Fielding, "Relative Uniform Resource Locators", RFC 1808, 407 UC Irvine, June 1995. 409 411 [HTTP] Fielding, Gettys, Mogul, Frystyk, Berners-Lee, "Hypertext 412 Transfer Protocol -- HTTP/1.1", RFC 2068, UC Irvine, DEC, MIT/LCS, 413 January 1997. 415 417 12. Security Considerations 419 IMAP URLs have the same security considerations as general Internet 420 URLs [RFC1738]. Specifically, including passwords in the URL makes 421 the password vulnerable to network eavesdroppers both when the URL 422 is transmitted and when the "LOGIN" command is sent to the IMAP 423 server. Some web browsers store URLs in history files which may 424 expose them further. For these reasons, passwords SHOULD NOT be in 425 the URL. 427 Security considerations discussed in the IMAP specification [IMAP4] 428 are also relevant. 430 Client authors SHOULD be careful when selecting an authentication 431 mechanism if ";AUTH=*" is specified. Clients SHOULD NOT fall back 432 to the "LOGIN" command with a user other than "anonymous". A 433 client which violates this rule is vulnerable to an active attacker 434 which spoofs the server and does not declare support for any 435 AUTHENTICATE mechanisms. 437 Many email clients store the plain text password for later use 438 after logging into an IMAP server. Such clients MUST NOT use a 439 stored password in response to an IMAP URL without explicit 440 permission from the user to supply that password to the specified 441 host name. 443 13. Author's Address 445 Chris Newman 446 Innosoft International, Inc. 447 1050 East Garvey Ave. South 448 West Covina, CA 91790 USA 450 Email: chris.newman@innosoft.com