idnits 2.17.1 draft-daboo-imap-commandplus-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == There is 1 instance of lines with non-ascii characters in the document. == 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 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 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 1999) is 9136 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 822 (Obsoleted by RFC 2822) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Daboo 2 Internet Draft: IMAP4 COMMAND+ Extension B. Leiba 3 Document: draft-daboo-imap-commandplus-00.txt April 1999 5 IMAP4 COMMAND+ Extension 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The COMMAND+ extension to the Internet Message Access Protocol 31 [IMAP4] defines a formal syntax for extending [IMAP4] commands. 32 This includes adding requirements on future extensions to the 33 [IMAP4] syntax that may add new commands, so that any command in an 34 [IMAP4] session, be it part of the base-specification, or a current 35 or future extension, can be extended in an arbitrary manner, without 36 conflicts in syntax between current or future extensions. 38 Copyright Notice 40 Copyright (C) The Internet Society (1999). All Rights Reserved. 42 1. Introduction and Overview 44 The COMMAND+ extension is present in any IMAP4 implementation which 45 returns "COMMAND+" as one of the supported capabilities to the 46 CAPABILITY command. 48 The COMMAND+ extension specifies a new syntax for all IMAP4 49 commands. 51 The design goal for COMMAND+ is to ensure an easy way to extend 52 IMAP4 commands with "options", defined in other extension documents. 53 By following the design rules laid out in this document, authors of 54 future extensions can ensure that their extension syntax will allow 55 other extensions to coexist. 57 The goal of this extension is to remove the need to define separate 58 commands that modify the behaviour of an existing IMAP4 command, and 59 therefore to cut down on the number of possibilities where multiple 60 options for a single IMAP4 command are required. The aim is to 61 provide a framework for adding 'options' to any IMAP4 command in an 62 extensible manner, that will work with both current and future 63 extensions. 65 2. Conventions Used in This Document 67 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 68 NOT", and "MAY" in this document are to be interpreted as described 69 in "Key words for use in RFCs to Indicate Requirement Levels" 70 [KEYWORDS]. 72 Formal syntax is defined using the augmented Backus-Naur Form (BNF) 73 notation as specified in [RFC-822] as modified by [IMAP4]. 75 In examples, "C:" and "S:" indicate lines sent by the client and 76 server respectively. 78 This document uses the following terms to describe an IMAP4 command 79 sent by the client to the server. 81 command 82 refers to the [IMAP4] command sent by a client to a server. 83 Note this can apply to commands introduced by extensions, 84 not just commands in the base specificiation [IMAP4]. 85 tag 86 refers to the [IMAP4] tag at the start of every command 87 line. 88 command descriptor 89 refers to the "base" unmodified command syntax following the 90 tag as defined in the "base" document for the corresponding 91 command. 93 command options 94 a set of options, as defined in a separate extension 95 document, that extends a command. 96 option arguments 97 a set of arguments that can be applied to an option to 98 modify the behaviour the option has on the corresponding 99 command. 100 option data 101 a set of data "objects" added to the end of a command when a 102 command option needs to include large volumes of information 103 in an option argument. 105 3. Modification to IMAP command syntax 107 When the COMMAND+ extension is in effect, any IMAP4 command MAY 108 accept command options that modify the behaviour of that command. 110 To specify command options, the client MUST prefix the command 111 descriptor with the command option list. The options themselves are 112 defined in separate extensions that MUST be advertised as one of the 113 supported capabilities of the CAPABILITY command. Each option MAY 114 also include option arguments that allow the command option to be 115 further extended if required. 117 Example: 118 C: A001 CAPABILITY 119 S: * CAPABILITY IMAP4rev1 COMMAND+ LISTCHILDREN LISTREFERRAL 120 S: A001 OK 121 ... 122 C: A006 (LISTCHILDREN () LISTREFERRAL (ALL)) LIST "" "%" 123 S: ... 124 S: A006 OK 126 In the above example, the "LISTCHILDREN" and "LISTREFERRAL" command 127 options are added by the client to the LIST command. These command 128 options modify the server behaviour for the LIST command based on 129 the corresponding extension document defining these extensions. The 130 "LISTREFERRAL" command option includes the "ALL" option argument 131 which modifies the behaviour of the command option in some 132 particular manner. 134 A command option may define that additional option data is appended 135 to the end of the command descriptor. This may be useful when the 136 command option requires an argument whose size may be large, and the 137 processing of which is better deferred until after the base command 138 has been processed by the server. 140 Example: 141 C: A006 (ADDNOTES ()) CREATE INBOX.test ({19} 142 S: + Ready for literal data 143 C: Here are some notes) 144 S: A006 OK 146 Extensions that allow this type of behaviour with the [IMAP4] SEARCH 147 command MUST require that the search keys are explicitly surrounded 148 by parenthesis, which are normally implicit to the SEARCH command. 150 Example: 151 C: A007 (MORE ()) SEARCH (SUBJECT FROM) ("extra data") 153 If multiple command options add option data to the end of a command 154 descriptor, then the option data MUST appear in the same order as 155 the command options appear in the command option list. 157 Example: 158 C: A007 (X () Y () Z ()) SEARCH (SUBJECT) ("X-data") ("Z-data") 160 In order to support this extension the following must be adhered to: 162 * A server that advertises a capability that has a command 163 option associated with it MUST be prepared to accept that 164 command option. 166 * A server MUST respond with a tagged BAD to any command that 167 contains a command option for which the server did not advertise 168 support. 170 * A client MUST NOT send a command option for which the server 171 did not advertise support. 173 * A client MUST NOT send an empty command option list. 175 * Each command option MUST include a parenthesised option 176 argument list that MAY be empty. 178 * A command option MAY define that additional option data be 179 added after the command descriptor. 181 * Additional option data at the end of a command descriptor MUST 182 appear in the same order as the corresponding command options in 183 the command option list. 185 * Future extensions MUST NOT define a command descriptor that 186 begins with the "(" character. 188 4. Formal Syntax 190 The following syntax specification uses the augmented Backus-Naur 191 Form (BNF) notation as specified in [RFC-822] as modified by 192 [IMAP4]. Non-terminals referenced but not defined below are as 193 defined by [IMAP4]. 195 Except as noted otherwise, all alphabetic characters are 196 case-insensitive. The use of upper or lower case characters to 197 define token strings is for editorial clarity only. Implementations 198 MUST accept these strings in a case-insensitive fashion. 200 command_ex ::= tag SPACE 201 ["(" command_opt [*(SPACE command_opt)] ")" SPACE] 202 (command_any / command_auth / command_nonauth / 203 command_select / command_extension) 204 [*(SPACE option_data)] CRLF 206 command_extension ::= ;; command defined by an extension specification 208 command_opt ::= option_name SPACE 209 "(" [option_arg *(SPACE option_arg)] ")" 211 option_name ::= 1*ATOM_CHAR 213 ;; defined by extension specification 215 option_arg ::= astring / nstring / number / snumber / 216 "(" option_arg *(SPACE option_arg) ")" 218 ;; defined by extension specification 220 option_data ::= "(" option_arg *(SPACE option_arg) ")" 222 ;; defined by extension specification 224 snumber ::= ["+" / "-"] 1*digit 226 ;; signed 32-bit integer 227 ;; (-2147483648 <= n <= 2147483647) 229 5. Security Considerations 231 Command options that modify any command relating to security (e.g. 232 authentication or security layer) MUST take security considerations 233 into account when defined. 235 6. References 237 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 238 Requirement Levels", RFC 2119, Harvard University, March 1997. 240 [IMAP4] Crispin, M., "Internet Message Access Protocol � Version 241 4rev1", RFC 2060, University of Washington, December 1996. 243 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 244 Text Messages", STD 11, RFC 822, University of Delaware, August 245 1982. 247 7. Acknowledgments 249 Mark Pustilnik and Bart Schaefer have made important contributions 250 to the creation and refinement of the ideas expressed in this 251 document. 253 8. Authors' Addresses 255 Cyrus Daboo 256 Cyrusoft International, Inc. 257 Suite 780, 5001 Baum Blvd. 258 Pittsburgh, PA 15213 260 Phone: (412)605-0499 261 Email: daboo@cyrusoft.com 263 Barry Leiba 264 IBM T.J. Watson Research Center 265 30 Saw Mill River Road 266 Hawthorne, NY 10532 268 Email: leiba@watson.ibm.com