idnits 2.17.1 draft-newman-url-imap-02.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-27) 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 11 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 81: '...n mechanism. It MAY use any mechanism...' RFC 2119 keyword, line 97: '... ";TYPE=" MUST be included....' RFC 2119 keyword, line 123: '...s created. This MAY be used by the pr...' RFC 2119 keyword, line 141: '...in this form, it SHOULD be used by the...' RFC 2119 keyword, line 303: '...ecified. Clients SHOULD NOT fall back...' 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 1996) is 10025 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 1730 (ref. 'IMAP4') (Obsoleted by RFC 2060, RFC 2061) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) Summary: 13 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-02.txt November 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, 43 files, and search programs on Internet hosts accessible using the 44 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=[iauth] 53 imap:///?[uidvalidity][iauth] 54 imap:///[uidvalidity][isection][iauth] 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, Password and Authentication mechanism 62 A user name, password and/or authentication mechanism 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 password or authentication mechanism 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 URL. 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 4. Lists of mailboxes 91 An IMAP URL referring to a list of mailboxes has the following 92 form: 94 imap:///;TYPE=[iauth] 96 The may be either "LIST" or "LSUB", and is case 97 insensitive. The field ";TYPE=" MUST be included. 99 The is any argument suitable for the 100 list_mailbox field of the IMAP [IMAP4] LIST or LSUB commands. The 101 field may be omitted, in which case the program 102 interpreting the IMAP URL may use "*" or "%" as the 103 . The program should use "%" if it supports a 104 hierarchical view, otherwise it should use "*". 106 Note that if unsafe or reserved characters such as " " or "%" are 107 present in they must be encoded as defined in 108 RFC 1738 [RFC1738]. 110 5. Lists of messages 112 An IMAP URL referring to a list of messages has the following form: 114 imap:///?[uidvalidity][iauth] 116 The field is used as the argument to the IMAP4 117 "SELECT" command. Note that if unsafe or reserved characters such 118 as " ", ";", or "?" are present in they must be 119 encoded as defined in RFC 1738 [RFC1738]. 121 The [uidvalidity] field is optional. If it is present, it must be 122 the argument to the IMAP4 UIDVALIDITY status response at the time 123 the URL was created. This MAY be used by the program interpreting 124 the IMAP URL to determine if the URL is stale. 126 The "?" field is optional. If it is not 127 present, a list of all messages in the mailbox should be presented 128 by the program interpreting the URL. If it is present, it should 129 be used as the arguments following an IMAP4 SEARCH command with 130 unsafe characters such as " " (which are likely to be present in 131 the ) encoded as defined in RFC 1738 [RFC1738]. 133 6. A specific message or message part 134 An IMAP URL referring to a specific message or message part has the 135 following form: 137 imap:///[uidvalidity][isection][iauth] 139 The and [uidvalidity] are as defined above. 141 If [uidvalidity] is present in this form, it SHOULD be used by the 142 program interpreting the URL to determine if the URL is stale. 144 The refers to an IMAP4 message UID, and should be used as the 145 argument to the IMAP4 "UID FETCH" command. 147 The [isection] field is optional. If not present, the URL refers 148 to the entire RFC 822 message as returned by the IMAP command "UID 149 FETCH RFC822.PEEK". If present, the URL refers to the object 150 returned by a "UID FETCH BODY.PEEK[
]" command. The 151 type of the object may be determined with a "UID FETCH 152 BODYSTRUCTURE" command and locating the appropriate part in the 153 resulting BODYSTRUCTURE. Note that unsafe characters in 154 [isection], such as " " must be encoded as defined in RFC 1738 155 [RFC1738]. 157 7. Examples 159 The following examples demonstrate how an IMAP4 client program 160 might translate various IMAP4 URL into a series of IMAP4 commands. 161 Commands sent from the client to the server are prefixed with "C:", 162 and responses sent from the server to the client are prefixed with 163 "S:". 165 The URL: 167 169 Results in the following client commands: 171 172 C: A001 LOGIN ANONYMOUS sheridan@babylon5.org 173 C: A002 SELECT grey-council 174 175 C: A003 UID FETCH 20 RFC822.PEEK 177 The URL: 179 181 Results in the following client commands: 183 184 185 C: A001 LOGIN MICHAEL zipper 186 C: A002 LIST "" users.* 188 The URL: 190 192 Results in the following client commands: 194 195 C: A001 AUTHENTICATE KERBEROS_V4 196 197 C: A002 SELECT grey-council 198 C: A003 UID FETCH 20 BODY.PEEK[1.2] 200 The URL: 202 204 Could result in the following: 206 207 C: A001 CAPABILITY 208 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI 209 S: A001 OK 210 C: A002 AUTHENTICATE GSSAPI 211 212 S: A002 OK user lennier authenticated 213 C: A003 SELECT "grey council" 214 ... 215 C: A004 SEARCH SUBJECT shadows 216 S: * SEARCH 8 10 13 14 15 16 217 S: A004 OK SEARCH completed 218 C: A005 FETCH 8,10,13:16 ALL 219 ... 221 NOTE: In this final example, the client has implementation dependant 222 choices. The authentication mechanism could be anything, including 223 PREAUTH. And the final FETCH command could fetch more or less 224 information about the messages, depending on what it wishes to display 225 to the user. 227 8. ABNF for IMAP URL scheme 229 This uses ABNF as used in the IMAP specification [IMAP4]. 230 Terminals from the BNF for URLs [RFC1738] are also used. Strings 231 are not case sensitive. 233 encoded_char ::= uchar / ":" / "@" / "&" / "=" / "/" 234 ; see RFC 1738 for "uchar" definition 236 enc_auth_type ::= 1*encoded_char 237 ; further defined in RFC 1730 "auth_type" 239 enc_list_mailbox ::= *encoded_char 240 ; further defined in RFC 1730 "list_mailbox" 242 enc_mailbox ::= 1*encoded_char 243 ; further defined in RFC 1730 "mailbox" 245 enc_search_program 246 ::= 1*encoded_char 247 ; encoded version of search_program below 249 imapurl ::= "imap://" login "/" [ icommand ] [ iauth ] 250 ; see RFC 1738 for "login" terminal 252 iauth ::= ";AUTH=" ( "*" / enc_auth_type ) 254 icommand ::= imailboxlist / ipath / isearch 256 imailboxlist ::= enc_list_mailbox [ ";TYPE=" list_type ] 258 ipath ::= enc_mailbox [uidvalidity] iuid [isection] 260 isearch ::= enc_mailbox [ "?" enc_search_program ] [uidvalidity] 262 isection ::= ";SECTION=" section 263 ; See RFC 1730 for "section" definition 265 iuid ::= ";UID=" nz_number 266 ; See RFC 1730 for "nz_number" definition 268 list_type ::= "LIST" / "LSUB" 270 search_program ::= ["CHARSET" SPACE astring SPACE] search_criteria 271 ; IMAP4 literals may not be used 272 ; See RFC 1730 for "astring" and "search_criteria" 274 uidvalidity ::= ";UIDVALIDITY=" nz_number 275 ; See RFC 1730 for "nz_number" definition 277 9. References 279 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 280 4", RFC 1730, University of Washington, December 1994. 282 284 [RFC1738] Berners-Lee, Masinter, McCahill, "Uniform Resource 285 Locators (URL)", RFC 1738, CERN, Xerox Coproration, University of 286 Minnesota, December 1994. 288 290 10. Security Considerations 292 IMAP URLs have the same security considerations as general Internet 293 URLs [RFC1738]. Specifically, including passwords in the URL makes 294 the password vulnerable to network evesdroppers both when the URL 295 is transmitted and when the "LOGIN" command is sent to the IMAP 296 server. For this reason, including passwords in the URL is 297 discouraged. 299 Security considerations discussed in the IMAP specification [IMAP4] 300 are also relevant. 302 Client authors should be careful when selecting an authentication 303 mechanism if ";AUTH=*" is specified. Clients SHOULD NOT fall back 304 to the "LOGIN" command with a user other than "anonymous" if more 305 secure mechanisms are available to the client. A client which 306 violates this rule is vulnerable to an active attacker which spoofs 307 the server and does not declare support for any AUTHENTICATE 308 mechanisms. 310 11. Author's Address 312 Chris Newman 313 Innosoft International, Inc. 314 1050 East Garvey Ave. South 315 West Covina, CA 91790 USA 316 Email: chris.newman@innosoft.com