idnits 2.17.1 draft-newman-url-imap-00.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-26) 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 6 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 105: '...s created. This MAY be used by the pr...' RFC 2119 keyword, line 124: '...fined above. The SHOULD...' 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 10055 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-00.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 Name and Password 64 A user name and password may be supplied. They are used in the 65 "LOGIN" command after making the connection to the IMAP server. If 66 no user name or password is supplied, the user name "anonymous" is 67 used and the password is supplied as the Internet e-mail address of 68 the end user accessing the resource. If the URL supplies a user 69 name but no password, the program interpreting the IMAP URL should 70 request one from the user. 72 4. Lists of mailboxes 74 An IMAP URL referring to a list of mailboxes has the following 75 form: 77 imap:///;type= 79 The may be either "LIST" or "LSUB", and is case 80 insensitive. The field ";type=" may be omitted, in which 81 case ";type=LIST" is assumed. 83 The is any argument suitable for the list_mailbox 84 field of the IMAP [IMAP4] LIST or LSUB commands. The field 85 "/" may be omitted, in which case the program 86 interpreting the IMAP URL may use "*" or "%" as the . 88 Note that if unsafe or reserved characters such as " ", "/", or "%" 89 are present in they must be encoded as defined in 90 RFC 1738 [RFC1738]. 92 5. Lists of messages 94 An IMAP URL referring to a list of messages has the following form: 96 imap:////? 98 The field is used as the argument to the IMAP4 "SELECT" 99 command. Note that if unsafe or reserved characters such as " " or 100 "/" are present in they must be encoded as defined in RFC 101 1738 [RFC1738]. 103 The field is optional. If it is present, it must be 104 the argument to the IMAP4 UIDVALIDITY status response at the time 105 the URL was created. This MAY be used by the program interpreting 106 the IMAP URL to determine if the URL is stale. 108 The "?" field is optional. If it is not present, a 109 list of all messages in the mailbox should be presented by the 110 program interpreting the URL. If it is present, it should be used 111 as all the arguments following an IMAP4 SEARCH command. Note that 112 unsafe characters such as " " are likely to be present in the 113 and must be encoded as defined in RFC 1738 114 [RFC1738]. 116 6. A specific message or message part 118 An IMAP URL referring to a specific message or message part has the 119 following form: 121 imap://////
123 The is as defined above. The is mandatory 124 for this format and is as defined above. The SHOULD 125 be used by the program interpreting the URL to determine if the URL 126 is stale. 128 The refers to an IMAP4 message UID, and should be used as the 129 argument to the IMAP4 "UID FETCH" command. 131 The
field is optional. If not present, the URL refers to 132 the entire RFC 822 message as returned by the IMAP command "UID 133 FETCH RFC822". If present, the URL refers to the object 134 returned by a "UID FETCH BODY[
]" command. The type 135 of the object may be determined by "UID FETCH BODYSTRUCTURE" 136 and locating the appropriate part. Note that unsafe characters in 137
, such as " " must be encoded as defined in RFC 1738 138 [RFC1738]. 140 7. ABNF for IMAP URL scheme 142 This uses ABNF as used in the IMAP specification [IMAP4]. 143 Terminals from the BNF for URLs [RFC1738] are also used. 145 imapurl ::= "imap://" ilogin [ imailboxlist / isearch / ipath ] 147 ilogin ::= [ iuser [ ":" ipassword ] "@" ] hostport 149 imailboxlist ::= "/" list_mailbox [ ";type=" list_type ] 150 ;; unsafe characters in list_mailbox are 151 ;; encoded as in [RFC1738] 153 ipassword ::= *( uchar / "&" / "=" ) 155 ipath ::= "/" mailbox "/" nz_number "/" number [ "/" section ] 156 ;; unsafe characters in mailbox and section are 157 ;; encoded as in [RFC1738] 158 ;; IMAP4 literals may not be used in mailbox 160 isearch ::= "/" mailbox "/" [nz_number] [ "?" search_program ] 161 ;; unsafe characters in mailbox and 162 ;; search_program, including SPACE and "/", 163 ;; are encoded as in [RFC1738] 164 ;; IMAP4 literals may not be used in mailbox 165 ;; or search_program 167 iuser ::= *( uchar / "&" / "=" ) 169 list_type ::= "LIST" / "LSUB" 170 ;; case insensitive 172 search_program ::= ["CHARSET" SPACE astring SPACE] search_criteria 173 ;; IMAP4 literals may not be used 175 8. References 177 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 178 4", RFC 1730, University of Washington, December 1994. 180 182 [RFC1738] Berners-Lee, Masinter, McCahill, "Uniform Resource 183 Locators (URL)", RFC 1738, CERN, Xerox Coproration, University of 184 Minnesota, December 1994. 186 188 9. Security Considerations 190 IMAP URLs have the same security considerations as general Internet 191 URLs [RFC1738]. Issues discussed in the IMAP specification [IMAP4] 192 are also relevant. No new security issues are introduced in this 193 document. 195 10. Author's Address 197 Chris Newman 198 Innosoft 199 1050 East Garvey Ave. South 200 West Covina, CA 91790 USA 202 Email: chris.newman@innosoft.com