From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3691.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc3691.txt (limited to 'doc/rfc/rfc3691.txt') diff --git a/doc/rfc/rfc3691.txt b/doc/rfc/rfc3691.txt new file mode 100644 index 0000000..2f4e9b4 --- /dev/null +++ b/doc/rfc/rfc3691.txt @@ -0,0 +1,283 @@ + + + + + + +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] + -- cgit v1.2.3