Lemonade Z. Oerdoegh, Ed. Internet-Draft Nokia Intended status: Standards Track November 8, 2007 Expires: May 11, 2008 CLIENTID extension to the IMAP Protocol draft-ordogh-lemonade-clientid-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on May 11, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes the CLIENTID extension to IMAP. IMAP CLIENTID allows an IMAP client to identify itself to the IMAP server, which allows the IMAP server to store data specific to an individual IMAP client. The solution includes two new mechanisms. One to request a new Client-ID, and another to disclose the Client-ID to the IMAP server, which in turn initializes the client environment. Oerdoegh Expires May 11, 2008 [Page 1] Internet-Draft CLIENTID November 2007 Conventions used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Formal syntax is defined using the Augmented Backus-Naur Form for Syntax Specification in RFC 4234 [2] as extended by IMAP in RFC 3501 [3] and IMAP extensions in RFC 4466 [4]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. "[...]" means elision. The reader will find several references to the usage of Client-IDs, like assigning it, taking it into use, initializing the client environment, etc. All of these expressions mean the same things, as discussed in Section 4. 1. Introduction This document is addressing a simple problem: there is no way of identifying individual clients in a reliable manner currently; while client identification is required to store client-specific data to the IMAP server. The original motivation to create this extension was to facilite the following features by providing a generic framework to obtain and use unique client identifiers: o Detect that a certain client is online; in order to stop sending out of band notifications for the online client. o Allow storing client-specific preferences. o Support for per-client SIEVE scripts. 2. Overview To make this perfectly clear at the beginning: the purpose of this document is not to describe how the Client-ID is used by the server or the client. The purpose of this document is to describe a command that can be used to aquire a unique Client-ID and how a Client-ID is taken into use. Describing a specific server or client behaviour when the Client-ID is taken into use - when the client environment is initialized - is the responsibility of those future specifications that build funcionality using Client-IDs. The root of our problems is rather simple: currently - at the time of writing this document - IMAP does not provide that means of identifying individual clients in a reliable manner. A simple problem calls for a simple solution: let's have the server generate a Oerdoegh Expires May 11, 2008 [Page 2] Internet-Draft CLIENTID November 2007 unique Client-ID whenever needed, give the generated Client-ID to the client, and finally let the client initialize its environment by disclosing its Client-ID when needed. What do we need to specify all this? First, we describe the syntax (Section 3) of the Client-ID, then, we describe the usage (Section 4) of the Client-ID, and finally, we describe the command (Section 5) that can help us achive this all. An IMAP server that supports the capability described in this document MUST return "X-DRAFT-CLIENTID-00" as one of the supported capabilities in the CAPABILITY command. Comments regarding this draft can be sent either to the lemonade@ietf.org mailing list, or to the authors. 3. The Client-ID syntax The Client-ID is a quoted string (containing any characters except the quote character itself): Client-ID = quoted ; quoted defined in RFC 3501 4. Using the Client-ID A Client-ID can be taken into use using the ClientID command (Section 5) either when it is generated, or when the client discloses it to the server, as REQUIRED by the ClientID command (Section 5). This document does not describe what taking into use means in terms of server or client action. Describing the server and client actions and imposing the related requirements is the role of the extensions that built functionality using the Client-ID. This document imposes generic requirements though that guarantee interoperable operation of the extensions utilizing Client-IDs: o A newly generated Client-ID MUST be unique within the scope of the mail server, and it SHOULD be unique within the scope of the mail service. o A client that has been issued a Client-ID MUST store the Client-ID presistently, and it SHOULD use the stored Client-ID consistenly with the mail server it connects to. Persistent storage means that the new Client-ID MUST NOT be lost when the client crashes, a power failure, or other disruptive event occurs. Consistent usage means that once the client has requested a new Client-ID and it has stored any client-specific data, it MUST use its own Client-ID during every established session. Oerdoegh Expires May 11, 2008 [Page 3] Internet-Draft CLIENTID November 2007 o The server MAY implement garbage collection and remove allocated Client-IDs along with any associated client preferences from time to time, however it MUST NOT remove the Client-ID or any associated data as long as the last seen time for a Client-ID is less than 6 months. o In order to guarantee initializing all client-specific data as early as possible, a new Client-ID SHOULD be requested or the known Client-ID SHOULD be declared using the CLIENTID command immediately after the IMAP CAPABLITY command. 5. The CLIENTID command The CLIENTID command instructs the server either to generate a new Client-ID, or assign an exising Client-ID to the current session. Arguments: NONE Client-ID Responses: NONE untagged Client-ID Results: OK - The server has successfully generated a new Client-ID or assigned one that has been received as a parameter. NO - A Client-ID is already assigned to the session. BAD - There was an error in processing some client-specific data. In order to generate a new Client-ID, the CLIENTID command MUST be issued without any arguments. When the server receives a CLIENTID command without argument, it MUST generate a unique Client-ID, return the generated Client-ID in an untagged response, initialize the client environment using the newly generated Client-ID, and finally return the OK result. The server MUST NOT send any other untagged responses before the result.Example: C: a CLIENTID S: * "0Lame1Client2ID3" S: a OK In order to assign an existing Client-ID to a session, the client MUST issue the CLIENTID command with the Client-ID parameter. When the server receives a CLIENTID command with the Client-ID argument and no error occurs, the server MUST initialize the client environment using the newly generated Client-ID and return the OK result. If an error occurs, server MUST NOT take any other action than send backThe server MAY send other untagged responses before the result. Example: Oerdoegh Expires May 11, 2008 [Page 4] Internet-Draft CLIENTID November 2007 C: a CLIENTID "0Lame1Client2ID3" S: a OK 6. Security Considerations The CLIENTID extension does not raise any security considerations which are not present in the base protocol. Considerations are the same as for IMAP [3]. 7. IANA Considerations Per the IMAP RFC [3], registration of a new IMAP capablity in the IMAP Capability registry requires the publication of a standards track RFC or an IESG approved experimental RFC. The registry is currently located at . This standards track document defines the CLIENTID IMAP capability. We request IANA to add this extension to the IANA IMAP Capability registry. 8. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [3] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. [4] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006. Oerdoegh Expires May 11, 2008 [Page 5] Internet-Draft CLIENTID November 2007 Author's Address Zoltan Oerdoegh (editor) Nokia Visiokatu 6. Tampere, 33720 Finland Phone: Fax: Email: zoltan.ordogh@nokia.com URI: http://www.nokia.com Oerdoegh Expires May 11, 2008 [Page 6] Internet-Draft CLIENTID November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Oerdoegh Expires May 11, 2008 [Page 7]