IMAP4 ID extension
RFC 2971

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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