idnits 2.17.1 draft-crispin-imap-obsolete-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-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 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 Introduction 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.) ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([TEXT], [HEADER], [0], [RFC-822]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 36: '...AP4 implementations MAY implement this...' RFC 2119 keyword, line 224: '... responses MUST NOT be transmitted b...' RFC 2119 keyword, line 225: '... implementations SHOULD accept these r...' RFC 2119 keyword, line 235: '...MAILBOX response MUST NOT be transmitt...' RFC 2119 keyword, line 238: '...e these commands MAY ignore this respo...' (4 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 (March 1996) is 10268 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) -- Missing reference section? 'RFC-822' on line 194 looks like a reference -- Missing reference section? '0' on line 197 looks like a reference -- Missing reference section? 'HEADER' on line 196 looks like a reference -- Missing reference section? 'TEXT' on line 217 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Crispin 3 Internet Draft: IMAP4 University of Washington 4 Document: internet-drafts/draft-crispin-imap-obsolete-00.txt March 1996 6 INTERNET MESSAGE ACCESS PROTOCOL - OBSOLETE SYNTAX 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 months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 A revised version of this draft document will be submitted to the RFC 27 editor as an Informational RFC for the Internet Community. 28 Discussion and suggestions for improvement are requested, and should 29 be sent to imap@CAC.Washington.EDU. This document will expire before 30 30 September 1996. Distribution of this memo is unlimited. 32 Abstract 34 This document describes obsolete syntax which may be encountered by 35 IMAP4 implementations which deal with older versions of the Internet 36 Mail Access Protocol. IMAP4 implementations MAY implement this 37 syntax in order to maximize interoperability with older 38 implementations. 40 This document repeats information from earlier documents, most 41 notably RFC 1176 and RFC 1730. 43 Obsolete Commands and Fetch Data Items 45 The following commands are OBSOLETE. It is NOT required to support 46 any of these commands or fetch data items in new server 47 implementations. These commands are documented here for the benefit 48 of implementors who may wish to support them for compatibility with 49 old client implementations. 51 The section headings of these commands are intended to correspond 52 with where they would be located in the main document if they were 53 not obsoleted. 55 6.3.OBS.1. FIND ALL.MAILBOXES Command 57 Arguments: mailbox name with possible wildcards 59 Data: untagged responses: MAILBOX 61 Result: OK - find completed 62 NO - find failure: can't list that name 63 BAD - command unknown or arguments invalid 65 The FIND ALL.MAILBOXES command returns a subset of names from the 66 complete set of all names available to the user. It returns zero 67 or more untagged MAILBOX replies. The mailbox argument to FIND 68 ALL.MAILBOXES is similar to that for LIST with an empty reference, 69 except that the characters "%" and "?" match a single character. 71 Example: C: A002 FIND ALL.MAILBOXES * 72 S: * MAILBOX blurdybloop 73 S: * MAILBOX INBOX 74 S: A002 OK FIND ALL.MAILBOXES completed 76 6.3.OBS.2. FIND MAILBOXES Command 78 Arguments: mailbox name with possible wildcards 80 Data: untagged responses: MAILBOX 82 Result: OK - find completed 83 NO - find failure: can't list that name 84 BAD - command unknown or arguments invalid 86 The FIND MAILBOXES command returns a subset of names from the set 87 of names that the user has declared as being "active" or 88 "subscribed". It returns zero or more untagged MAILBOX replies. 90 The mailbox argument to FIND MAILBOXES is similar to that for LSUB 91 with an empty reference, except that the characters "%" and "?" 92 match a single character. 94 Example: C: A002 FIND MAILBOXES * 95 S: * MAILBOX blurdybloop 96 S: * MAILBOX INBOX 97 S: A002 OK FIND MAILBOXES completed 99 6.3.OBS.3. SUBSCRIBE MAILBOX Command 101 Arguments: mailbox name 103 Data: no specific data for this command 105 Result: OK - subscribe completed 106 NO - subscribe failure: can't subscribe to that name 107 BAD - command unknown or arguments invalid 109 The SUBSCRIBE MAILBOX command is identical in effect to the 110 SUBSCRIBE command. A server which implements this command must be 111 able to distinguish between a SUBSCRIBE MAILBOX command and a 112 SUBSCRIBE command with a mailbox name argument of "MAILBOX". 114 Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime 115 S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime 116 completed 117 C: A003 SUBSCRIBE MAILBOX 118 S: A003 OK SUBSCRIBE to MAILBOX completed 120 6.3.OBS.4. UNSUBSCRIBE MAILBOX Command 122 Arguments: mailbox name 124 Data: no specific data for this command 126 Result: OK - unsubscribe completed 127 NO - unsubscribe failure: can't unsubscribe that name 128 BAD - command unknown or arguments invalid 130 The UNSUBSCRIBE MAILBOX command is identical in effect to the 131 UNSUBSCRIBE command. A server which implements this command must 132 be able to distinguish between a UNSUBSCRIBE MAILBOX command and 133 an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX". 135 Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime 136 S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime 137 completed 138 C: A003 UNSUBSCRIBE MAILBOX 139 S: A003 OK UNSUBSCRIBE from MAILBOX completed 141 6.4.OBS.1 PARTIAL Command 143 Arguments: message sequence number 144 message data item name 145 position of first octet 146 number of octets 148 Data: untagged responses: FETCH 150 Result: OK - partial completed 151 NO - partial error: can't fetch that data 152 BAD - command unknown or arguments invalid 154 The PARTIAL command is equivalent to the associated FETCH command, 155 with the added functionality that only the specified number of 156 octets, beginning at the specified starting octet, are returned. 157 Only a single message can be fetched at a time. The first octet 158 of a message, and hence the minimum for the starting octet, is 159 octet 1. 161 The following FETCH items are valid data for PARTIAL: RFC822, 162 RFC822.HEADER, RFC822.TEXT, BODY[
], as well as any .PEEK 163 forms of these. 165 Any partial fetch that attempts to read beyond the end of the text 166 is truncated as appropriate. If the starting octet is beyond the 167 end of the text, an empty string is returned. 169 The data are returned with the FETCH response. There is no 170 indication of the range of the partial data in this response. It 171 is not possible to stream multiple PARTIAL commands of the same 172 data item without processing and synchronizing at each step, since 173 streamed commands may be executed out of order. 175 There is no requirement that partial fetches follow any sequence. 176 For example, if a partial fetch of octets 1 through 10000 breaks 177 in an awkward place for BASE64 decoding, it is permitted to 178 continue with a partial fetch of 9987 through 19987, etc. 180 The handling of the \Seen flag is the same as in the associated 181 FETCH command. 183 Example: C: A005 PARTIAL 4 RFC822 1 1024 184 S: * 1 FETCH (RFC822 {1024} 185 S: Return-Path: 186 S: ... 187 S: ......... FLAGS (\Seen)) 188 S: A005 OK PARTIAL completed 190 6.4.5.OBS.1 Obsolete FETCH Data Items 192 The following FETCH data items are obsolete: 194 BODY[<...>0] A body part number of 0 is the [RFC-822] header of 195 the message. BODY[0] is functionally equivalent to 196 BODY[HEADER], differing in the syntax of the 197 resulting untagged FETCH data (BODY[0] is 198 returned). 200 RFC822.HEADER.LINES 201 Functionally equivalent to BODY.PEEK[HEADER.LINES 202 ], differing in the syntax of the 203 resulting untagged FETCH data (RFC822.HEADER is 204 returned). 206 RFC822.HEADER.LINES.NOT 207 Functionally equivalent to 208 BODY.PEEK[HEADER.LINES.NOT ], 209 differing in the syntax of the resulting untagged 210 FETCH data (RFC822.HEADER is returned). 212 RFC822.PEEK Functionally equivalent to BODY.PEEK[], except for 213 the syntax of the resulting untagged FETCH data 214 (RFC822 is returned). 216 RFC822.TEXT.PEEK 217 Functionally equivalent to BODY.PEEK[TEXT], except 218 for the syntax of the resulting untagged FETCH data 219 (RFC822.TEXT is returned). 221 Obsolete Responses 223 The following responses are OBSOLETE. Except as noted below, these 224 responses MUST NOT be transmitted by new server implementations. 225 Client implementations SHOULD accept these responses. 227 The section headings of these responses are intended to correspond 228 with where they would be located in the main document if they were 229 not obsoleted. 231 7.2.OBS.1. MAILBOX Response 233 Data: name 235 The MAILBOX response MUST NOT be transmitted by server 236 implementations except in response to the obsolete FIND MAILBOXES 237 and FIND ALL.MAILBOXES commands. Client implementations that do 238 not use these commands MAY ignore this response. It is documented 239 here for the benefit of implementors who may wish to support it 240 for compatibility with old client implementations. 242 This response occurs as a result of the FIND MAILBOXES and FIND 243 ALL.MAILBOXES commands. It returns a single name that matches the 244 FIND specification. There are no attributes or hierarchy 245 delimiter. 247 Example: S: * MAILBOX blurdybloop 249 7.3.OBS.1. COPY Response 251 Data: none 253 The COPY response MUST NOT be transmitted by new server 254 implementations. Client implementations MUST ignore the COPY 255 response. It is documented here for the benefit of client 256 implementors who may encounter this response from old server 257 implementations. 259 In some experimental versions of this protocol, this response was 260 returned in response to a COPY command to indicate on a 261 per-message basis that the message was copied successfully. 263 Example: S: * 44 COPY 265 7.3.OBS.2. STORE Response 267 Data: message data 269 The STORE response MUST NOT be transmitted by new server 270 implementations. Client implementations MUST treat the STORE 271 response as equivalent to the FETCH response. It is documented 272 here for the benefit of client implementors who may encounter this 273 response from old server implementations. 275 In some experimental versions of this protocol, this response was 276 returned instead of FETCH in response to a STORE command to report 277 the new value of the flags. 279 Example: S: * 69 STORE (FLAGS (\Deleted)) 281 Formal Syntax of Obsolete Commands and Responses 283 Each obsolete syntax rule that is suffixed with "_old" is added to 284 the corresponding name in the formal syntax. For example, 285 command_auth_old adds the FIND command to command_auth. 287 command_auth_old ::= find 289 command_select_old 290 ::= partial 292 date_year_old ::= 2digit 293 ;; (year - 1900) 295 date_time_old ::= <"> date_day_fixed "-" date_month "-" date_year 296 SPACE time "-" zone_name <"> 298 find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE 299 list_mailbox 301 fetch_att_old ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list / 302 fetch_text_old 304 fetch_text_old ::= "BODY" [".PEEK"] section_old / 305 "RFC822" [".HEADER" / ".TEXT" [".PEEK"]] 307 msg_data_old ::= "COPY" / ("STORE" SPACE msg_att) 309 partial ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE 310 number SPACE number 312 section_old ::= "[" (number ["." number]) "]" 314 subscribe_old ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox 316 unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox 317 zone_name ::= "UT" / "GMT" / "Z" / ;; +0000 318 "AST" / "EDT" / ;; -0400 319 "EST" / "CDT" / ;; -0500 320 "CST" / "MDT" / ;; -0600 321 "MST" / "PDT" / ;; -0700 322 "PST" / "YDT" / ;; -0800 323 "YST" / "HDT" / ;; -0900 324 "HST" / "BDT" / ;; -1000 325 "BST" / ;; -1100 326 "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6 327 "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12 328 "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6 329 "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12 331 Security Considerations 333 Security issues are not discussed in this memo. 335 Author's Address 337 Mark R. Crispin 338 Networks and Distributed Computing 339 University of Washington 340 4545 15th Aveneue NE 341 Seattle, WA 98105-4527 343 Phone: (206) 543-5762 345 EMail: MRC@CAC.Washington.EDU