idnits 2.17.1 draft-newman-url-imap-01.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 6 instances of too long lines in the document, the longest one being 5 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 83: '...n mechanism. It MAY use any mechanism...' RFC 2119 keyword, line 126: '...s created. This MAY be used by the pr...' RFC 2119 keyword, line 145: '...fined above. The SHOULD...' RFC 2119 keyword, line 301: '...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 (October 1996) is 10054 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-01.txt October 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= 53 imap:////? 54 imap://////
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. The characters ";", "?", and "/" 59 are reserved, and must be encoded if present in the , 60 , , or . 62 3. IMAP User Name, Password and Authentication mechanism 64 A user name, password and/or authentication mechanism may be 65 supplied. They are used in the "LOGIN" or "AUTHENTICATE" commands 66 after making the connection to the IMAP server. If no user name, 67 password or authentication mechanism is supplied, the user name 68 "anonymous" is used with the "LOGIN" command and the password is 69 supplied as the Internet e-mail address of the end user accessing 70 the resource. If the URL supplies a user name but no password, the 71 program interpreting the IMAP URL should request one from the user 72 if necessary. 74 An authentication mechanism can be expressed by adding 75 ";AUTH=" to the end of the URL. When such an 76 is indicated, the client should request appropriate 77 credentials from that mechanism and use the "AUTHENTICATE" command 78 instead of the "LOGIN" command. If no user name is specified, one 79 should be obtained from the mechanism or requested from the user as 80 appropriate. 82 The string ";AUTH=*" indicates that the client should select an 83 appropriate authentication mechanism. It MAY use any mechanism 84 listed in the CAPABILITY command or use an out of band security 85 service resulting in a PREAUTH connection. If no user name is 86 specified and no appropriate authentication mechanisms are 87 available, the client should fall back to anonymous login as 88 described above. This allows a URL which grants read-write access 89 to authorized users, and read-only anonymous access to other users. 91 4. Lists of mailboxes 93 An IMAP URL referring to a list of mailboxes has the following 94 form: 96 imap:///;type= 98 The may be either "LIST" or "LSUB", and is case 99 insensitive. The field ";TYPE=" may be omitted, in which 100 case ";TYPE=LIST" is assumed. 102 The is any argument suitable for the list_mailbox 103 field of the IMAP [IMAP4] LIST or LSUB commands. The field 104 may be omitted, in which case the program 105 interpreting the IMAP URL may use "*" or "%" as the . 106 The client should use "%" if it supports a hierarchical view, 107 otherwise it should use "*". 109 Note that if unsafe or reserved characters such as " ", "/", or "%" 110 are present in they must be encoded as defined in 111 RFC 1738 [RFC1738]. 113 5. Lists of messages 115 An IMAP URL referring to a list of messages has the following form: 117 imap:////? 119 The field is used as the argument to the IMAP4 "SELECT" 120 command. Note that if unsafe or reserved characters such as " " or 121 "/" are present in they must be encoded as defined in RFC 122 1738 [RFC1738]. 124 The field is optional. If it is present, it must be 125 the argument to the IMAP4 UIDVALIDITY status response at the time 126 the URL was created. This MAY be used by the program interpreting 127 the IMAP URL to determine if the URL is stale. 129 The "?" field is optional. If it is not present, a 130 list of all messages in the mailbox should be presented by the 131 program interpreting the URL. If it is present, it should be used 132 as all the arguments following an IMAP4 SEARCH command. Note that 133 unsafe characters such as " " are likely to be present in the 134 and must be encoded as defined in RFC 1738 135 [RFC1738]. 137 6. A specific message or message part 139 An IMAP URL referring to a specific message or message part has the 140 following form: 142 imap://////
144 The is as defined above. The is mandatory 145 for this format and is as defined above. The SHOULD 146 be used by the program interpreting the URL to determine if the URL 147 is stale. 149 The refers to an IMAP4 message UID, and should be used as the 150 argument to the IMAP4 "UID FETCH" command. 152 The
field is optional. If not present, the URL refers to 153 the entire RFC 822 message as returned by the IMAP command "UID 154 FETCH RFC822". If present, the URL refers to the object 155 returned by a "UID FETCH BODY[
]" command. The type 156 of the object may be determined by "UID FETCH BODYSTRUCTURE" 157 and locating the appropriate part. Note that unsafe characters in 158
, such as " " must be encoded as defined in RFC 1738 159 [RFC1738]. 161 7. Examples 163 The following examples demonstrate how an IMAP4 client program 164 might translate various IMAP4 URL into a series of IMAP4 commands. 165 Commands sent from the client to the server are prefixed with "C:", 166 and responses sent from the server to the client are prefixed with 167 "S:". 169 The URL: 171 173 Results in the following client commands: 175 176 C: A001 LOGIN ANONYMOUS sheridan@babylon5.org 177 C: A002 SELECT grey-council 178 179 C: A003 UID FETCH 20 RFC822.PEEK 181 The URL: 183 185 Results in the following client commands: 187 188 189 C: A001 LOGIN MICHAEL zipper 190 C: A002 LIST "" users.* 192 The URL: 194 196 Results in the following client commands: 198 199 C: A001 AUTHENTICATE KERBEROS_V4 200 201 C: A002 SELECT grey-council 202 203 C: A003 UID FETCH 20 BODY.PEEK[1.2] 205 The URL: 207 209 Could result in the following: 211 212 C: A001 CAPABILITY 213 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI 214 S: A001 OK 215 C: A002 AUTHENTICATE GSSAPI 216 217 S: A002 OK user lennier authenticated 218 C: A003 SELECT grey-council 219 ... 220 C: A004 SEARCH SUBJECT shadows 221 S: * SEARCH 8 10 13 14 15 16 222 S: A004 OK SEARCH completed 223 C: A005 FETCH 8,10,13:16 ALL 224 ... 226 NOTE: In this final example, the client has implementation dependant 227 choices. The authentication mechanism could be anything, including 228 PREAUTH. And the final FETCH command could fetch more or less 229 information about the messages, depending on what it wishes to 230 display to the user. 232 8. ABNF for IMAP URL scheme 234 This uses ABNF as used in the IMAP specification [IMAP4]. 235 Terminals from the BNF for URLs [RFC1738] are also used. 237 imapurl ::= "imap://" ilogin "/" [ icommand ] [ iauth ] 239 iauth ::= ";AUTH=" ( "*" / auth_type ) 240 ; unsafe characters in auth_type are 241 ; encoded as in [RFC1738] 242 ; ";AUTH=" is not case sensitive 244 icommand ::= imailboxlist / ipath / isearch 246 ilogin ::= [ iuser [ ":" ipassword ] "@" ] hostport 248 imailboxlist ::= list_mailbox [ ";TYPE=" list_type ] 249 ; unsafe characters in list_mailbox are 250 ; encoded as in [RFC1738] 251 ; ";TYPE=" is not case sensitive 253 ipassword ::= *( uchar / "&" / "=" ) 255 ipath ::= mailbox "/" nz_number "/" number [ "/" section ] 256 ; unsafe characters in mailbox and section are 257 ; encoded as in [RFC1738] 258 ; IMAP4 literals may not be used in mailbox 260 isearch ::= mailbox "/" [nz_number] [ "?" search_program ] 261 ; unsafe characters in mailbox and 262 ; search_program, including SPACE, ";", and "/", 263 ; are encoded as in [RFC1738] 264 ; IMAP4 literals may not be used in mailbox 265 ; or search_program 267 iuser ::= *( uchar / "&" / "=" ) 269 list_type ::= "LIST" / "LSUB" 270 ; case insensitive 272 search_program ::= ["CHARSET" SPACE astring SPACE] search_criteria 273 ; IMAP4 literals may not be used 275 9. References 277 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 278 4", RFC 1730, University of Washington, December 1994. 280 282 [RFC1738] Berners-Lee, Masinter, McCahill, "Uniform Resource 283 Locators (URL)", RFC 1738, CERN, Xerox Coproration, University of 284 Minnesota, December 1994. 286 288 10. Security Considerations 290 IMAP URLs have the same security considerations as general Internet 291 URLs [RFC1738]. Specifically, including passwords in the URL makes 292 the password vulnerable to network evesdroppers both when the URL 293 is transmitted and when the "LOGIN" command is sent to the IMAP 294 server. For this reason, including passwords in the URL is 295 discouraged. 297 Security considerations discussed in the IMAP specification [IMAP4] 298 are also relevant. 300 Client authors should be careful when selecting an authentication 301 mechanism if ";AUTH=*" is specified. Clients SHOULD NOT fall back 302 to the "LOGIN" command with a user other than "anonymous" if more 303 secure mechanisms are available to the client. A client which 304 violates this rule is vulnerable to an active attacker which spoofs 305 the server and does not declare support for any AUTHENTICATE 306 mechanisms. 308 11. Author's Address 310 Chris Newman 311 Innosoft International, Inc. 312 1050 East Garvey Ave. South 313 West Covina, CA 91790 USA 315 Email: chris.newman@innosoft.com