diff options
Diffstat (limited to 'imap/docs/rfc/rfc3691.txt')
| -rw-r--r-- | imap/docs/rfc/rfc3691.txt | 283 |
1 files changed, 0 insertions, 283 deletions
diff --git a/imap/docs/rfc/rfc3691.txt b/imap/docs/rfc/rfc3691.txt deleted file mode 100644 index 2f4e9b44..00000000 --- a/imap/docs/rfc/rfc3691.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -Network Working Group A. Melnikov -Request for Comments: 3691 Isode Ltd. -Category: Standards Track February 2004 - - - Internet Message Access Protocol (IMAP) UNSELECT command - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document defines an UNSELECT command that can be used to close - the current mailbox in an Internet Message Access Protocol - version - 4 (IMAP4) session without expunging it. Certain types of IMAP - clients need to release resources associated with the selected - mailbox without selecting a different mailbox. While IMAP4 provides - this functionality (via a SELECT command with a nonexistent mailbox - name or reselecting the same mailbox with EXAMINE command), a more - clean solution is desirable. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. UNSELECT command . . . . . . . . . . . . . . . . . . . . . . . 2 - 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 3 - 4. Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 3 - 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 3 - 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 3 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4 - 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 - 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 5 - - - - - - - - - - -Melnikov Standards Track [Page 1] - -RFC 3691 IMAP UNSELECT command February 2004 - - -1. Introduction - - Certain types of IMAP clients need to release resources associated - with the selected mailbox without selecting a different mailbox. - While [IMAP4] provides this functionality (via a SELECT command with - a nonexistent mailbox name or reselecting the same mailbox with - EXAMINE command), a more clean solution is desirable. - - [IMAP4] defines the CLOSE command that closes the selected mailbox as - well as permanently removes all messages with the \Deleted flag set. - - However [IMAP4] lacks a command that simply closes the mailbox - without expunging it. This document defines the UNSELECT command for - this purpose. - - A server which supports this extension indicates this with a - capability name of "UNSELECT". - - "C:" and "S:" in examples show lines sent by the client and server - respectively. - - The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in - this document when typed in uppercase are to be interpreted as - defined in "Key words for use in RFCs to Indicate Requirement Levels" - [KEYWORDS]. - -2. UNSELECT Command - - Arguments: none - - Responses: no specific responses for this command - - Result: OK - unselect completed, now in authenticated state - BAD - no mailbox selected, or argument supplied but - none permitted - - The UNSELECT command frees server's resources associated with the - selected mailbox and returns the server to the authenticated - state. This command performs the same actions as CLOSE, except - that no messages are permanently removed from the currently - selected mailbox. - - Example: C: A341 UNSELECT - S: A341 OK Unselect completed - - - - - - - -Melnikov Standards Track [Page 2] - -RFC 3691 IMAP UNSELECT command February 2004 - - -3. Security Considerations - - It is believed that this extension doesn't raise any additional - security concerns not already discussed in [IMAP4]. - -4. Formal Syntax - - The following syntax specification uses the Augmented Backus-Naur - Form (ABNF) notation as specified in [ABNF]. Non-terminals - referenced but not defined below are as defined by [IMAP4]. - - Except as noted otherwise, all alphabetic characters are case- - insensitive. The use of upper or lower case characters to define - token strings is for editorial clarity only. Implementations MUST - accept these strings in a case-insensitive fashion. - - command-select /= "UNSELECT" - -5. IANA Considerations - - IMAP4 capabilities are registered by publishing a standards track or - IESG approved experimental RFC. The registry is currently located - at: - - http://www.iana.org/assignments/imap4-capabilities - - This document defines the UNSELECT IMAP capabilities. IANA has added - this capability to the registry. - -6. Acknowledgments - - UNSELECT command was originally implemented by Tim Showalter in Cyrus - IMAP server. - - Also, the author of the document would like to thank Vladimir Butenko - and Mark Crispin for reminding that UNSELECT has to be documented. - Also thanks to Simon Josefsson for pointing out that there are - multiple ways to implement UNSELECT. - - - - - - - - - - - - - -Melnikov Standards Track [Page 3] - -RFC 3691 IMAP UNSELECT command February 2004 - - -7. Normative References - - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [IMAP4] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 3501, March 2003. - - [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - -8. Author's Address - - Alexey Melnikov - Isode Limited - 5 Castle Business Village - Hampton, Middlesex TW12 2BX - - EMail: Alexey.Melnikov@isode.com - URI: http://www.melnikov.ca/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Melnikov Standards Track [Page 4] - -RFC 3691 IMAP UNSELECT command February 2004 - - -9. Full Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78 and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE - INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed - to pertain to the implementation or use of the technology - described in this document or the extent to which any license - under such rights might or might not be available; nor does it - represent that it has made any independent effort to identify any - such rights. Information on the procedures with respect to - rights in RFC documents can be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention - any copyrights, patents or patent applications, or other - proprietary rights that may cover technology that may be required - to implement this standard. Please address the information to the - IETF at ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - -Melnikov Standards Track [Page 5] - |