idnits 2.17.1 draft-ietf-imap-status-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-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 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 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (January 1996) is 10328 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) Summary: 10 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 M. Crispin 3 Internet Draft: IMAP4 STATUS Extension University of Washington 4 Document: internet-drafts/draft-ietf-imap-status-02.txt January 1996 6 IMAP4 STATUS EXTENSION 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 This is a draft document of the IETF IMAP Working Group. A revised 27 version of this draft document will be submitted to the RFC editor as 28 an Proposed Standard for the Internet Community. Discussion and 29 suggestions for improvement are requested, and should be sent to 30 imap@CAC.Washington.EDU. This document will expire before 30 June 31 1996. Distribution of this memo is unlimited. 33 Introduction 35 The Internet Message Access Protocol, Version 4 [IMAP4] contains the 36 LIST and LSUB commands, for indentifying mailbox names on the server 37 and retrieving some basic status informaton. This document describes 38 a mechanism to obtain additional mailbox name status information. 40 Internet DRAFT IMAP4 - STATUS January 17, 1996 42 IMAP4 STATUS Extension 44 The STATUS extension is present in any IMAP4 implementation which 45 returns "STATUS" as one of the supported capabilities to the 46 CAPABILITY command. Servers which have this extension offer the 47 STATUS command and STATUS response, which enables the client to query 48 the server about the status of a mailbox without selecting the 49 mailbox. 51 The STATUS command provides an alternative to opening a second IMAP4 52 connection and doing an EXAMINE command on an mailbox to query that 53 mailbox's status without deselecting the current mailbox in the first 54 IMAP4 connection. 56 Unlike the LIST command, the STATUS command is not guaranteed to be 57 fast in its response. In some implementations, the server may have 58 to open the mailbox read-only internally to obtain certain status 59 information. Also unlike the LIST command, the STATUS command does 60 not accept wildcards. 62 6.3.STATUS. STATUS Command 64 Arguments: mailbox name 65 status data item names 67 Data: untagged responses: STATUS 69 Result: OK - status completed 70 NO - status failure: no status for that name 71 BAD - command unknown or arguments invalid 73 The STATUS command requests the status of the indicated mailbox. 74 It does not change the currently selected mailbox, nor does it 75 affect the state of any messages in the queried mailbox (in 76 particular, STATUS must not cause messages to lose the \Recent 77 flag). The currently defined status data items that can be 78 requested are: 80 MESSAGES The number of messages in the mailbox. 82 RECENT The number of messages with the \Recent flag set. 84 UID-NEXT The next UID that will is available for assignment 85 to the mailbox. 87 UID-VALIDITY The unique identifier validity value of the 89 Internet DRAFT IMAP4 - STATUS January 17, 1996 91 mailbox, as described in [IMAP4]. 93 UNSEEN The number of messages which do not have the \Seen 94 flag set. 96 Example: C: A042 STATUS blurdybloop (UID-NEXT MESSAGES) 97 S: * STATUS blurdybloop (MESSAGES 231 UID-NEXT 44292) 98 S: A042 OK STATUS completed 100 7.2.STATUS. STATUS Response 102 Data: name 103 status parenthesized list 105 The STATUS response occurs as a result of an STATUS command. It 106 returns the mailbox name that matches the STATUS specification and 107 the requested mailbox status information. 109 Example: S: * STATUS blurdybloop (MESSAGES 231 UID-NEXT 44292) 111 Internet DRAFT IMAP4 - STATUS January 17, 1996 113 9. Additional Formal Syntax 115 The following syntax is as described in [IMAP4], with one extension: 116 the token "+:=" means "added to the existing definition" as opposed 117 to "::=" which means "definition". 119 capability +:= "STATUS" 120 ;; Must be returned by server to use STATUS command 122 command_auth +:= status 124 mailbox_data +:= "STATUS" SPACE mailbox SPACE "(" #