SIMPLE                                                         E. Burger
Internet-Draft                                         BEA Systems, Inc.
Expires: August 9, 2007
Intended status: Standards Track                            H. Khartabil
                                                        February 5,
Expires: November 16, 2007                                  May 15, 2007

                Instant Message Disposition Notification
                       draft-ietf-simple-imdn-03
                       draft-ietf-simple-imdn-04

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 August 9, November 16, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Instant Messaging (IM) refers to the transfer of messages between
   users in real-time.  This document provides a mechanism whereby
   endpoints can request Instant Message Disposition Notifications
   (IMDN), including delivery, processing and read notifications, for
   page-mode instant messages.

   The Common Profile for Instant Messaging (CPIM) data format specified
   in RFC 3862 is extended with new header fields that enable endpoints
   to request IMDNs.  A new message format is also defined to convey
   IMDNs.

   This document also describes how SIP entities behave using this
   extension.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Disposition Types  . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Delivery . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Processing . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.3.  Read . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  New CPIM header fields Header Fields . . . . . . . . . . . . . . . . . . . .  7
     6.1.  CPIM header field Header Field Namespace  . . . . . . . . . . . . . . .  8
     6.2.  Disposition-Notification . . . . . . . . . . . . . . . . .  8
     6.3.  Message-ID . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.4.  Original-To  . . . . . . . . . . . . . . . . . . . . . . .  8
     6.5.  IMDN-Record-Route  . . . . . . . . . . . . . . . . . . . .  8
     6.6.  IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  IM Sender  . . . . . . . . . . . . . . . . . . . . . . . .  9
       7.1.1.  Constructing Instant Messages  . . . . . . . . . . . .  9
       7.1.2.  Matching IMs with IMDNs  . . . . . . . . . . . . . . . 10
       7.1.3.  Keeping State  . . . . . . . . . . . . . . . . . . . . 11
       7.1.4.  Aggregation of IMDNs . . . . . . . . . . . . . . . . . 11
     7.2.  IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12
       7.2.1.  Constructing IMDNs . . . . . . . . . . . . . . . . . . 12
   8.  Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Constructing Processing Notifications  . . . . . . . . . . 15
     8.2.  Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 16
   9.  Identifying Messages . . . . . . . . . . . . . . . . . . . . . 17 19
   10. header fields Header Fields Formal Syntax  . . . . . . . . . . . . . . . . . 17 19
   11. IMDN Format  . . . . . . . . . . . . . . . . . . . . . . . . . 18 20
     11.1. Structure of XML-Encoded IMDN Payload  . . . . . . . . . . 18 20
       11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 19 20
       11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 19 20
       11.1.3. The <recipient-uri> Element  . . . . . . . . . . . . . 19 20
       11.1.4. The <original-recipient-uri> Element . . . . . . . . . 19 21
       11.1.5. The <subject> Element  . . . . . . . . . . . . . . . . 19 21
       11.1.6. The <disposition> Element  . . . . . . . . . . . . . . 19 21
       11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 19 21
       11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 20 21
     11.2. MIME Type for IMDN Paylaod Payload . . . . . . . . . . . . . . . . 20 21
     11.3. The RelaxNG Schema . . . . . . . . . . . . . . . . . . . . 20 21
   12. Transporting Messages using SIP  . . . . . . . . . . . . . . . 24 25
     12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 24 25
       12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 24 25
       12.1.2. Sending Responses  . . . . . . . . . . . . . . . . . . 24 26
       12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 24 26
     12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 25 27
   13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 26 28
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 27 28
     14.1. Forgery  . . . . . . . . . . . . . . . . . . . . . . . . . 29 30
     14.2. Confidentiality  . . . . . . . . . . . . . . . . . . . . . 29 31
     14.3. Non-Repudiation  . . . . . . . . . . . . . . . . . . . . . 30 31
   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30 31
     15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 30 32
     15.2. URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:imdn  . . . . . . . . . . . . . . . 31 32
     15.3. Schema Registration  . . . . . . . . . . . . . . . . . . . 31 33
     15.4. Message/CPIM header field registration Registration for urn:ietf:params:imdn  . . . . . . . . . . 31 33
     15.5. Message/CPIM Header Field Registration . . . . . . . . . . 33
     15.6. Content-Disposition: notification  . . . . . . . . . . . . 32 34
   16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 34
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 34
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 32 34
     17.2. Informative References . . . . . . . . . . . . . . . . . . 32 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 35
   Intellectual Property and Copyright Statements . . . . . . . . . . 34 37

1.  Introduction

   In many user-to-user message exchange systems, message senders often
   wish to know if the human recipient actually received or read a
   message.

   Electronic Mail [10] deals with this situation with Message Delivery
   Notifications [11].  After the recipient views the message, her mail
   user agent generates a Message Delivery Notification, or MDN.  The
   MDN is an e-mail that follows the format prescribed by RFC2298 RFC3798 [11].
   The fixed format ensures that an automaton can process the message.

   Message/CPIM [2] is a message format used to generate instant
   messages.  SIP [8] can carry instant messages generated using
   message/CPIM in SIP MESSAGE requests [9].

   This document extends Message/CPIM message format (much like Message
   Delivery Notifications [11] extends Electronic Mail [10]) Mail) to enable Instant
   Message Senders to request, create and send Instant Message
   Disposition Notifications (IMDN) (IMDN).  This mechanism works for a page-mode page-
   mode as well as session mode instant messages.  This document only
   discusses page-mode.  Session mode is left as future standardisation
   efforts.

   IMDNs include positive delivery, negative delivery (i.e. a message
   did not get delivered successfully), read notifications as well as
   processed notifications.  By using CPIM header fields, the IMDN
   request and delivery are abstracted outside the transport protocol
   allowing interoperability between different IM systems.  Likewise, the mechanism does not rely on session-mode
   versus page-mode.

2.  Conventions

   In this document, the

   The key words 'MUST', 'MUST NOT', 'REQUIRED',
   'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 'OPTIONAL' "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant implementations. RFC-2119 [1].

3.  Terminology

   o  IM: An Instant Message generated using the Message/CPIM format.

   o  IMDN: An Instant Message Disposition Notification generated using
      the Message/CPIM format that carries a IMDN XML document.

   o  Message: an IM or an IMDN generated using the Message/CPIM format.

   o  IM Sender: An endpoint (User Agent) generating and sending an IM.
      It is also the endpoint that requests IMDNs for an IM.  Quite
      often, the IM Sender is the IMDN Recipient, but that is not always
      true since an IM Sender's Address of Record (AoR) placed in the IM
      and in turn used in the IMDN may in fact resolve to different User
      Agents.  This is a limitation due to an artifact of the nature of page-mode IMs.

   o  IM Recipient: An endpoint (User Agent) that receives IMs.  It is
      also the endpoint that generates and sends IMDNs to IMs, if
      requested by the IM Sender.

   o  Endpoint: An IM Sender or an IM Recipient.

   o  Intermediary: An entity in the network that is on the path of an
      IM to its final destination.

   o  IMDN Payload: An XML document carrying the disposition
      notification information.  In this specification, it is of MIME
      type "message/imdn+xml".

   o  Disposition type: the type of IMDN that can be requested.  This
      specification defines three, namely "delivery", "processing" and
      "read" disposition types.

   o  Transport Protocol Message: A SIP or other protocol message that
      contains an IM or IMDN.

4.  Overview

   The basic protocol flow is depicted in the diagram below.  An IM
   Sender creates an IM, adds IMDN request information the IM Sender is
   interested in receiving, then sends IM.  At a certain point in time,
   the IM Recipient or an intermediary determines that the user or
   application has received, did not receive, read, or otherwise
   disposed the IM.  The mechanism by which an IM Recipient determines
   its user has read an IM is beyond the scope of this document.  At
   that point, the IM Recipient or intermediary automatically generates
   a notification message to the IM Sender.  This notification message
   is the Instant Message Disposition Notification (IMDN).

   +--------------+                        +--------------+
   |  IM Sender   |                        | IM Recipient |
   |IMDN Recipient|                        | IMDN Sender  |
   +--------------+                        +--------------+
           |                                       |
           |                                       |
           |         1. IM requesting IMDN         |
           |-------------------------------------->|
           |                                       |
           |                                       |
           |         2. IMDN (disposition)         |
           |<--------------------------------------|
           |                                       |
           |                                       |

   Note that the recipient of an IMDN, in some instances, may not be the
   IM Sender.  This is specifically true for page-mode IMs where the
   Address of Record (AOR) of the IM Sender, that is present in the
   IMDN, resolves to a different location or user agent to where the IM
   originated.  For simplicity, the rest of this document assumes that
   the IM Sender and the IMDN Recipient are the same and therefore will
   refer to both as the IM Sender.

5.  Disposition Types

   There are three broad categories of disposition states.  They are
   delivery, processing and read.  Future extensions may introduce
   others.

5.1.  Delivery

   The delivery notification type indicates whether the IM has been
   delivered to the IM Recipient or not.  The delivery notification type
   can have the following states:

   o  "delivered" to indicate successful delivery.

   o  "failed" to indicate failure in delivery.

   o  "forbidden" indicate denial for the IM Sender to receive the
      requested IMDN.  The "forbidden" state can be sent by the IM
      Recipient but is mainly sent by an intermediary that is configured
      to do so.  For example, the administrator has disallowed IMDNs.

   o  "error" to indicate an error in determining the fate of an IM.

5.2.  Processing

   The processing notification type indicates that an IM has been
   processed by an intermediary.  The processing notification type can
   have the following states:

   o  "processed" is a general state of the IM indicating that the
      intermediary has performed its task on the IM.

   o  "stored" state indicates that the IM has been stored by the
      intermediary for later delivery.

   o  "forbidden" indicate denial for the IM Sender to receive the
      requested IMDN.  The "forbidden" state is sent by an intermediary
      that is configured to do so.  For example, the administrator has
      disallowed IMDNs.

   o  "error" to indicate an error in determining the fate of an IM.

5.3.  Read

   The read notification type indicates whether the IM Recipient
   rendered the IM to the user or not.  The read notification type can
   have the following states:

   o  "read" is a state indicating that the IM has been displayed or
      played to the user.

   o  "forbidden" indicate denial, by the IM Recipient, for the IM
      Sender to receive the requested IMDN.

   o  "error" to indicate an error in determining the fate of an IM.

   Some IMs may in fact be audio, video or still images.  Therefore, the
   state "read" includes playing the audio or video file to the user.

   Since there is no positive acknowledgement from the user, one cannot
   determine a priori that the user actually read the IM.  Thus one
   cannot use the protocol described here as a non-repudiation service.

6.  New CPIM header fields Header Fields

   This specification extends the CPIM data format specified in RFC 3862
   [2].  A new namespace is created as well as a number of new CPIM
   header fields.

6.1.  CPIM header field Header Field Namespace

   Per CPIM [2], this specification defines a new namespace for the CPIM
   extension header fields defined in the following sections.  The
   namespace is:

   urn:ietf:params:cpim-header fields:imdn

   urn:ietf:params:imdn

   As per CPIM [2] requirements, the new header fields defined in the
   following sections are prepended, in CPIM messages, by a prefix
   assigned to the URN through the NS header field field of the CPIM message.
   The remaining of this specification always assumes an NS header field field
   like this one:

   NS: imdn <urn:ietf:params:cpim-header fields:imdn>. <urn:ietf:params:imdn>.

6.2.  Disposition-Notification

   The Disposition-Notification header field is used by the IM Sender to
   indicate the desire to receive IMDNs, from the IM Recipient, for that
   specific IM.  This header field is not needed if the IM Sender does
   not request an IMDN.  The syntax is defined in Section 10.

6.3.  Message-ID

   The Message-ID header field contains a globally unique message
   identifier that is used by the IM Sender to correlate received IMDNs
   by comparing its value with the value of the <message-id> element
   present in the IMDN payload.  This header field is MANDATORY when
   sending an IM and requesting an IMDN.  IMDNs also carry this header
   field.  The syntax is defined in Section 10.

6.4.  Original-To

   The Original-To header field is sometimes added to an IM by an
   intermediary and populated with the address of the IM Receiver.  It
   is used by the IM Recipient to indicate in the IMDNs (by populating
   the <original-recipient-uri> element) the original address the IM was
   sent to.  This header field is mandatory if the intermediary changes
   the CPIM To header field value.  The header field MUST NOT appear
   more than once in an IM.  The header field value MUST NOT be changed
   by an intermediary if it was already present.  The syntax is defined
   in Section 10.

6.5.  IMDN-Record-Route

   Intermediaries have the capability of indicating that IMDNs should be
   sent through it (otherwise, IMDNs will not visit the intermediary).

   An intermediary that request IMDNs to be sent through itself adds an
   IMDN-Record-Route header field to the IM.  The value of the IMDN-
   Record-Route header field is set to the address of that intermediary.
   Multiple IMDN-Record-Route header fields can appear in an IM.  The
   syntax is defined in Section 10.

6.6.  IMDN-Route

   The IMDN-Route header field provides routing information by including
   one or more addresses where an IMDN must be routed through.  On
   creating an IMDN, an IM recipient copies the contents of the IMDN-
   Record-Route present in the IM into the IMDN-Route of the IMDN.
   Multiple IMDN-Route header fields can appear in an IMDN.  The syntax
   is defined in Section 10.

7.  Endpoint Behaviour

7.1.  IM Sender

7.1.1.  Constructing Instant Messages

   An IM is constructed using CPIM Message Format defined in RFC 3862
   [2].

7.1.1.1.  Adding a Message-ID header field Header Field

   If the IM sender requests the reception of IMDNs, the IM sender MUST
   include a Message-ID header field.  The Message-ID field is populated
   with a value that is unique with 32 bits of randomness.  This header
   field enables the IM Sender to match any IMDNs with their
   corresponding IMs.

7.1.1.2.  Adding a DateTime header field Header Field

   Some devices may not implement the concept of "Sent Items" box and
   therefore no information about an IM is stored.  It is therefore
   necessary to add a time stamp in the IM to indicate when it was sent.
   This time stamp is returned in the IMDN in order to enable the user
   to correlate the IM with the IMDN at the human level.  The DateTime
   header field is used for this purpose.  The IM MUST contain a
   DateTime header field if an IMDN is requested.

7.1.1.3.  Adding a Disposition-Notification header field Header Field

   The Disposition-Notification conveys the type of disposition
   notification requested by the IM sender.  There are three types of
   disposition notification: delivery, processing, and read.  The
   delivery notification is further subdivided into failure and success
   delivery notifications.  An IM Sender requests failure delivery
   notification by including a Disposition-Notification header field
   with value "negative-delivery".  Similarly, a success notification is
   requested by including a Disposition-Notification header field with
   value "positive-delivery".  Both types of delivery notifications can
   be requested for the same IM.

   The IM Sender can request a processing notification by including a
   Disposition-Notification header field with value "processing".

   The IM Sender can also request a read notification.  It is requested
   by including a Disposition-Notification header field with value
   "read".

   The absence of this header field or the presence of the header field
   with empty value indicates that the IM Sender is not requesting any
   IMDNs.  The Disposition-Notification header fields field values can be comma
   separated.  The IM Sender MAY request more than one type of IMDN for
   a single IM.

   Future extension may define other disposition notifications not
   defined in this document.

   The formal syntax of the Disposition-Notification header field can be
   found in Section 10.  The following is an example CPIM body of an IM
   where the IM Sender requests positive and negative delivery
   notifications, but not read notification nor processing
   notifications:

     From: Alice <im:alice@example.com>
     To: Bob <im:bob@example.com>
     NS: imdn <urn:ietf:params:cpim-header fields:imdn> <urn:ietf:params:imdn>
     imdn.Message-ID: 34jk324j
     DateTime: 2006-04-04T12:16:49-05:00
     imdn.Disposition-Notification: positive-delivery, negative-delivery
     Content-type: text/plain
     Content-length: 12

     Hello World

7.1.2.  Matching IMs with IMDNs

   An IM Sender matches an IMDN to an IM by matching the Message-ID
   header field value in the IM with the <message-id> element value in
   the body of the IMDN.  If the IM was delivered to multiple
   recipients, the IM Sender uses the <recipient-uri> element and the
   <original-recipient-uri> element in the XML body of the IMDN it
   received to determine if the IM was sent to multiple recipients and
   to identify the IM Recipient that sent the IMDN.

7.1.3.  Keeping State

   This specification does not mandate the IM Sender to keep state for a
   sent IM.

   Once an IM Sender sends an IM containing an IMDN request, it MAY
   preserve the IM context, principally the Message-ID, and other user-
   identifiable information such as the IM subject or content, and date
   and time it was sent.  Without preservation of the IM context, the IM
   Sender will not be able to correlate the IMDN with the IM it sent.
   The IM Sender may find it impossible to preserve IM state if it has
   limited resources or does not have non-volatile memory and then loses
   power.

   There is, however, the concept of "Sent Items" box in an application
   that stores sent IMs.  This "Sent Items" box has the necessary
   information and may have a fancy user interface indicating the state
   of a sent IM.  Unique Message-ID for this purpose proves to be
   useful.  The length of time for items to remain in the "Sent Items"
   box is a user choice.  The user is usually free to keep or delete
   items from the "Sent Items" box as she pleases or as the memory on
   the device reaches capacity.

   Clearly, if an IM Sender loses its sent items state (user deletes
   items from the "Send Items" box), the client may use a different
   display strategy in response to apparently unsolicited IMDNs.

   This specification also does not mandate an IM Sender to run any
   timers waiting for an IMDN.  There are no time limits associated with
   when IMDNs may be received.

   IMDNs may legitimately never be received.  On the other hand, and
   IMDN may simply take a very long time.  Some clients may choose to
   purge the state associated with the sent IM.  This is the reason for
   adding the time stamp in the IM and having it returned in the IMDN.
   This gives the user some opportunity of remembering what IM was sent.
   For example if the IMDN indicates that the IM the user sent at 2 p.m.
   last Thursday was delivered, the user has a chance of remembering
   that they sent an IM at 2 p.m. last Thursday.

7.1.4.  Aggregation of IMDNs

   An IM Sender may send an IM to multiple recipients in one Transport
   Protocol Message (typically using a URI-List server) and request
   IMDNs.  An IM Sender that requested an IMDNs MUST be prepared to receive
   multiple aggregated or non-aggregated IMDNs.  See Section 8.2 for
   details.

7.2.  IM Recipient

7.2.1.  Constructing IMDNs

   IM recipients examine the contents of the Disposition-Notification
   header field of the CPIM message to determine if an IMDN must be
   generated for that IM.  Disposition-Notification header fields of
   CPIM messages can include one or more values.  This implies that IM
   recipients may need to generate zero, one, or more IMDNs for that IM,
   for example a delivery notification as well as a read notification.
   In this case the IM Recipient MUST be able to construct multiple
   IMDNs per IM.  An IM Recipient MUST NOT construct more than one IMDN
   per disposition type.  I.e.  It must not, for example, generate a
   delivery notification indicating "delivered" then followed by a
   delivery notification indicating "failed" for the same IM.  If the IM
   Sender requested only failure notifications and the IM was
   successfully delivered, then no IMDNs will be generated.

   The IM Recipient MUST NOT generate "processing" notifications.

   Disposition-Notification header field MUST NOT appear in an IMDN
   since it does not make sense and is therefore forbidden to request an IMDN for an IMDN.  IM Sender MUST
   ignore it if present.  The IM Sender MUST NOT send an IMDN to an
   IMDN.

   An IMDN MUST contain a Message-ID header field.  The same rules of
   uniqueness for the Message-ID header field that appears in an IM
   apply to an IMDN.  The Message-ID header field in the IMDN is
   different and unrelated to the one in the IM.

   An IM may contain a IMDN-Record-Route header field (see Section 8 for
   details).  If IMDN-Record-Route header fields appear in the IM, the
   IM Recipient constructing the IMDN MUST copy the contents of the
   IMDN-Record-Route header fields into IMDN-Route header fields in the
   IMDN and maintain the order.  The IMDN is then sent to the URI in the
   top IMDN-Route header field.  IMDN-Record-Route header fields do not
   make sense in an IMDN and therefore SHOULD NOT be placed in an IMDN.
   IMDN Recipients SHOULD ignore it if present.

   The CPIM Content-Disposition header field must be set to the value
   "notification".  This indicates to the IM Sender that the message is
   an IMDN to an IM it has earlier sent.

7.2.1.1.  Constructing Delivery Notifications

   A delivery notification is constructed in a similar fashion as an IM,
   using a CPIM body [2] that carries a Disposition Notification XML
   document formatted according to the rules specified in Section 11.
   The MIME type of the Disposition Notification XML document is
   "message/imdn+xml".

   An example CPIM body of IMDN looks like the following:

      From: Bob <im:bob@example.com>
      To: Alice <im:alice@example.com>
      NS: imdn <urn:ietf:params:cpim-header fields:imdn> <urn:ietf:params:imdn>
      imdn.Message-ID: d834jied93rf
      Content-type: message/imdn+xml
      Content-Disposition: notification
      Content-length: ...

      <?xml version="1.0" encoding="UTF-8"?>
      <imdn xlmns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2006-04-04T12:16:49-05:00</datetime>
         <recipient-uri>im:bob@example.com</recipient-uri>
         <original-recipient-uri>
             im:bob@example.com</original-recipient-uri>
         <disposition>
            <delivery/>
         </disposition>
         <status>
            <delivered/>
         </status>
         <note lang="en">The IM was successfully Delivered</note>
      </imdn>

7.2.1.2.  Constructing Read Notifications

   A read notification is constructed in a similar fashion as the
   delivery notification.  See Section 7.2.1.1 for details.

   An example looks like the following:

      From: Bob <im:bob@example.com>
      To: Alice <im:alice@example.com>
      NS: imdn <urn:ietf:params:cpim-header fields:imdn> <urn:ietf:params:imdn>
      imdn.Message-ID: dfjkleriou432333
      Content-type: message/imdn+xml
      Content-Disposition: notification
      Content-length: ...

      <?xml version="1.0" encoding="UTF-8"?>
      <imdn xlmns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2006-04-04T12:16:49-05:00</datetime>
         <recipient-uri>im:bob@example.com</recipient-uri>
         <original-recipient-uri>
             im:bob@example.com</original-recipient-uri>
         <disposition>
            <read/>
         </disposition>
         <status>
            <read/>
         </status>
         <note lang="en">The IM has been read</note>
      </imdn>

   There are situations where the IM Recipient cannot determine if or
   when the IM has been read.  The IM Recipient in this case generates a
   read notification with a <status> value of "error" to indicate an
   internal error by the server.  Note that the IM Recipient may choose
   to ignore any IMDN requests and not to send any IMDNs.  An example of
   this is when a SIP stack with built in IMDN support is talking to an
   IM application and the IM application never returned indicating that
   it has displayed the IM to the user.

8.  Intermediary Behaviour

   In this context, application servers (including URI-List servers and
   Store-and-Forward server) and gateways are defined as intermediaries.
   A gateway is a server the translates between different IM systems
   that use different protocols.

   A URI-List server may change the IM Recipient address from its own to
   the address of the final recipient of that IM for every copy it makes
   to be sent to the list members (see [12] [13] for details).  In this case,
   if the IM Sender is requesting an IMDN, the intermediary MUST add an
   Original-To header field to the IM populating it with the address
   that was in the CPIM To header field before it was changed.  I.e.
   The Original-To header field is populated with the intermediary
   address.  An intermediary MUST NOT add an Original-To header field if
   one already exists.

   An intermediary MAY choose to remain on the path of IMDNs for a
   specific IM.  It can do so by adding a CPIM IMDN-Record-Route header
   field as the top IMDN-Record-Route header field and populating it
   with its own address.  An intermediary that does not support this
   extension will obviously not add the IMDN-Record-Route header field.
   This allows IMDNs to traverse directly from the IM Recipient to the
   IM Sender even if the IM traversed an intermediary not supporting
   this extension.

   An intermediary receiving an IMDN checks the top IMDN-Route header
   field.  If that header field carries the intermediary address, the
   intermediary pops that value and forwards the IMDN to the address
   indicated in the now top IMDN-Route header field.  If no IMDN-Route
   header fields are present, the IMDN is forwarded to the address in
   the CPIM To header field.

   An intermediary MUST remove any information about the final
   recipients of a list if the list membership is not disclosed.  The
   intermediary does that by removing the <recipient-uri> element and/or
   <original-recipient-uri> element from the body of the IMDN before
   forwarding it to the IM Sender.

8.1.  Constructing Processing Notifications

   Intermediaries are the only entities that construct processing
   notifications.  They do so only if the IM Sender has requested a
   "processing" notification by including a Disposition-Notification
   header field with value "processing".

   The intermediary can create and send "processing" notifications
   indicating that an IM has been processed or stored.  The intermediary
   MUST NOT send more than one IMDN for the same disposition type.  I.e.
   It must not send a "processing" notification indicating that an IM is
   being "processed" followed by another IMDN indicating that the same
   IM is "stored".

   A "processing" notification is constructed in a similar fashion as
   the delivery notification.  See Section 7.2.1.1 for details.

   An example looks like the following:

      Content-type: Message/CPIM

      From: Bob <im:bob@example.com>
      To: Alice <im:alice@example.com>
      Content-type: message/imdn+xml
      Content-Disposition: notification
      Content-length: ...

      <imdn>
         <message-id>34jk324j</message-id>
         <datetime>2006-04-04T12:16:49-05:00</datetime>
         <recipient-uri>im:bob@example.com</recipient-uri>
         <original-recipient-uri>
             im:bob@example.com</original-recipient-uri>
         <disposition>
            <processing/>
         </disposition>
         <status>
            <processed/>
         </status>
         <note lang="en">The IM has been processed</note>
      </imdn>

   There are situations where the intermediary cannot know the fate of
   an IM.  The intermediary in this case generates a processing
   notification with a <status> value of "error" to indicate so.

8.2.  Aggregation of IMDNs

   In this context, URI-List servers are defined as intermediaries.

   An intermediary may choose to aggregate IMDNs using local policy for
   making such a decision or it may send individual IMDNs instead.  When
   a URI-List server receives an IM and decides to aggregate IMDNs, it
   waits
   can wait for a configurable period of time or until all recipients
   have sent the IMDN (whichever comes first) before the URI-List server
   sends an aggregated IMDN.  Note that some IMDNs, for example read
   notifications, may never come due to user settings.  It is an
   administrator configuration and an implementation issue how long to
   wait before sending an aggregated IMDN and before a URI-List server
   removes state for that IM.

   A URI-List server MAY choose to send multiple aggregated IMDNs.  A
   timer can be started and when it fires, the URI-List server can
   aggregate whatever IMDNs it has so far for that IM, send the
   aggregated IMDN and restart the timer for the next batch.  This is
   needed for scenarios where the IM Sender has requested more than one
   IMDN for a specific IM, for example, delivery notifications as well
   as read notifications, or when the URI-List server is short on
   resources and chooses to prioritise forwarding IMs over IMDNs.

   A second timer can be running and when it fires, the state of the IM
   is deleted.  In this case, the URI-List server consumes any IMDNs
   that might arrive after that time.

   Please note that the references to timers in the above paragraphs are
   not normative and are only present to help describe one way
   aggregation might be implemented.

   A URI-List server MAY aggregate IMDNs for the case where the list
   membership information is not disclosed.  There may be scenarios
   where the URI-List server starts sending aggregated IMDNs and switch
   to indivdual individual ones or visa versa.  A timer firing so ofter often may in
   fact have that effect.

   The aggregated IMDN is constructed using the multipart/mixed MIME
   type and including all the received IMDNs as message/imdn+xml as
   individual payloads.

   There are scenarios where an intermediary needs to generate IMDNs,
   see Section 12.2 for further details.

9.  Identifying Messages

   Messages are typically carried in a transport protocol like SIP [8].
   The message

   Below is an IM if the content-type header field field present
   in it has a value that is NOT "message/imdn+xml".

   A message is identified as a example of aggregated IMDNs.

      From: Bob <im:bob@example.com>
      To: Alice <im:alice@example.com>
      NS: imdn <urn:ietf:params:imdn>
      imdn.Message-ID: d834jied93rf
      Content-type: multipart/mixed;
                         boundary="imdn-boundary"
      Content-Disposition: notification
      Content-length: ...

       --imdn-boundary
      Content-type: message/imdn+xml

      <?xml version="1.0" encoding="UTF-8"?>
      <imdn xlmns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2006-04-04T12:16:49-05:00</datetime>
         <recipient-uri>im:bob@example.com</recipient-uri>
         <original-recipient-uri>
             im:bob@example.com</original-recipient-uri>
         <disposition>
            <delivery/>
         </disposition>
         <status>
            <delivered/>
         </status>
         <note lang="en">The IM was successfully Delivered</note>
      </imdn>

      --imdn-boundary
      Content-type: message/imdn+xml

      <?xml version="1.0" encoding="UTF-8"?>
      <imdn xlmns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2006-04-04T12:16:49-05:00</datetime>
         <recipient-uri>im:bob@example.com</recipient-uri>
         <original-recipient-uri>
             im:bob@example.com</original-recipient-uri>
         <disposition>
            <read/>
         </disposition>
         <status>
            <read/>
         </status>
         <note lang="en">The IM was successfully Delivered</note>
      </imdn>

      --imdn-boundary

9.  Identifying Messages

   Messages are typically carried in a transport protocol like SIP [8].
   If the payload carried by the transport protocol does not contain any
   parts of type Message/CPIM then the message is an IM.  If the payload
   contains any parts of type Message/CPIM, and none of those parts
   contains a payload that is of type "message/imdn+xml", the message is
   an IM.  It is not valid to attempt to carry both an IM and an IMDN in
   a multipart payload in a single transport protocol message.

   A message is identified as a delivery notification by examining its
   contents.  The message is a delivery notification if: if the Content-
   type Content-type
   header field present has a value of "message/imdn+xml", the
   Content-Disposition Content-
   Disposition header field field has a value of "notification", and the
   <disposition> element in that xml body has a sub-element <delivery>.

   A message is identified as a processing notification or read
   notification in a similar fashion as a delivery notification.  The
   difference is that the <disposition> element in that xml body has a
   sub-element of <processing> and <read> respectively.

10.  header fields  Header Fields Formal Syntax

   The following syntax specification uses the message header field
   syntax as described in Section 3 of RFC3862 [2].

   header

   Header field syntax is described without a namespace qualification.
   Following the rules in RFC3862 [2], header field names and other text
   are case sensitive and MUST be used as given, using exactly the
   indicated upper-case and lower-case letters.

         Disposition-Notification =
             "Disposition-Notification" ": "
             [(notify-req *(COMMA notify-req))]
         notify-req =
             ("negative-delivery" / "positive-delivery" /
             "processing" / "read" / Token) *(SEMI disp-notif-params)

         disp-notify-params = generic-param

         Message-ID = "Message-ID" ": " Token

         Original-To = "Original-To" ": "  [ Formal-name ] "<" URI ">"

         IMDN-Record-Route =
             "IMDN-Record-Route" ": "  [ Formal-name ] "<" URI ">"
         IMDN-Route = "IMDN-Route" ": "  [ Formal-name ] "<" URI ">"

11.  IMDN Format

11.1.  Structure of XML-Encoded IMDN Payload

   An IMDN Payload is an XML document [7] [6] that MUST be well-formed and
   MUST be valid according to schemas, including extension schemas,
   available to the validater and applicable to the XML document.  The
   IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
   UTF-8.

   The namespace identifier for elements defined by this specification
   is a URN [4], using the namespace identifier 'ietf' defined by [5] [12]
   and extended by [3].  This urn is: urn:ietf:params:xml:ns:imdn.

   This namespace declaration indicates the namespace on which the IMDN
   is based.

   The root element is <imdn>.  The <imdn> element has sub-elements,
   namely <message-id>, <datetime>, <recipient-uri>, <original-
   recipient-uri>, <subject>, <disposition>, <status>, and <note>.
   Those elements are described in details in the following sections.

   <disposition> and <status> can be extended in the future to include
   new sub-elements not defined in this document.  Those new elements
   MUST be defined in an RFC.

11.1.1.  The <message-id> Element

   The <message-id> element is mandatory according to the XML schema and
   carries the message id that appeared in the Message-ID header field
   of the IM.

11.1.2.  The <datetime> Element

   The <datetime> element is mandatory and carries the date and time the
   IM was sent (not the IMDN).  This information is obtained from the
   DateTime header field of the IM.

11.1.3.  The <recipient-uri> Element

   The <recipient-uri> element is optional and carries the URI of the
   final recipient.  This information is obtained from the CPIM To
   header field of the IM.

11.1.4.  The <original-recipient-uri> Element

   The <original-recipient-uri> element is optional and carries the URI
   of the original recipient.  It MUST be present if the IM carried the
   Original-To header field.  This information is obtained from the
   Original-To header field of the IM.

11.1.5.  The <subject> Element

   The <subject> element is optional and carries the text that was in
   the Subject header field, if any.  This allows for a human level
   correlation between an IM and an IMDN.

11.1.6.  The <disposition> Element

   The <disposition> element is mandatory and carries the disposition
   type that the IM Sender requested and is being reported.  It can
   carry one of the sub-elements <delivery>, <processing>, <read> or any
   other future extension.

11.1.7.  The <status> Element

   The <status> element is mandatory and carries the result of the
   disposition request in the <disposition> element.  For disposition
   type <delivery>, it can carry one of the sub-elements <delivered>,
   <failed>, <forbidden> or <error>.  For disposition type <read>, it
   can carry one of the sub-elements <read>, <forbidden> or <error>.
   For disposition type <processing>, it can carry one of the sub-
   elements <processed>, <stored>, <forbidden> or <error>. <forbidden>
   means the disposition was denied. <error> means internal server
   error.  It can also carry any other future extension.

11.1.8.  The <note> Element

   The <note> element is optional and carries a human readable text.  It
   has the "lang" attribute that indicates the language the text is
   written in.

11.2.  MIME Type for IMDN Paylaod Payload

   The MIME type for the IMDN Payload is "message/imdn+xml".  The IMDN
   MUST identify the payload as MIME type "message/imdn+xml" in the
   Content-type header field.

11.3.  The RelaxNG Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <grammar
     xmlns="http://relaxng.org/ns/structure/1.0"
     xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
     datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
     ns="urn:ietf:params:xml:ns:imdn">

       <start>
           <element name="imdn">
               <element name="message-id">
                   <data type="token"/>
               </element>
               <element name="datetime">
                   <data type="string"/>
               </element>
               <optional>
                   <element name="recipient-uri">
                       <data type="anyURI"/>
                   </element>
                   <element name="original-recipient-uri">
                       <data type="anyURI"/>
                   </element>
                   <element name="subject">
                       <data type="string"/>
                   </element>
               </optional>
               <choice>
                   <ref name="deliveryNotification"/>
                   <ref name="readNotification"/>
                   <ref name="processingNotification"/>
                   <zeroOrMore>
                       <empty/>
                   </zeroOrMore>
               </choice>
               <ref name="note"/>
               <zeroOrMore>
                   <ref name="Extension"/>
               </zeroOrMore>
               <zeroOrMore>
                   <ref name="anyIMDN"/>
               </zeroOrMore>
           </element>
       </start>

       <define name="deliveryNotification">
           <element name="disposition">
               <element name="delivery">
                   <empty/>
               </element>
           </element>
           <element name="status">
               <choice>
                   <element name="delivered">
                       <empty/>
                   </element>
                   <element name="failed">
                       <empty/>
                   </element>
                   <ref name="commonDispositionStatus"></ref>
                   <zeroOrMore>
                       <ref name="Extension"/>
                   </zeroOrMore>
                   <zeroOrMore>
                       <ref name="anyIMDN"/>
                   </zeroOrMore>
               </choice>
           </element>
       </define>

       <define name="readNotification">
           <element name="disposition">
               <element name="read">
                   <empty/>
               </element>
           </element>
           <element name="status">
               <choice>
                   <element name="read">
                       <empty/>
                   </element>
                   <ref name="commonDispositionStatus"></ref>
                   <zeroOrMore>
                       <ref name="Extension"/>
                   </zeroOrMore>
                   <zeroOrMore>
                       <ref name="anyIMDN"/>
                   </zeroOrMore>
               </choice>
           </element>
       </define>

       <define name="processingNotification">
           <element name="disposition">
               <element name="processing">
                   <empty/>
               </element>
           </element>
           <element name="status">
               <choice>
                   <element name="processed">
                       <empty/>
                   </element>
                   <element name="stored">
                       <empty/>
                   </element>
                   <ref name="commonDispositionStatus"></ref>
                   <zeroOrMore>
                       <ref name="Extension"/>
                   </zeroOrMore>
                   <zeroOrMore>
                       <ref name="anyIMDN"/>
                   </zeroOrMore>
               </choice>
           </element>
       </define>

       <define name="commonDispositionStatus">
           <choice>
               <element name="forbidden">
                   <empty/>
               </element>
               <element name="error">
                   <empty/>
               </element>
               <zeroOrMore>
                   <ref name="Extension"/>
               </zeroOrMore>
               <zeroOrMore>
                   <ref name="anyIMDN"/>
               </zeroOrMore>
           </choice>
       </define>

       <define name="note">
           <element name="note">
               <optional>
                   <attribute>
                       <name ns="http://www.w3.org/XML/1998/namespace">
                           lang
                       </name>
                       <data type="language"/>
                   </attribute>
               </optional>
               <data type="string"/>
           </element>
       </define>

       <define name="Extension">
           <empty/>
       </define>

       <define name="anyIMDN">
           <element>
               <anyName>
                   <except>
                       <nsName ns="urn:ietf:params:xml:ns:imdn"/>
                       <nsName ns=""/>
                   </except>
               </anyName>
               <mixed>
                   <zeroOrMore>
                       <choice>
                           <attribute>
                               <anyName/>
                           </attribute>
                           <ref name="anyIMDN"/>
                       </choice>
                   </zeroOrMore>
               </mixed>
           </element>
       </define>

   </grammar>

12.  Transporting Messages using SIP

12.1.  Endpoint Behaviour

12.1.1.  Sending Requests

   A SIP MESSAGE request is constructed using RFC 3428 [9].  The
   Content-type header field indicates the MIME type of the request
   payload.  When using this extension, the Content-type header field
   MUST be of MIME type "message/cpim" [2] for both IMs and IMDNs.  The
   payload is constructed according to Section 7.

   A SIP MESSAGE request to multiple recipients is constructed in a
   similar manner as a SIP MESSAGE request to a single recipient.  The
   differences are indicated in [12]. [13].

12.1.2.  Sending Responses

   An endpoint receiving a SIP MESSAGE request constructs a SIP response
   according to RFC3428 [9].  Of course, an endpoint will send a
   response to the MESSAGE request regardless of they type of message
   (IM or IMDN) is has received, or the disposition type it has been
   asked for.

12.1.3.  Receiving Requests

12.1.3.1.  Instant Message

   A SIP MESSAGE request is identified as an IM by examining its
   contents according to Section 9.

   If an IM Recipient received a SIP MESSAGE request that is an IM that
   requested a positive-delivery notification, and that IM Recipient has
   constructed and sent a SIP 2xx class response, it MAY generate a
   positive-delivery notification after making sure that the IM has been
   delivered to the user or application (a gateway, for example, can
   generate a 2xx response before it has been guaranteed that the final
   recipient has actually received the IM).  The positive-delivery
   notification is constructed according to Section 7.2.1.1.  The
   message is then placed as the payload in a SIP MESSAGE request.

   If an IM Recipient received a SIP MESSAGE request that is an IM that
   requested a negative-delivery, and that IM Recipient has constructed
   and sent a 2xx class response, it SHOULD generate a negative-delivery
   notification if it learnt that the final recipient or application did
   not receive the IM (a gateway, for example, can generate a 2xx
   response before it has been guaranteed that the final recipient has
   actually received the IM). an error response from downstream or before
   any internal timers fire waiting for a response).  The negative-delivery negative-
   delivery notification is constructed according to Section 7.2.1.1.
   The message is then placed as the payload in a SIP MESSAGE request.

   If an IM Recipient received a SIP MESSAGE request that is an IM that
   requested a negative-delivery notification, and the IM Recipient has
   constructed and sent an non-2xx final response, it MUST NOT generate
   a negative-delivery notification.

   If an IM Recipient received a SIP MESSAGE request that is an IM that
   requested a read notification, and that IM Recipient has constructed
   and sent a SIP 2xx class response, it MAY generate a read
   notification after making sure that the IM has been presented to the
   user or application.  It is outside the scope of this document how
   such determination can be made.  Note that the option to send a read
   notification or not can be left to the user.  An application may
   allow a user to configure such choice.  The read notification is
   constructed according to Section 7.2.1.2.  The message is then placed
   as the payload in a SIP MESSAGE request.

   For IMDNs, the SIP Request-URI and the SIP To header field are
   populated using the address that appeared in the SIP From header
   field field in the IM.

12.1.3.2.  Delivery Notification

   A SIP MESSAGE request is identified as delivery notification by
   examining its contents according to Section 9.

12.1.3.3.  Read Notification

   A SIP MESSAGE request is identified as read notification by examining
   its contents according to Section 9.

12.2.  Intermediary Behaviour

   In this context, application servers (including URI-List servers and
   Store-and-Forward server) and gateways are defined as intermediaries.
   SIP Proxies MUST NOT generate IMDNs but MUST forward them like any
   other sip request.

   A SIP MESSAGE request to multiple recipients is forwarded according
   to [12]. [13].

   If an intermediary generates a SIP 2xx class response to a SIP
   MESSAGE request it has received that is an IM, it examines if the
   body was of type "message/cpim".  If so, it checks the CPIM header to
   see if there is the header field Disposition-Notification with a
   value "positive-
   delivery" "positive-delivery" and/or "negative-delivery".  If so, it MUST
   send a delivery notification after receiving a transactional final
   response for the IM.

   If the Disposition-Notification header field contains a value of
   "positive-delivery", the intermediary MUST NOT generate a delivery
   notification if it receives a SIP 2xx class response for the sent IM.
   This is in anticipation of a failure downstream after a 2xx response
   has been generated.

   If the Disposition-Notification header field contains a value of
   "negative-delivery", the intermediary SHOULD generate a delivery
   notification if it receives a SIP 4xx, 5xx or 6xx class final
   response for the sent IM.  If it has received a SIP 2xx class
   response followed by a negative-delivery notification, the
   intermediary forwards that negative-delivery notification or
   aggragates
   aggregates it.

   If the Disposition-Notification header field contains a value of
   "processing", the intermediary MAY generate a processing notification
   after it has forwarded or stored the IM.  The rest of the procedures
   in Section 8.1 apply.

   The procedure for generating such IMDN is the same as that of an IM
   Recipient (Section 7.2.1.1).

   The <recipient-uri> element of the XML body is populated with the URI
   of the IM Recipient.

   If an intermediary receives a SIP MESSAGE request carrying a positive
   delivery notification or a read notification, it forwards it using
   the rules in Section 8.

13.  Transporting Messages using MSRP

   MSRP already provides a built-in mechanism to supply positive and
   negatie
   negative delivery reports.

   While MSRP does not provide a built-in Read or Processing
   notification dispositions, those are generally not considered as
   useful information for session IM.  This is because the assumption
   behind MSRP is that SEND requests do not reach a mailbox where
   incoming IMs have to be open, but to an application that renders
   sequentially those incoming IMs, providing the session experience.
   This kind of applications has no means of identifying when a user has
   read the IM and therefore cannot be useful information for the
   sender.

   IMDN use cases for MSRP have not been fully explored.  If new
   requirements arise in the future determining the need for IMDN in
   MSRP, new specifications can be drafted.

14.  Security Considerations

   IMDNs provide a fine-grained view of the activity of the IM Recipient
   and thus deserves particularly careful confidentiality protection so
   that only the intended recipient of the IMDN will receive the IMDN
   (in most cases, the intended recipient of the IMDN is the IM Sender).

   Since IMDNs are carried by using the IM protocol itself, all security
   considerations of the underlying IM protocol also apply to the IMDNs.

   The threats in the IMDN system, over and beyond the threats inherent
   to IM include the following:

   o  A malicious endpoint attempts to send messages to a user that
      would normally not wish to receive messages from that endpoint by
      convincing the IMDN system to "bounce" an IMDN from an
      unsuspecting endpoint to the user.

   o  A malicious endpoint attempts to flood a IM Sender with IMDNs by
      convincing a URI-List server to send IMDNs to an unsuspecting IM
      Sender.

   o  A malicious node in the network that attempts to modify an IMDN
      from a IM Recipient.

   o  A malicious intermediary attempts to forward an IMDN from an IM
      Recipient to the IM Sender, where the IM Recipient would not
      normally forward the IMDN to that IM Sender if the IM Recipient
      knew the identity of the IM Sender.

   o  A malicious endpoint that attempts to fish for a Request-URI of an
      endpoint beyond an intermediary , where the endpoint would
      normally wish to keep its identity private from the malicious
      endpoint.

   o  A malicious node in the network that attempts to eavesdrop on IMDN
      traffic to, for example, learn Request-URI or traffic pattern
      information.

   o  A malicious node in the network attempts to stage a denial of
      service attack on an intermediary by requesting a large list
      expansion.

   The protocol cannot protect against attacks that include the
   following:

   o  A malicious intermediary directly revealing the identity of a
      downstream endpoint that would not normally wish its identity
      revealed.  Keeping such information private is an intermediary
      implementation issue.

   o  A malicious IM Recipient that alters the time of the IMDN.  There
      is no protocol mechanism for ensuring that the IM Recipient does
      not lie about the time or purposely holds an IMDN for transmission
      to make it appear that the user read an IM later than they
      actually did.

   o  A deletion attack on an IMDN.  This is a trade-off between privacy
      and security.  The privacy considerations allow the IM Recipient
      to silently ignore an IMDN request.  Any mechanism that would
      reliably indicate that a malicious node deleted a IM Recipient's
      IMDN would also serve the purpose of detecting a IM Recipient that
      chose not to issue an IMDN.

   To combat eavesdropping, modification, and man-in-the-middle attacks,
   we require some level of authentication and integrity protections.
   That said, there are circumstances where strong integrity would be
   overkill.  The presumption is the IM Sender has and sets the
   expectation for the level of protection.  The procedures for
   integrity protection are as follows.

   o  If the IM Recipient has a certificate, it MUST sign the IMDN.

   o  If the IM is encrypted, the IM Recipient or intermediary MUST
      encrypt the IMDN body, as an attacker may attempt to discern the
      user's activity profile and identity from sniffing IMDNs on the
      network.

   o  The two above rules are cumulative.

   The IM Recipient or intermediary MUST be capable of loading a user
   certificate. accessing the IM
   Sender's public certificate in order to verify the signature in the
   IM.

   An attacker can mount a distributed denial of service attack on a
   node by sending lots of IMs to the node with IMDN requests.  Note
   that this is the same problem as there is without IMDN; IMDN simply
   linearly increases the load on the node under attack.  One can
   mitigate, but not eliminate this threat by the endpoint immediately
   ignoring requests that are not authenticated.

   Likewise, an attacker can mount a denial of service attack on an
   intermediary by asking the intermediary to explode a large list.

   The following security considerations apply when using IMDNs:

14.1.  Forgery

   IMs can be forged.  To protect against that, an IM can be signed.  An
   intermediary that receives a signed message and needs to modify any
   part of it that is included in the signature (like adding an
   Original-To header field to the CPIM header fields), MUST consume the
   IM and create a new copy of it that the intermediary signs itself.

   IMDNs may be forged as easily as ordinary IMs.  Endpoints and
   intermediaries that wish to make automatic use of IMDNs should take
   appropriate precautions to minimize the potential damage from denial-
   of-service attacks.  Security threats related to forged IMDNs include
   the sending of a falsified IMDN when the indicated disposition of the
   IM has not actually occurred.  For example, read notification could
   be forged to indicate that a IM Recipient has read the IM.
   Unsolicited IMDNs is also another form of forgery.

14.2.  Confidentiality

   There may be cases where an IM Recipient does not wish to reveal the
   information that he has received or in fact read the IM.  In this
   situation, it is acceptable for the IM Recipient to silently ignore
   requests for an IMDN.  It is strongly RECOMMENDED that the IM
   Recipient obtain the user's consent before sending an IMDN.
   Circumstances where the IM Recipient does not ask for the user's
   consent include IM systems that, for regulatory reasons, are required
   to issue an IMDN, such as in the health care field or financial
   community.

   An IM Recipient can obtain such consent by a prompt or dialog box on
   a per-IM basis, globally through the user's setting of a preference,
   or other, user-configurable mechanism.  The user might also indicate
   globally that IMDNs are never to be sent or that a "forbidden" IMDN
   status is always sent in response to a request for an IMDN.

   There are situations where a user sends an IM and requests IMDNs to a
   list who's member information is not disclosed.  In this situation,
   the user will learn of the list members.  Therefore, in this case,
   the URI-List server MUST remove any information about list members.
   If the number of members in the list is also not disclosed, the URL-
   List server MUST only deliver one aggregated IMDN.  Alternatively,
   the URI-list server MAY reject the IM.

   An unencrypted IMDN could reveal confidential information about an
   encrypted IM.  It is a MUST that the same level of security applied
   to an IM to be applied to its IMDNs.  For example, if an IM is signed
   and encrypted, and IMDN must also be signed and encrypted.

14.3.  Non-Repudiation

   IMDNs cannot be relied on as a guarantee that an IM was or was not
   seen by the user.  Even if IMDNs are not actively forged, they may be
   lost in transit.  The IMDN issuing mechanism may be bypassed in some
   manner by the IM Recipient.

15.  IANA Considerations

15.1.  message/imdn+xml MIME TYPE

   This document registers a new MIME type "message/imdn+xml", and
   registers a new XML namespace.

   This specification follows the guidelines of RFC3023 [6]. [5].

   MIME media type: message

   MIME subtype name: imdn+xml

   Mandatory parameters: none

   Optional parameters: Same as charset parameter application/xml as
   specified in RFC 3023 [6]. [5].

   Encoding considerations: Same as encoding considerations of
   application/xml as specified in RFC 3023 [6]. [5].

   Security considerations: See section 10 of RFC 3023 [6] [5] and
   Section 14 of this document.

   Interoperability considerations: none.

   Published specification: This document.

   Applications which use this media type: This document type is used to
   support SIP CPIM based instant messaging.

   Additional information: None

   Magic number: None

   File extension: .cl or .xml

   Macintosh file type code: "TEXT"

   Personal and email address for further information: Hisham Khartabil
   (hisham.khartabil@telio.no)
   (hisham.khartabil@gmail.com)

   Intended Usage: COMMON

   Author/change controller: The IETF .

15.2.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn

   This section registers a new XML namespace, as per guidelines in the
   IETF XML Registry [3].

   URI: The URI for this namespace is urn:ietf:params:xml:ns:imdn.

   Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
   (hisham.khartabil@telio.no)
   (hisham.khartabil@gmail.com) .

15.3.  Schema Registration

   This section registers a new XML schema per the procedures in [3].

   URI: urn:ietf:params:xml:ns:imdn

   Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil
   (hisham.khartabil@telio.no)
   (hisham.khartabil@gmail.com)

   The XML for this schema can be found as the sole content of
   Section 11.3.

15.4.  Message/CPIM  Registration for urn:ietf:params:imdn

   Registry name: imdn

   Specification: RFC XXXX.  Additional values may be defined by
   standards track RFCs that update or obsolete RFC XXXX (Specification
   Required).

   Repository: http://www.iana.org/assignments/imdn

   Index value: The index value is a CPIM message IMDN header field registration name,
   which may consist of a sequence from a restricted set of US-ASCII
   characters, as defined above.

   URN Formation: The URI for a header is formed from its name by:

      a) replacing any non-URN characters (as defined by RFC 2141[4])
      with the corresponding '%hh' escape sequence (per RFC 2396 [7]);
      and

      b) prepending the resulting string with 'urn:ietf:params:imdn:'.

   Thus, the URI corresponding to the CPIM message IMDN header
   'Disposition-Notification:' would be
   'urn:ietf:params:imdn:Disposition-Notification'.

15.5.  Message/CPIM Header Field Registration

   This document registers the following message/cpim header fields in
   the cpim-header imdn fields registry:

   Disposition-Notification - [RFCXXXX]

   Message-ID - [RFCXXXX]

   Original-To - [RFCXXXX]

   IMDN-Record-Route - [RFCXXXX]

   IMDN-Route - [RFCXXXX].

15.5.

15.6.  Content-Disposition: notification

   This document registers one new Content-Disposition header field
   "disposition-types": notification.  The authors request that this
   values be recorded in the IANA registry for Content-Dispositions.

   Descriptions of this "disposition-types", including motivation and
   examples, are given in Section 7.2.1.1 and Section 9.

   Short descriptions suitable for the IANA registry are:

   notification the body of the message is a notification according to
   an earlier request for a disposition notification to an instant
   message

16.  Acknowledgements

   The authors would like to thank Paul Kyzivat, Ben Campbell, Adam
   Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia,
   Eric McMurry and McMurry, Jari Urpalainen and Robert Sparks for their comments
   and support.

17.  References

17.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
         (CPIM): Message Format", RFC 3862, August 2004.

   [3]   Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.

   [4]   Moats, R., "The URN Syntax", RFC 2141, May 1997.

   [5]   Moats, R., "The URN Namespace for IETF Documents", RFC 2648,
         August 1999.

   [6]   Murata, M., "XML Media Types", RFC 3023, March 1997.

   [7]

   [6]   Bray, T., "Extensible Markup Language (XML) 1.0 (Second
         Edition)",  W3C CR CR-xml11-20011006, October 2000.

   [7]   Berners-Lee, T., Fielding, R., and L. Masinter, "URI: Generic
         Syntax", RFC 3023, August 1998.

17.2.  Informative References

   [8]   Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston,
         A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
         "SIP: Session Initiation Protocol", RFC 3261, June 2002.

   [9]   Campbell, B., "SIP Extension for Instant Messaging", RFC 3428,
         December 2002.

   [10]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
         April 2001.

   [11]  Fajman, R., "An Extensible Message Format for Message  Hansen, T. and G. Vaudreuil, "Message Disposition Notifications",
         Notification", RFC 2298, March 1998. 3798, May 2004.

   [12]  Moats, R., "The URN Namespace for IETF Documents", RFC 2648,
         August 1999.

   [13]  Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
         Requests in SIP",  draft-ietf-sip-uri-list-message-01.txt,
         January 2007.

Authors' Addresses

   Eric Burger
   BEA Systems, Inc.
   4 Van de Graaff Dr.
   Burlington, MA  01803
   USA

   Phone: +1 781 993 7437
   Fax:   +1 603 457 5933
   Email: eric.burger@bea.com
   Hisham Khartabil
   Melbourne
   Australia

   Phone: +61 416 108 890
   Email: hisham.khartabil@gmail.com

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).