Internet Draft: Transitional IMAP capabilities A. Melnikov Document: draft-melnikov-imap-transitional-capa-00.txt Isode Ltd. Expires: January 2005 July 2004 Intended category: Informational Transitional IMAP capabilities Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to the IMAPEXT Mailing list <ietf-imapext@imc.org>. Distribution of this draft is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Software releases can't always wait for some document to become an RFC. As the result some software products are released when they implement a non-final version of an IMAP [IMAP4] extension. This may cause substantial interoperability problems between clients and servers that implement different revisions of the same document, as syntax and semantics of operations may change substantially between revisions of the same IMAP extension draft. There is also a need to have transitional IMAP capabilities for Melnikov Expires: January 2005 [Page 1]
INTERNET DRAFT Transitional IMAP capabilities July 2004 testing purposes. This document defines a convention for IMAP capability strings that allows to reference an IMAP extension as defined by a particular revision of a draft. 1. Conventions Used in this Document 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. Transitional IMAP capabilities This document reserves a prefix for referencing an IMAP extension as defined by a draft revision. A draft defines a base capability name <EXTENSION>, which will be used when (and if) the document is approved as an RFC. For a draft revision <nn> and a ownership <o> (one of "I" - individual submission or "W" - a WG document) an implementation of the draft that also conforms to this document should advertise a capability "X-DRAFT-<o><nn>-<EXTENSION>". For example, if <EXTENSION> is URLAUTH and the draft revision number is 09 and it is an individual submission, the advertised capability string would be "X-DRAFT-I09-URLAUTH". Note that the defined convention MUST NOT be used with SASL capabilities. One of the advantages of the proposed convention is that an IMAP client can support multiple revisions of the same draft by checking "X-DRAFT-" prefix and then checking the suffix (e.g. "URLAUTH"). <o> field in a transitional capability string helps to cope with a situation when a draft is initially submitted as a individual submission, which is later on accepted as a WG document. Without this field the revision number will go back to "00" when the draft is resubmitted as a WG document. 3. Security Considerations One of the purposes of this document is to be able to distinguish two implementations that comply with different versions of the same IMAP extension. This might help to improve interoperability, and, Melnikov Expires: January 2005 [Page 2]
INTERNET DRAFT Transitional IMAP capabilities July 2004 hopefully, security. 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. capability =/ transit_capa ; transit_capa falls under "X" prefix transit_capa = "X-DRAFT-" ownership revision "-" atom ; MUST NOT be used with SASL capabilities ; starting with "AUTH=" ownership = "I" / "W" ; "I" means that the draft is an individual ; submission; "W" means a WG document revision = 2DIGIT ; 2 digit draft revision number 5. Acknowledgments <<TBD>> 6. Normative references [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [ABNF] Crocker, D., and Overell, P. "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, March 2003. Melnikov Expires: January 2005 [Page 3]
INTERNET DRAFT Transitional IMAP capabilities July 2004 7. Author's Addresses Alexey Melnikov Isode Ltd. 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, United Kingdom Email: Alexey.Melnikov@isode.com 8. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. 9. 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 Melnikov Expires: January 2005 [Page 4]
INTERNET DRAFT Transitional IMAP capabilities July 2004 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. Melnikov Expires: January 2005 [Page 5]