Network Working Group T. Showalter Internet Draft: IMAP ID Extension Mirapoint, Inc. Document: draft-showalter-imap-id-02.txt July 19, 1999 IMAP4 ID extension Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 Abstract The ID extension to the IMAP4rev1 protocol allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. 1. Introduction The IMAP4rev1 protocol described in [IMAP4rev1] provides a method for accessing remote mail stores, but it provides no facility to advertise what program a client or server uses to provide service. This makes it difficult for implementors to get complete bug reports from users, as it is frequently difficult to know what client or server is in use. Additionally, some sites may wish to assemble usage statistics based on what clients are used, but in an an environment where users are permitted to obtain and maintain their own clients this is difficult to accomplish. The ID command provides a facility to advertise information on what Showalter Expire in Six Months [Page 1]
Internet DRAFT IMAP ID July 19, 1999 programs are being used along with contact information (should bugs ever occur). 2. Conventions Used in this Document The conventions used in this document are the same as specified in [IMAP4rev1]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Line breaks have been inserted for readability. 3. Specification The ID extension is provided in order for clients and servers to exchange information on their implementations. This information may be submitted to a server by any client wishing to provide information for statistical purposes, provided the server advertises its willingness to take the information with the atom "ID" included in the list of capabilities returned by the CAPABILITY command. Implementations MUST NOT make operational changes based on the data sent as part of the ID command or response. The ID command is for human consumption only, and is not to be used in improving the performance of clients or servers. This includes, but is not limited to, the following: A server MUST NOT attempt to work around a client's bugs after using the ID response to find out what client is on the other end. Clients MUST NOT attempt to work around server bugs based on the ID response. Clients MUST NOT optimize for particular servers based on an ID response. Servers MUST NOT do the same for clients. Clients and servers MUST NOT deny access based on an ID response. For instance, servers may not refuse service to a particular vendor's client. Rationale: It is imperative that this extension not supplant IMAP's CAPABILITY mechanism with a ad-hoc approach where implementations guess each other's features based on who they claim to be. Implementations SHOULD NOT send false information in an ID command. There may be cases where this is desirable, however, if implementations violate rules given above. Showalter Expire in Six Months [Page 2]
Internet DRAFT IMAP ID July 19, 1999 Implementations MAY send less information than they have avalible or no information at all. Such behavior may be useful to preserve user privacy. See Security Considerations, section 6. 3.1. ID Command Arguments: client parameter list or NIL Responses: OPTIONAL untagged response: ID Result: OK identification information accepted BAD command unknown or arguments invalid Implementation identification information is sent by the client with the ID command. This command is valid in any state. The information sent is in the form of a list of field/value pairs. Fields are permitted to be any IMAP4 string, and values are permitted to be any IMAP4 string or NIL. A value of NIL indicates that the client can not or will not specify this information. The client may also send NIL instead of the list, indicating that it wants to send no information, but would still accept a server response. The available fields are defined in section 3.3. Example: C: a023 ID ("name" "sodr" "version" "19.34" "vendor" "Pink Floyd Music Limited") S: a023 OK ID completed 3.2. ID Response Contents: server parameter list In response to an ID command issued by the client, the server MAY reply with a tagged response containing information on its implementation. The format is the same as the client list. Example: C: a023 ID NIL S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos" "os-version" "5.5" "email" "cyrus-bugs+@andrew.cmu.edu") S: a023 OK ID command completed A server MUST send a tagged ID response to an ID command. However, a server may send NIL in place of the list. Showalter Expire in Six Months [Page 3]
Internet DRAFT IMAP ID July 19, 1999 3.3. Defined Field Values Any string may be sent as a field, but the following are defined to describe certain values that might be sent. Implementations are free to send none, any, or all of these. Strings are not case-sensitive. Field strings MUST NOT be longer than 30 octets. Value strings MUST NOT be longer than 1024 octets. No more than 30 pieces of data may be sent. name Name of the program version Version number of the program os Name of the operating system os-version Version of the operating system vendor Vendor of the client/server support-url URL to contact for support address Postal address of contact/vendor date Date program was released; should be in a human-readable form command Command used to start the program arguments Arguments supplied on the command line, if any environment Description of environment, i.e., UNIX environment variables or Window registry settings Implementations MUST NOT use contact information to submit automatic bug reports. Implementations may, however, include information from an ID response in a report submitted. It is preferable to find the name and version of the underlying operating system at runtime in cases where this is possible. Information sent via an ID response may violate user privacy. See Security Considerations, section 6. Implementations MUST NOT send the same field name more than once. Showalter Expire in Six Months [Page 4]
Internet DRAFT IMAP ID July 19, 1999 4. Formal Syntax This syntax is intended to augment the grammar specified in [IMAP4rev1] in order to provide for the ID command. This specification uses the augmented Backus-Naur Form (BNF) notation as used in [IMAP4rev1]. command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id ;; adds id command to command_any in [IMAP4rev1] id ::= "ID" SPACE id_params_list id_response ::= "ID" SPACE id_params_list id_params_list ::= "(" #(string SPACE nstring) ")" / nil ;; list of field value pairs response_data ::= "*" (resp_cond_state / resp_cond_bye / mailbox_data / message_data / capability_data / id_response) 5. References [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, October, 1996. [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822. 6. Security Considerations This extension has the danger of violating the privacy of users if misused. Clients and servers should notify users that they implement and enable the ID command. It is highly desirable that implementations provide a method of disabling ID support, perhaps by not sending ID at all, or by sending NIL as the argument to the ID command or response. Implementors must exercise extreme care in adding fields sent as part of an ID command or response. Some fields, including a processor ID number, Ethernet address, or other unique (or mostly unique) identifier allow tracing of more than just user. Having implementation information of a given client or server may make it easier for an attacker to gain unauthorized access due to security holes. Showalter Expire in Six Months [Page 5]
Internet DRAFT IMAP ID July 19, 1999 7. Author's Address Tim Showalter Mirapoint, Inc. Two Results Way, Suite 100 Cupertino, CA 95014 8. Full Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Showalter Expire in Six Months [Page 6]