--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/rfc/rfc2971.txt	Mon Sep 14 15:17:45 2009 +0900
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        T. Showalter
+Request for Comments: 2971                                Mirapoint, Inc.
+Category: Standards Track                                    October 2000
+
+
+                           IMAP4 ID extension
+
+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 (2000).  All Rights Reserved.
+
+Abstract
+
+   The ID extension to the Internet Message Access Protocol - Version
+   4rev1 (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
+   programs are being used along with contact information (should bugs
+   ever occur).
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 1]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+2. 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 [KEYWORDS].
+
+   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 sole purpose of the ID extension is to enable clients and servers
+   to exchange information on their implementations for the purposes of
+   statistical analysis and problem determination.
+
+   This information is 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:
+
+      Servers MUST NOT attempt to work around client bugs by using
+      information from the ID command.  Clients MUST NOT attempt to work
+      around server bugs based on the ID response.
+
+      Servers MUST NOT provide features to a client or otherwise
+      optimize for a particular client by using information from the ID
+      command.  Clients MUST NOT provide features to a server or
+      otherwise optimize for a particular server based on the ID
+      response.
+
+      Servers MUST NOT deny access to or refuse service for a client
+      based on information from the ID command.  Clients MUST NOT refuse
+      to operate or limit their operation with a server based on the ID
+      response.
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 2]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+   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 MUST NOT send false information in an ID command.
+
+   Implementations MAY send less information than they have available or
+   no information at all.  Such behavior may be useful to preserve user
+   privacy.  See Security Considerations, section 7.
+
+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: * ID NIL
+             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 replies
+   with a tagged response containing information on its implementation.
+   The format is the same as the client list.
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 3]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+   Example:  C: a042 ID NIL
+             S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos"
+                  "os-version" "5.5" "support-url"
+                  "mailto:cyrus-bugs+@andrew.cmu.edu")
+             S: a042 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.
+
+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.  Implementations MUST NOT send more
+   than 30 field-value pairs.
+
+     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, specified as a date-time
+                       in IMAP4rev1
+     command         Command used to start the program
+     arguments       Arguments supplied on the command line, if any
+                       if any
+     environment     Description of environment, i.e., UNIX environment
+                       variables or Windows registry settings
+
+   Implementations MUST NOT use contact information to submit automatic
+   bug reports.  Implementations may include information from an ID
+   response in a report automatically prepared, but are prohibited from
+   sending the report without user authorization.
+
+   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 7.
+
+   Implementations MUST NOT send the same field name more than once.
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 4]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+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 ::= "*" SPACE (resp_cond_state / resp_cond_bye /
+         mailbox_data / message_data / capability_data / id_response)
+
+5. Use of the ID extension with Firewalls and Other Intermediaries
+
+   There exist proxies, firewalls, and other intermediary systems that
+   can intercept an IMAP session and make changes to the data exchanged
+   in the session.  Such intermediaries are not anticipated by the IMAP4
+   protocol design and are not within the scope of the IMAP4 standard.
+   However, in order for the ID command to be useful in the presence of
+   such intermediaries, those intermediaries need to take special note
+   of the ID command and response.  In particular, if an intermediary
+   changes any part of the IMAP session it must also change the ID
+   command to advertise its presence.
+
+   A firewall MAY act to block transmission of specific information
+   fields in the ID command and response that it believes reveal
+   information that could expose a security vulnerability.  However, a
+   firewall SHOULD NOT disable the extension, when present, entirely,
+   and SHOULD NOT unconditionally remove either the client or server
+   list.
+
+   Finally, it should be noted that a firewall, when handling a
+   CAPABILITY response, MUST NOT allow the names of extensions to be
+   returned to the client that the firewall has no knowledge of.
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 5]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+6. References
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", RFC 2119, March 1997.
+
+   [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
+               4rev1", RFC 2060, October 1996.
+
+   [RFC-822]   Crocker, D., "Standard for the Format of ARPA Internet
+               Text Messages", STD 11, RFC 822, August 1982.
+
+7. 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 tracking of users in ways that violate user privacy
+   expectations.
+
+   Having implementation information of a given client or server may
+   make it easier for an attacker to gain unauthorized access due to
+   security holes.
+
+   Since this command includes arbitrary data and does not require the
+   user to authenticate, server implementations are cautioned to guard
+   against an attacker sending arbitrary garbage data in order to fill
+   up the ID log.  In particular, if a server naively logs each ID
+   command to disk without inspecting it, an attacker can simply fire up
+   thousands of connections and send a few kilobytes of random data.
+   Servers have to guard against this.  Methods include truncating
+   abnormally large responses; collating responses by storing only a
+   single copy, then keeping a counter of the number of times that
+   response has been seen; keeping only particularly interesting parts
+   of responses; and only logging responses of users who actually log
+   in.
+
+   Security is affected by firewalls which modify the IMAP protocol
+   stream; see section 5, Use of the ID Extension with Firewalls and
+   Other Intermediaries, for more information.
+
+
+
+
+Showalter                   Standards Track                     [Page 6]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+8. Author's Address
+
+   Tim Showalter
+   Mirapoint, Inc.
+   909 Hermosa Ct.
+   Sunnyvale, CA 94095
+
+   EMail: tjs@mirapoint.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 7]
+
+RFC 2971                   IMAP4 ID extension               October 2000
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Showalter                   Standards Track                     [Page 8]
+