1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc2971.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,451 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                        T. Showalter
    1.11 +Request for Comments: 2971                                Mirapoint, Inc.
    1.12 +Category: Standards Track                                    October 2000
    1.13 +
    1.14 +
    1.15 +                           IMAP4 ID extension
    1.16 +
    1.17 +Status of this Memo
    1.18 +
    1.19 +   This document specifies an Internet standards track protocol for the
    1.20 +   Internet community, and requests discussion and suggestions for
    1.21 +   improvements.  Please refer to the current edition of the "Internet
    1.22 +   Official Protocol Standards" (STD 1) for the standardization state
    1.23 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.24 +
    1.25 +Copyright Notice
    1.26 +
    1.27 +   Copyright (C) The Internet Society (2000).  All Rights Reserved.
    1.28 +
    1.29 +Abstract
    1.30 +
    1.31 +   The ID extension to the Internet Message Access Protocol - Version
    1.32 +   4rev1 (IMAP4rev1) protocol allows the server and client to exchange
    1.33 +   identification information on their implementation in order to make
    1.34 +   bug reports and usage statistics more complete.
    1.35 +
    1.36 +1. Introduction
    1.37 +
    1.38 +   The IMAP4rev1 protocol described in [IMAP4rev1] provides a method for
    1.39 +   accessing remote mail stores, but it provides no facility to
    1.40 +   advertise what program a client or server uses to provide service.
    1.41 +   This makes it difficult for implementors to get complete bug reports
    1.42 +   from users, as it is frequently difficult to know what client or
    1.43 +   server is in use.
    1.44 +
    1.45 +   Additionally, some sites may wish to assemble usage statistics based
    1.46 +   on what clients are used, but in an an environment where users are
    1.47 +   permitted to obtain and maintain their own clients this is difficult
    1.48 +   to accomplish.
    1.49 +
    1.50 +   The ID command provides a facility to advertise information on what
    1.51 +   programs are being used along with contact information (should bugs
    1.52 +   ever occur).
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Showalter                   Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 2971                   IMAP4 ID extension               October 2000
    1.64 +
    1.65 +
    1.66 +2. Conventions Used in this Document
    1.67 +
    1.68 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    1.69 +   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    1.70 +   document are to be interpreted as described in [KEYWORDS].
    1.71 +
    1.72 +   The conventions used in this document are the same as specified in
    1.73 +   [IMAP4rev1].  In examples, "C:" and "S:" indicate lines sent by the
    1.74 +   client and server respectively.  Line breaks have been inserted for
    1.75 +   readability.
    1.76 +
    1.77 +3. Specification
    1.78 +
    1.79 +   The sole purpose of the ID extension is to enable clients and servers
    1.80 +   to exchange information on their implementations for the purposes of
    1.81 +   statistical analysis and problem determination.
    1.82 +
    1.83 +   This information is be submitted to a server by any client wishing to
    1.84 +   provide information for statistical purposes, provided the server
    1.85 +   advertises its willingness to take the information with the atom "ID"
    1.86 +   included in the list of capabilities returned by the CAPABILITY
    1.87 +   command.
    1.88 +
    1.89 +   Implementations MUST NOT make operational changes based on the data
    1.90 +   sent as part of the ID command or response.  The ID command is for
    1.91 +   human consumption only, and is not to be used in improving the
    1.92 +   performance of clients or servers.
    1.93 +
    1.94 +   This includes, but is not limited to, the following:
    1.95 +
    1.96 +      Servers MUST NOT attempt to work around client bugs by using
    1.97 +      information from the ID command.  Clients MUST NOT attempt to work
    1.98 +      around server bugs based on the ID response.
    1.99 +
   1.100 +      Servers MUST NOT provide features to a client or otherwise
   1.101 +      optimize for a particular client by using information from the ID
   1.102 +      command.  Clients MUST NOT provide features to a server or
   1.103 +      otherwise optimize for a particular server based on the ID
   1.104 +      response.
   1.105 +
   1.106 +      Servers MUST NOT deny access to or refuse service for a client
   1.107 +      based on information from the ID command.  Clients MUST NOT refuse
   1.108 +      to operate or limit their operation with a server based on the ID
   1.109 +      response.
   1.110 +
   1.111 +
   1.112 +
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Showalter                   Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 2971                   IMAP4 ID extension               October 2000
   1.120 +
   1.121 +
   1.122 +   Rationale: It is imperative that this extension not supplant IMAP's
   1.123 +   CAPABILITY mechanism with a ad-hoc approach where implementations
   1.124 +   guess each other's features based on who they claim to be.
   1.125 +
   1.126 +   Implementations MUST NOT send false information in an ID command.
   1.127 +
   1.128 +   Implementations MAY send less information than they have available or
   1.129 +   no information at all.  Such behavior may be useful to preserve user
   1.130 +   privacy.  See Security Considerations, section 7.
   1.131 +
   1.132 +3.1. ID Command
   1.133 +
   1.134 +   Arguments:  client parameter list or NIL
   1.135 +
   1.136 +   Responses:  OPTIONAL untagged response: ID
   1.137 +
   1.138 +   Result:     OK    identification information accepted
   1.139 +               BAD   command unknown or arguments invalid
   1.140 +
   1.141 +   Implementation identification information is sent by the client with
   1.142 +   the ID command.
   1.143 +
   1.144 +   This command is valid in any state.
   1.145 +
   1.146 +   The information sent is in the form of a list of field/value pairs.
   1.147 +   Fields are permitted to be any IMAP4 string, and values are permitted
   1.148 +   to be any IMAP4 string or NIL.  A value of NIL indicates that the
   1.149 +   client can not or will not specify this information.  The client may
   1.150 +   also send NIL instead of the list, indicating that it wants to send
   1.151 +   no information, but would still accept a server response.
   1.152 +
   1.153 +   The available fields are defined in section 3.3.
   1.154 +
   1.155 +   Example:  C: a023 ID ("name" "sodr" "version" "19.34" "vendor"
   1.156 +                 "Pink Floyd Music Limited")
   1.157 +             S: * ID NIL
   1.158 +             S: a023 OK ID completed
   1.159 +
   1.160 +3.2. ID Response
   1.161 +
   1.162 +   Contents:   server parameter list
   1.163 +
   1.164 +   In response to an ID command issued by the client, the server replies
   1.165 +   with a tagged response containing information on its implementation.
   1.166 +   The format is the same as the client list.
   1.167 +
   1.168 +
   1.169 +
   1.170 +
   1.171 +
   1.172 +
   1.173 +Showalter                   Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 2971                   IMAP4 ID extension               October 2000
   1.176 +
   1.177 +
   1.178 +   Example:  C: a042 ID NIL
   1.179 +             S: * ID ("name" "Cyrus" "version" "1.5" "os" "sunos"
   1.180 +                  "os-version" "5.5" "support-url"
   1.181 +                  "mailto:cyrus-bugs+@andrew.cmu.edu")
   1.182 +             S: a042 OK ID command completed
   1.183 +
   1.184 +   A server MUST send a tagged ID response to an ID command.  However, a
   1.185 +   server MAY send NIL in place of the list.
   1.186 +
   1.187 +3.3. Defined Field Values
   1.188 +
   1.189 +   Any string may be sent as a field, but the following are defined to
   1.190 +   describe certain values that might be sent.  Implementations are free
   1.191 +   to send none, any, or all of these.  Strings are not case-sensitive.
   1.192 +   Field strings MUST NOT be longer than 30 octets.  Value strings MUST
   1.193 +   NOT be longer than 1024 octets.  Implementations MUST NOT send more
   1.194 +   than 30 field-value pairs.
   1.195 +
   1.196 +     name            Name of the program
   1.197 +     version         Version number of the program
   1.198 +     os              Name of the operating system
   1.199 +     os-version      Version of the operating system
   1.200 +     vendor          Vendor of the client/server
   1.201 +     support-url     URL to contact for support
   1.202 +     address         Postal address of contact/vendor
   1.203 +     date            Date program was released, specified as a date-time
   1.204 +                       in IMAP4rev1
   1.205 +     command         Command used to start the program
   1.206 +     arguments       Arguments supplied on the command line, if any
   1.207 +                       if any
   1.208 +     environment     Description of environment, i.e., UNIX environment
   1.209 +                       variables or Windows registry settings
   1.210 +
   1.211 +   Implementations MUST NOT use contact information to submit automatic
   1.212 +   bug reports.  Implementations may include information from an ID
   1.213 +   response in a report automatically prepared, but are prohibited from
   1.214 +   sending the report without user authorization.
   1.215 +
   1.216 +   It is preferable to find the name and version of the underlying
   1.217 +   operating system at runtime in cases where this is possible.
   1.218 +
   1.219 +   Information sent via an ID response may violate user privacy.  See
   1.220 +   Security Considerations, section 7.
   1.221 +
   1.222 +   Implementations MUST NOT send the same field name more than once.
   1.223 +
   1.224 +
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Showalter                   Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 2971                   IMAP4 ID extension               October 2000
   1.232 +
   1.233 +
   1.234 +4. Formal Syntax
   1.235 +
   1.236 +   This  syntax is intended to augment the grammar specified in
   1.237 +   [IMAP4rev1] in order to provide for the ID command.  This
   1.238 +   specification uses the augmented Backus-Naur Form (BNF) notation as
   1.239 +   used in [IMAP4rev1].
   1.240 +
   1.241 +     command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / id
   1.242 +         ;; adds id command to command_any in [IMAP4rev1]
   1.243 +
   1.244 +     id ::= "ID" SPACE id_params_list
   1.245 +
   1.246 +     id_response ::= "ID" SPACE id_params_list
   1.247 +
   1.248 +     id_params_list ::= "(" #(string SPACE nstring) ")" / nil
   1.249 +         ;; list of field value pairs
   1.250 +
   1.251 +     response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
   1.252 +         mailbox_data / message_data / capability_data / id_response)
   1.253 +
   1.254 +5. Use of the ID extension with Firewalls and Other Intermediaries
   1.255 +
   1.256 +   There exist proxies, firewalls, and other intermediary systems that
   1.257 +   can intercept an IMAP session and make changes to the data exchanged
   1.258 +   in the session.  Such intermediaries are not anticipated by the IMAP4
   1.259 +   protocol design and are not within the scope of the IMAP4 standard.
   1.260 +   However, in order for the ID command to be useful in the presence of
   1.261 +   such intermediaries, those intermediaries need to take special note
   1.262 +   of the ID command and response.  In particular, if an intermediary
   1.263 +   changes any part of the IMAP session it must also change the ID
   1.264 +   command to advertise its presence.
   1.265 +
   1.266 +   A firewall MAY act to block transmission of specific information
   1.267 +   fields in the ID command and response that it believes reveal
   1.268 +   information that could expose a security vulnerability.  However, a
   1.269 +   firewall SHOULD NOT disable the extension, when present, entirely,
   1.270 +   and SHOULD NOT unconditionally remove either the client or server
   1.271 +   list.
   1.272 +
   1.273 +   Finally, it should be noted that a firewall, when handling a
   1.274 +   CAPABILITY response, MUST NOT allow the names of extensions to be
   1.275 +   returned to the client that the firewall has no knowledge of.
   1.276 +
   1.277 +
   1.278 +
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Showalter                   Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 2971                   IMAP4 ID extension               October 2000
   1.288 +
   1.289 +
   1.290 +6. References
   1.291 +
   1.292 +   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
   1.293 +               Requirement Levels", RFC 2119, March 1997.
   1.294 +
   1.295 +   [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Version
   1.296 +               4rev1", RFC 2060, October 1996.
   1.297 +
   1.298 +   [RFC-822]   Crocker, D., "Standard for the Format of ARPA Internet
   1.299 +               Text Messages", STD 11, RFC 822, August 1982.
   1.300 +
   1.301 +7. Security Considerations
   1.302 +
   1.303 +   This extension has the danger of violating the privacy of users if
   1.304 +   misused.  Clients and servers should notify users that they implement
   1.305 +   and enable the ID command.
   1.306 +
   1.307 +   It is highly desirable that implementations provide a method of
   1.308 +   disabling ID support, perhaps by not sending ID at all, or by sending
   1.309 +   NIL as the argument to the ID command or response.
   1.310 +
   1.311 +   Implementors must exercise extreme care in adding fields sent as part
   1.312 +   of an ID command or response.  Some fields, including a processor ID
   1.313 +   number, Ethernet address, or other unique (or mostly unique)
   1.314 +   identifier allow tracking of users in ways that violate user privacy
   1.315 +   expectations.
   1.316 +
   1.317 +   Having implementation information of a given client or server may
   1.318 +   make it easier for an attacker to gain unauthorized access due to
   1.319 +   security holes.
   1.320 +
   1.321 +   Since this command includes arbitrary data and does not require the
   1.322 +   user to authenticate, server implementations are cautioned to guard
   1.323 +   against an attacker sending arbitrary garbage data in order to fill
   1.324 +   up the ID log.  In particular, if a server naively logs each ID
   1.325 +   command to disk without inspecting it, an attacker can simply fire up
   1.326 +   thousands of connections and send a few kilobytes of random data.
   1.327 +   Servers have to guard against this.  Methods include truncating
   1.328 +   abnormally large responses; collating responses by storing only a
   1.329 +   single copy, then keeping a counter of the number of times that
   1.330 +   response has been seen; keeping only particularly interesting parts
   1.331 +   of responses; and only logging responses of users who actually log
   1.332 +   in.
   1.333 +
   1.334 +   Security is affected by firewalls which modify the IMAP protocol
   1.335 +   stream; see section 5, Use of the ID Extension with Firewalls and
   1.336 +   Other Intermediaries, for more information.
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Showalter                   Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 2971                   IMAP4 ID extension               October 2000
   1.344 +
   1.345 +
   1.346 +8. Author's Address
   1.347 +
   1.348 +   Tim Showalter
   1.349 +   Mirapoint, Inc.
   1.350 +   909 Hermosa Ct.
   1.351 +   Sunnyvale, CA 94095
   1.352 +
   1.353 +   EMail: tjs@mirapoint.com
   1.354 +
   1.355 +
   1.356 +
   1.357 +
   1.358 +
   1.359 +
   1.360 +
   1.361 +
   1.362 +
   1.363 +
   1.364 +
   1.365 +
   1.366 +
   1.367 +
   1.368 +
   1.369 +
   1.370 +
   1.371 +
   1.372 +
   1.373 +
   1.374 +
   1.375 +
   1.376 +
   1.377 +
   1.378 +
   1.379 +
   1.380 +
   1.381 +
   1.382 +
   1.383 +
   1.384 +
   1.385 +
   1.386 +
   1.387 +
   1.388 +
   1.389 +
   1.390 +
   1.391 +
   1.392 +
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Showalter                   Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 2971                   IMAP4 ID extension               October 2000
   1.400 +
   1.401 +
   1.402 +9.  Full Copyright Statement
   1.403 +
   1.404 +   Copyright (C) The Internet Society (2000).  All Rights Reserved.
   1.405 +
   1.406 +   This document and translations of it may be copied and furnished to
   1.407 +   others, and derivative works that comment on or otherwise explain it
   1.408 +   or assist in its implementation may be prepared, copied, published
   1.409 +   and distributed, in whole or in part, without restriction of any
   1.410 +   kind, provided that the above copyright notice and this paragraph are
   1.411 +   included on all such copies and derivative works.  However, this
   1.412 +   document itself may not be modified in any way, such as by removing
   1.413 +   the copyright notice or references to the Internet Society or other
   1.414 +   Internet organizations, except as needed for the purpose of
   1.415 +   developing Internet standards in which case the procedures for
   1.416 +   copyrights defined in the Internet Standards process must be
   1.417 +   followed, or as required to translate it into languages other than
   1.418 +   English.
   1.419 +
   1.420 +   The limited permissions granted above are perpetual and will not be
   1.421 +   revoked by the Internet Society or its successors or assigns.
   1.422 +
   1.423 +   This document and the information contained herein is provided on an
   1.424 +   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   1.425 +   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   1.426 +   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   1.427 +   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   1.428 +   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.429 +
   1.430 +Acknowledgement
   1.431 +
   1.432 +   Funding for the RFC Editor function is currently provided by the
   1.433 +   Internet Society.
   1.434 +
   1.435 +
   1.436 +
   1.437 +
   1.438 +
   1.439 +
   1.440 +
   1.441 +
   1.442 +
   1.443 +
   1.444 +
   1.445 +
   1.446 +
   1.447 +
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Showalter                   Standards Track                     [Page 8]
   1.454 +