[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-burger-simple-imdn) 00 01 02 03 04 05 06 07 08 09 10 RFC 5438

SIMPLE                                                         E. Burger
Internet-Draft
Intended status: Standards Track                            H. Khartabil
Expires: June 12, 2009                                Ericsson Australia
                                                       December 09, 2008


                Instant Message Disposition Notification
                       draft-ietf-simple-imdn-10

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 June 12, 2009.

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




Burger & Khartabil        Expires June 12, 2009                 [Page 1]

Internet-Draft                    IMDN                     December 2008


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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Disposition Types  . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Delivery . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Processing . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.3.  Display  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  New CPIM Header Fields . . . . . . . . . . . . . . . . . . . .  7
     6.1.  CPIM Header Field Namespace  . . . . . . . . . . . . . . .  7
     6.2.  Disposition-Notification . . . . . . . . . . . . . . . . .  8
     6.3.  Message-ID . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.4.  Original-To  . . . . . . . . . . . . . . . . . . . . . . .  9
     6.5.  IMDN-Record-Route  . . . . . . . . . . . . . . . . . . . .  9
     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  . . . . . . . . . . . . . . . 11
       7.1.3.  Keeping State  . . . . . . . . . . . . . . . . . . . . 11
       7.1.4.  Aggregation of IMDNs . . . . . . . . . . . . . . . . . 12
     7.2.  IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12
       7.2.1.  Constructing IMDNs . . . . . . . . . . . . . . . . . . 12
   8.  Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Constructing Processing Notifications  . . . . . . . . . . 16
     8.2.  Constructing Delivery Notifications  . . . . . . . . . . . 17
     8.3.  Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 18
   9.  Identifying Messages . . . . . . . . . . . . . . . . . . . . . 20
   10. Header Fields Formal Syntax  . . . . . . . . . . . . . . . . . 20
   11. IMDN Format  . . . . . . . . . . . . . . . . . . . . . . . . . 21
     11.1. Structure of XML-Encoded IMDN Payload  . . . . . . . . . . 21
       11.1.1. The <message-id> Element . . . . . . . . . . . . . . . 22
       11.1.2. The <datetime> Element . . . . . . . . . . . . . . . . 22
       11.1.3. The <recipient-uri> Element  . . . . . . . . . . . . . 22
       11.1.4. The <original-recipient-uri> Element . . . . . . . . . 23
       11.1.5. The <subject> Element  . . . . . . . . . . . . . . . . 23
       11.1.6. The <delivery-notification>,
               <processing-notification> and
               <display-notification> Elements  . . . . . . . . . . . 23
       11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 23
       11.1.8. MIME Type for IMDN Payload . . . . . . . . . . . . . . 23
       11.1.9. The RelaxNG Schema . . . . . . . . . . . . . . . . . . 23



Burger & Khartabil        Expires June 12, 2009                 [Page 2]

Internet-Draft                    IMDN                     December 2008


   12. Transporting Messages using SIP  . . . . . . . . . . . . . . . 27
     12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 27
       12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 27
       12.1.2. Sending Responses  . . . . . . . . . . . . . . . . . . 28
       12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 28
     12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 29
   13. Transporting Messages using MSRP . . . . . . . . . . . . . . . 30
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 31
     14.1. Forgery  . . . . . . . . . . . . . . . . . . . . . . . . . 33
     14.2. Confidentiality  . . . . . . . . . . . . . . . . . . . . . 33
     14.3. IMDN as a Certified Delivery Service . . . . . . . . . . . 34
   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
     15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 34
     15.2. XML Registration . . . . . . . . . . . . . . . . . . . . . 35
     15.3. Registration for urn:ietf:params:imdn  . . . . . . . . . . 35
     15.4. Content-Disposition: notification  . . . . . . . . . . . . 36
   16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 37
     17.2. Informative References . . . . . . . . . . . . . . . . . . 37
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
   Intellectual Property and Copyright Statements . . . . . . . . . . 39





























Burger & Khartabil        Expires June 12, 2009                 [Page 3]

Internet-Draft                    IMDN                     December 2008


1.  Introduction

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

   Electronic Mail [RFC2821] offers a solution to this need with Message
   Delivery Notifications [RFC3798].  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 RFC 3798 [RFC3798].  The fixed format ensures that an
   automaton can process the message.

   The common presence and instant messaging (CPIM) format, Message/CPIM
   [RFC3862], is a message format used to generate instant messages.
   The session initiation protocol, SIP [RFC3261], can carry instant
   messages generated using message/CPIM in SIP MESSAGE requests
   [RFC3428].

   This document extends the Message/CPIM message format in much the
   same way Message Delivery Notifications extends Electronic Mail.
   This extension enables Instant Message Senders to request, create,
   and send Instant Message Disposition Notifications (IMDN).  This
   mechanism works for page-mode as well as session mode instant
   messages.  This document only discusses page-mode.  Session mode is
   left for future standardisation efforts.

   This specification defines three categories of disposition types,
   "delivery", "processing", and "displayed".  Specific disposition
   types provide more detailed information.  For example, the "delivery"
   category includes "delivered" to indicate successful delivery and
   "failed" to indicate failure in delivery.


2.  Conventions

   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 RFC 2119 [RFC2119].

   This document refers generically to the sender of a message in the
   masculine (he/him/his) and the recipient of the message in the
   feminine (she/her/hers).  This convention is purely for convenience
   and makes no assumption about the gender of a message sender or
   recipient.






Burger & Khartabil        Expires June 12, 2009                 [Page 4]

Internet-Draft                    IMDN                     December 2008


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 an 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.
      Also, the endpoint request IMDNs for an IM.  Quite often, the IM
      Sender is the IMDN Recipient.  However, that is not always the
      case, since the IMDN uses the From header in the CPIM message.
      That value is often the IM Sender's Address of Record (AOR).  This
      address may in fact resolve to different User Agents.
   o  IM Recipient: An endpoint (User Agent) that receives IMs.  The IM
      Recipient, as the node that presumably renders the IM to the user,
      generates and sends delivery IMDNs to IMs, if requested by the IM
      Sender and allowed by the IM Recipient.
   o  Endpoint: An IM Sender or an IM Recipient.
   o  Intermediary: An entity in the network, most often an application
      server, including URI-List servers and Store-and-Forward servers,
      that forwards an IM to its final destination.  Intermediaries also
      can generate and send processing IMDNs to IMs, if requested by the
      IM Sender and allowed by policy.
   o  Gateway: An intermediary that translates between different IM
      systems that use different protocols.
   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 categories of disposition types,
      "delivery", "processing", and "display".
   o  Transport Protocol Message: A SIP or other protocol message that
      contains an IM or IMDN.


4.  Overview

   The diagram below shows the basic protocol flow.  An IM Sender
   creates an IM, adds IMDN request information the IM Sender is
   interested in receiving and then sends the IM.  At a certain point in
   time, the IM Recipient or an intermediary determines that the user or
   application has received, did not receive, displayed, 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).





Burger & Khartabil        Expires June 12, 2009                 [Page 5]

Internet-Draft                    IMDN                     December 2008


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


                          Basic IMDN Message Flow

   Note 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 IM,
   resolves to a different location or user agent than the IM
   originated.  This could happen, for example, if resolving the AOR
   results in forking the request to multiple user agents.  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 display.

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 IM Recipient can send the "forbidden" state,
      but usually it is an intermediary that sends the message if one
      configures it to do so.  For example, it is possible the
      administrator has disallowed IMDNs.





Burger & Khartabil        Expires June 12, 2009                 [Page 6]

Internet-Draft                    IMDN                     December 2008


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

5.2.  Processing

   The processing notification type indicates that an intermediary has
   processed an IM.  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 intermediary stored the IM 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.  Display

   The display notification type indicates whether the IM Recipient
   rendered the IM to the user or not.  The display notification type
   can have the following states:
   o  "displayed" is a state indicating that the IM has been rendered 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.

   In addition to text, some IMs may contain audio, video, and still
   images.  Therefore, the state "displayed" includes the start of
   rendering the audio or video file to the user.

   Since there is no positive acknowledgement from the user, one cannot
   determine the user actually read the IM.  Thus, one cannot use the
   protocol described here as a service to prove someone actually read
   the IM.


6.  New CPIM Header Fields

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

6.1.  CPIM Header Field Namespace

   Per CPIM [RFC3862], this specification defines a new name space for
   the CPIM extension header fields defined in the following sections.



Burger & Khartabil        Expires June 12, 2009                 [Page 7]

Internet-Draft                    IMDN                     December 2008


   The name space is:

   urn:ietf:params:imdn

   As per CPIM [RFC3862] 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 of the CPIM message.
   The remaining of this specification always assumes an NS header field
   like this one:

   NS: imdn <urn:ietf:params:imdn>.

   Of course, clients are free to use any prefix while servers and
   intermediaries must accept any legal name space prefix specification.

6.2.  Disposition-Notification

   The IM Sender MUST include the Disposition-Notification header field
   to indicate the desire to receive IMDNs from the IM Recipient, for
   that specific IM.  Section 10 defines the syntax.

6.3.  Message-ID

   The IM Sender MUST include the Message-ID header field in the IM that
   he wishes to receive an IMDN on.  The Message-ID contains a globally
   unique message identifier the IM Sender can use to correlate received
   IMDNs.  Because the Message-ID is used by the sender to correlate
   IMDNs with their respective IMs, the Message-ID MUST be selected so
   that:

   o  There is a minimal chance of any two Message-IDs accidentally
      colliding within the time period within which an IMDN might be
      received.
   o  It is prohibitive for an attacker who has seen one or more valid
      Message-IDs to generate additional valid Message-IDs.

   The first requirement is a correctness requirement to ensure correct
   matching by the sender.  The second requirement prevents off-path
   attackers from forging IMDNs.  In order to meet both of these
   requirements, it is RECOMMENDED that Message-IDs be generated using a
   cryptographically secure pseudorandom number generator and contain at
   least 64 bits of randomness, thus reducing the chance of a successful
   guessing attack to n/2^64, where n is the number of outstanding valid
   messages.

   When the IM Sender receives an IMDN, it can compare its value with
   the value of the <message-id> element present in the IMDN payload.
   IMDNs also carry this header field.  Note that since the IMDN is



Burger & Khartabil        Expires June 12, 2009                 [Page 8]

Internet-Draft                    IMDN                     December 2008


   itself an IM, the Message-ID of the IMDN will be different than the
   Message-ID of the original IM.  Section 10 defines the syntax.

6.4.  Original-To

   An intermediary MAY insert an Original-To header field to the IM.
   The value of the Original-To field MUST be the address of the IM
   Receiver.  The IM Recipient uses this header to indicate the original
   IM address in the IMDNs.  The IM Recipient does this by populating
   the <original-recipient-uri> element in the IMDN.  The intermediary
   MUST insert this header if the intermediary changes the CPIM To
   header field value.  The header field MUST NOT appear more than once
   in an IM.  The intermediary MUST NOT change this header field value
   if it is already present.  Section 10 defines the syntax.

6.5.  IMDN-Record-Route

   An intermediary MAY insert an IMDN-Record-Route header field to the
   IM.  This enables the intermediary to receive and process the IMDN on
   its way back to the IM Sender.  The value of the IMDN-Record-Route
   header field MUST be the address of the intermediary.  Multiple IMDN-
   Record-Route header fields can appear in an IM.  Section 10 defines
   the syntax.

6.6.  IMDN-Route

   The IMDN-Route header field provides routing information by including
   one or more addresses where to route the IMDN.  An intermediary that
   needs the IMDN to flow back through the same intermediary MUST add
   the IMDN-Record-Route header.  When the IM Recipient creates the
   corresponding IMDN, the IM Recipient copies the IMDN-Record-Route
   headers into corresponding IMDN-Route header fields.  Section 10
   defines the syntax.


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
   [RFC3862].

7.1.1.1.  Adding a Message-ID Header Field

   If the IM sender requests the reception of IMDNs, the IM sender MUST
   include a Message-ID header field.  This header field enables the IM



Burger & Khartabil        Expires June 12, 2009                 [Page 9]

Internet-Draft                    IMDN                     December 2008


   Sender to match any IMDNs with their corresponding IMs.  See
   Section 6.3 for Message-ID uniqueness requirements.

7.1.1.2.  Adding a DateTime Header Field

   Some devices are not able to retain state over long periods.  For
   example, mobile devices may have memory limits or battery limits.
   These limits may mean these devices may not be able to, or may chose
   not to, keep sent messages for the purposes of correlating IMDNs with
   sent IMs.  To make some use of IMDN in this case, we add a time stamp
   to the IM to indicate when the user sent the message.  The IMDN
   returns this time stamp to enable the user to correlate the IM with
   the IMDN at the human level.  We use the DateTime CPIM header field
   for this purpose.  Thus, if the IM Sender would like an IMDN, the IM
   Sender MUST include the DateTime CPIM header field.

7.1.1.3.  Adding a Disposition-Notification 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 display.  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".  The IM Send can request both types of
   delivery notifications 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 display notification.  The IM Sender
   MUST include a Disposition-Notification header field with the value
   "display" to request a display IMDN.

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

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

   Section 10 describes the formal syntax for the Disposition-
   Notification header field.  The following is an example CPIM body of
   an IM where the IM Sender requests positive and negative delivery



Burger & Khartabil        Expires June 12, 2009                [Page 10]

Internet-Draft                    IMDN                     December 2008


   notifications, but neither display notification nor processing
   notifications:

   From: Alice <im:alice@example.com>
   To: Bob <im:bob@example.com>
   NS: 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.

   An IM Sender can determine an IMDN is a disposition notification by
   noting the Content-Disposition in the IMDN is "notification".  This
   does mean the IM Sender MUST understand the Content-Disposition MIME
   header in CPIM messages.

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.  A unique Message-ID for this purpose proves to be



Burger & Khartabil        Expires June 12, 2009                [Page 11]

Internet-Draft                    IMDN                     December 2008


   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, for example, the
   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, so the time between the
   sending of an IM and the generation and ultimate receipt of the 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
   [I-D.ietf-sip-uri-list-message]) and request IMDNs.  An IM Sender
   that requested IMDNs MUST be prepared to receive multiple aggregated
   or non-aggregated IMDNs.  See Section 8.3 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 the recipient needs
   to generate an IMDN for that IM.  Disposition-Notification header
   fields of CPIM messages can include one or more values.  IM
   recipients may need to generate zero, one, or more IMDNs for that IM,
   for example a delivery notification as well as a display
   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.  That is, it must not
   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



Burger & Khartabil        Expires June 12, 2009                [Page 12]

Internet-Draft                    IMDN                     December 2008


   successfully delivered, then no IMDNs will be generated.  If the IM
   recipient does not understand a value of the Disposition-Notification
   header field, the IM recipient ignores that value.

   The IM Recipient MUST NOT generate "processing" notifications.

   A Disposition-Notification header field MUST NOT appear in an IMDN
   since it is forbidden to request an IMDN for an IMDN.  An IM Sender
   MUST ignore a delivery notification request in an IMDN if present.
   The IM Sender MUST NOT send an IMDN for 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 an 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 MUST NOT be placed in an IMDN.
   IMDN Recipients MUST ignore it if present.

   If there is no IMDN-Record-Route header field, the IM Recipient MUST
   send the IMDN to the URI in the From header field.

   As stated in CPIM [RFC3862], CPIM messages may need to support MIME
   headers other than Content-type.  IM Recipients MUST insert a
   Content-Disposition header field, 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

   The IM Recipient constructs a delivery notification in a similar
   fashion as an IM, using a CPIM body [RFC3862] 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".

   Section 10 defines the schema for an IMDN.

   An example CPIM body of IMDN looks like the following:






Burger & Khartabil        Expires June 12, 2009                [Page 13]

Internet-Draft                    IMDN                     December 2008


   From: Bob <im:bob@example.com>
   To: Alice <im:alice@example.com>
   NS: 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 xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-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>
         <delivery-notification>
            <status>
               <delivered/>
            </status>
         </delivery-notification>
       </imdn>

7.2.1.2.  Constructing Display Notifications

   The IM Recipient constructs a display notification in a similar
   fashion as the delivery notification.  See Section 7.2.1.1 for
   details.

   Section 10 defines the schema for an IMDN.

   An example looks like the following:




















Burger & Khartabil        Expires June 12, 2009                [Page 14]

Internet-Draft                    IMDN                     December 2008


   From: Bob <im:bob@example.com>
   To: Alice <im:alice@example.com>
   NS: 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 xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-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>
         <display-notification>
            <status>
               <displayed/>
            </status>
         </display-notification>
       </imdn>

   There are situations where the IM Recipient cannot determine if or
   when the IM has been displayed.  The IM Recipient in this case
   generates a display 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
   IM recipient may not wish to let a sender know if a particular
   message has been displayed to her or not.  This could be on a per-
   message, per-sender, or programmed policy choice.


8.  Intermediary Behaviour

   In this context, intermediaries are application servers (including
   URI-List servers and Store-and-Forward server) and gateways.  A
   gateway is a server that 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
   that it sends to the list members (see
   [I-D.ietf-sip-uri-list-message] for details).  In this case, if the
   IM Sender is requesting an IMDN, the intermediary SHOULD 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.  That is,
   the intermediary populates the Original-To header field with the
   intermediary address.  Of course, one may configure an intermediary



Burger & Khartabil        Expires June 12, 2009                [Page 15]

Internet-Draft                    IMDN                     December 2008


   to restrict it from rewriting or populating the Original-To field.
   An intermediary MUST NOT add an Original-To header field if one
   already exists.  An intermediary MAY have an administrative
   configuration to not reveal the original Request-URI, and as such,
   MUST NOT add an Original-To header.

   An IM reply for a page-mode IM is not linked in any way to the
   initial IM and can end up at a diffent user agent from where the
   initial IM originated, depending on how the recipient URI gets
   resolved.  Therefore, IM replies may traverse different
   intermediaries.  An IMDN, on the other hand, needs to traverse the
   same intermediares as the IM itself since those intermediares may be
   required to report negative delivery notifications if the IM was not
   delivered successfully.  Some of those interdemiaries are, for
   example, store-and-forward servers that may report that an IM has
   been processed and later report that the IM has failed to be
   delivered.

   For the reasons stated above, 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.  The value of this field MUST be the intermediary's 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 removes that value and forwards the IMDN to the address
   indicated in the now top IMDN-Route header field.  If no additional
   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".




Burger & Khartabil        Expires June 12, 2009                [Page 16]

Internet-Draft                    IMDN                     December 2008


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

   An intermediary constructs a "processing" notification 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: ...

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-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>
         <processing-notification>
            <status>
               <processed/>
            </status>
         </processing-notification>
       </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.  Constructing Delivery Notifications

   Intermediaries MAY construct negative delivery notifications.  They
   do so only if the IM Sender has requested a "negative-delivery"
   notification by including a Disposition-Notification header field
   with value "negative-delivery" AND an error was returned for that IM.

   The intermediary can create and send "negative-delivery"
   notifications indicating that an IM has failed to be delivered.  The



Burger & Khartabil        Expires June 12, 2009                [Page 17]

Internet-Draft                    IMDN                     December 2008


   intermediary MUST NOT send more than one IMDN for the same
   disposition type.  I.e., it must not send a "failed" notification
   indicating that an IM has failed followed by another IMDN indicating
   that an IMDN is "forbidden".

   An intermediary constructs a "negative-delivery" notification much
   like the IM Recipient.  See Section 7.2.1.1 for details.

8.3.  Aggregation of IMDNs

   As previously described, URI-List servers are intermediaries.

   A URI-List server 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 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
   "displayed" 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 display 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 the references to timers in the above paragraphs are not
   normative and are only present to help describe one way one might
   implement aggregation.

   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 individual ones or visa versa.  A timer firing so 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



Burger & Khartabil        Expires June 12, 2009                [Page 18]

Internet-Draft                    IMDN                     December 2008


   individual payloads.

   Below is an 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 xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-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>
         <delivery-notification>
            <status>
               <delivered/>
            </status>
         </delivery-notification>
       </imdn>

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

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-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>
         <display-notification>
            <status>
               <displayed/>
            </status>
         </display-notification>
       </imdn>

   --imdn-boundary



Burger & Khartabil        Expires June 12, 2009                [Page 19]

Internet-Draft                    IMDN                     December 2008


9.  Identifying Messages

   Messages are typically carried in a transport protocol like SIP
   [RFC3261].  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 the Content-type
   header field present has a value of "message/imdn+xml", the Content-
   Disposition header field has a value of "notification", and the
   <delivery-notification> element appears in that xml body.

   A message is identified as a processing notification or display
   notification in a similar fashion as a delivery notification.  The
   difference is that for a processing notification, the <processing-
   notification> element appears in the xml body.  For a display
   notification, the <display-notification> element appears in the xml
   body.


10.  Header Fields Formal Syntax

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

   Header field syntax is described without a name space qualification.
   Following the rules in RFC 3862 [RFC3862], 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.

















Burger & Khartabil        Expires June 12, 2009                [Page 20]

Internet-Draft                    IMDN                     December 2008


   Disposition-Notification =
       "Disposition-Notification" ": "
       [(notify-req *(COMMA notify-req))]

   notify-req =
       ("negative-delivery" / "positive-delivery" /
        "processing" / "display" / Token) *(SEMI disp-notify-params)

   disp-notify-params = Ext-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 ">"

   SEMI    =  *SP ";" *SP ; semicolon

   COMMA   =  *SP "," *SP ; comma




11.  IMDN Format

11.1.  Structure of XML-Encoded IMDN Payload

   An IMDN Payload is an XML document [XML] 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 schema allows qualified extension elements in several positions
   other than the "urn:ietf:params:xml:ns:imdn" namespace.  To maintain
   forwards compatibility (newer instance documents can be used by
   existing consumers) the new specifications MUST NOT extend the
   allowable content of this specification.  The backwards compatibility
   (existing instance documents can also be used by updated new
   consumers) MAY break if there are conflicts with the existing
   qualified names of extension elements and possible new
   specifications.  The IETF MAY specify new extension elements within
   the "sub-namespace" of "urn:ietf:params:xml:ns:" for this message/
   imdn+xml MIME type.




Burger & Khartabil        Expires June 12, 2009                [Page 21]

Internet-Draft                    IMDN                     December 2008


   Possible future specifications can add new element definitions with
   the combine="interleave" pattern.  When multiple elements of this new
   type are then allowed, the new definition MUST contain the
   <zeroOrMore> cardinality rule.  If the new specification does allow
   only a single new element, the <optional> cardinality rule MUST be
   used.  These cardinality requirements maintain the backwards
   compatibility of existing instance documents with newer consumers.
   Also the new specification MUST then re-define either the "anyIMDN"
   extension, or the individual extension points which reference it, so
   that new element definitions do not match with this redefined, and
   more limited wildcard pattern.

   The name space identifier for elements defined by this specification
   is a URN [URN], using the name space identifier 'ietf' defined by
   [URN_NS] and extended by [IANA].  This urn is:
   urn:ietf:params:xml:ns:imdn.

   This name space declaration indicates the name space 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>, and one of <delivery-notification>,
   <processing-notification> or <display-notification>.  A <status> also
   appears as a sub-element of <delivery-notification>, <processing-
   notification> and <display-notification>.  The elements are described
   in details in the following sections.

   <imdn>, can be extended in the future to include new disposition
   notification types or other elements, as described in Section 11.1.9.

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.



Burger & Khartabil        Expires June 12, 2009                [Page 22]

Internet-Draft                    IMDN                     December 2008


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.  If present it MUST cary the text
   and, if present, language attribute, that was in the Subject header
   field, if any.  This allows for a human level correlation between an
   IM and an IMDN.  If there are more than one Subject header fields in
   an IM, selecting any one of them to place in the IMDN payload
   <subject> element will suffice.  The sender then needs to compare
   Subject header fields until a match or not match is determined.

11.1.6.  The <delivery-notification>, <processing-notification> and
         <display-notification> Elements

   The appearance of one of the <delivery-notification>, <processing-
   notification> and <display-notification> elements is mandatory and
   carries the disposition type that the IM Sender requested and is
   being reported.  It carries the sub-element <status>.

11.1.7.  The <status> Element

   The <status> element is mandatory and carries the result of the
   disposition request.  For notification type <delivery-notification>,
   it can carry one of the sub-elements <delivered>, <failed>,
   <forbidden> or <error>.  For notification type <display-
   notification>, it can carry one of the sub-elements <displayed>,
   <forbidden> or <error>.  For notification type <processing-
   notification>, 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 be
   extended to carry any other status extension.

11.1.8.  MIME Type for IMDN 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.1.9.  The RelaxNG Schema

<?xml version="1.0" encoding="UTF-8"?>
     <grammar



Burger & Khartabil        Expires June 12, 2009                [Page 23]

Internet-Draft                    IMDN                     December 2008


       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>
                     <optional>
                         <element name="subject">
                             <data type="string"/>
                         </element>
                     </optional>
                 </optional>
                 <choice>
                     <ref name="deliveryNotification"/>
                     <ref name="displayNotification"/>
                     <ref name="processingNotification"/>
                     <empty/>
                 </choice>
                 <ref name="imdnExtension"/>
             </element>
         </start>

         <define name="deliveryNotification">
             <element name="delivery-notification">
                 <element name="status">
                     <choice>
                         <element name="delivered">
                             <empty/>
                         </element>
                         <element name="failed">
                             <empty/>
                         </element>
                         <ref name="commonDispositionStatus"></ref>
                     </choice>



Burger & Khartabil        Expires June 12, 2009                [Page 24]

Internet-Draft                    IMDN                     December 2008


                     <ref name="deliveryExtension"/>
                   </element>
              </element>
         </define>

         <define name="displayNotification">
             <element name="display-notification">
                 <element name="status">
                     <choice>
                         <element name="displayed">
                             <empty/>
                         </element>
                         <ref name="commonDispositionStatus"></ref>
                     </choice>
                     <ref name="displayExtension"/>
                 </element>
             </element>
         </define>

         <define name="processingNotification">
             <element name="processing-notification">
                 <element name="status">
                     <choice>
                         <element name="processed">
                             <empty/>
                         </element>
                         <element name="stored">
                             <empty/>
                         </element>
                         <ref name="commonDispositionStatus"></ref>
                     </choice>
                     <ref name="processingExtension"/>
                  </element>
             </element>
         </define>

         <define name="commonDispositionStatus">
             <choice>
                 <element name="forbidden">
                     <empty/>
                 </element>
                 <element name="error">
                     <empty/>
                 </element>
             </choice>
         </define>

         <!-- <imdn> extension point for the extension schemas to add



Burger & Khartabil        Expires June 12, 2009                [Page 25]

Internet-Draft                    IMDN                     December 2008


              new definitions with the combine="interleave" pattern.
              Extension schemas should add proper cardinalities,
              i.e. <zeroOrMore> enclosed e.g. with the new element
              if multiple new elements are allowed, and <optional>
              if a single new element is allowed -->
         <define name="imdnExtension">
             <zeroOrMore>
                 <ref name="anyIMDN"/>
             </zeroOrMore>
         </define>

         <!-- delivery-notification <status> extension point -->
         <define name="deliveryExtension">
             <zeroOrMore>
                 <ref name="anyIMDN"/>
             </zeroOrMore>
         </define>

         <!-- display-notification <status> extension point -->
         <define name="displayExtension">
             <zeroOrMore>
                 <ref name="anyIMDN"/>
             </zeroOrMore>
         </define>

         <!-- processing-notification <status> extension point -->
         <define name="processingExtension">
             <zeroOrMore>
                 <ref name="anyIMDN"/>
             </zeroOrMore>
         </define>

         <!-- wildcard definition for complex elements (of mixed type)
              unqualified or qualified in the imdn namespace.
              Extension schemas MUST redefine this or the
              individual previous definitions which use this definition.
              In other words, the extension schema MUST reduce the
              allowable content in order to maintain deterministic
              and unambiquous schemas with the interleave pattern. -->
         <define name="anyIMDN">
             <element>
                 <anyName>
                     <except>
                         <nsName ns="urn:ietf:params:xml:ns:imdn"/>
                         <nsName ns=""/>
                     </except>
                 </anyName>
                 <ref name="anyExtension"/>



Burger & Khartabil        Expires June 12, 2009                [Page 26]

Internet-Draft                    IMDN                     December 2008


             </element>
         </define>

        <!-- the rest of the "anyIMDN" wildcard definition -->
         <define name="anyExtension">
             <zeroOrMore>
                <choice>
                    <attribute>
                       <anyName/>
                    </attribute>
                    <ref name="any"/>
                </choice>
             </zeroOrMore>
         </define>

         <!-- wildcard type for complex elements (of mixed type)
              without any namespace or content restrictions -->
         <define name="any">
             <element>
                 <anyName/>
                 <zeroOrMore>
                    <choice>
                       <attribute>
                          <anyName/>
                       </attribute>
                       <text/>
                       <ref name="any"/>
                    </choice>
                 </zeroOrMore>
             </element>
         </define>

    </grammar>



12.  Transporting Messages using SIP

12.1.  Endpoint Behaviour

12.1.1.  Sending Requests

   The IM Sender constructs a SIP MESSAGE request using RFC 3428
   [RFC3428].  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" [RFC3862] for both
   IMs and IMDNs.  The IM Sender constructs the payload according to
   Section 7.



Burger & Khartabil        Expires June 12, 2009                [Page 27]

Internet-Draft                    IMDN                     December 2008


   The IM Sender constructs a SIP MESSAGE request to multiple recipients
   in a similar manner as a SIP MESSAGE request to a single recipient.
   Multiple-Recipient MESSAGE Requests in SIP
   [I-D.ietf-sip-uri-list-message] describes the differences.

   IM senders can remain anonymous.  For example, the sender can set the
   SIP From header field of the SIP message to an anonymous URI.  As
   there is no return address, anonymous IM senders SHOULD NOT request
   disposition notifications.  An IM Recipient MAY ignore such request
   if the IM Sender is anonymous.

12.1.2.  Sending Responses

   An endpoint receiving a SIP MESSAGE request constructs a SIP response
   according to RFC 3428 [RFC3428].  Of course, an endpoint will send a
   SIP response to the MESSAGE request regardless of the 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 the final recipient received the IM.
   The IM Recipient constructs a positive-delivery notification
   according to Section 7.2.1.1.  The IM Recipient places the message 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 an error response from downstream or before
   any internal timers fire waiting for a response).  The 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



Burger & Khartabil        Expires June 12, 2009                [Page 28]

Internet-Draft                    IMDN                     December 2008


   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 display notification, and that IM Recipient has
   constructed and sent a SIP 2xx class response, it MAY generate a
   display notification after making sure that the IM has been presented
   to the user or application.  It is outside the scope of this document
   how a determination can be made whether the IM has been read.  Note
   that the option to send a display notification or not can be left to
   the user.  An application may allow a user to configure such choice.
   The IM Recipient constructs the display notification according to
   Section 7.2.1.2.  The IM Recipient places the message as the payload
   in a SIP MESSAGE request.

   For IMDNs, the IM Recipient populates the SIP Request-URI and the SIP
   To header field using the address that appeared in the SIP From
   header 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.  Display Notification

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

12.2.  Intermediary Behaviour

   In this context, intermediaries include application servers,
   including URI-List servers, Store-and-Forward servers, and gateways.
   SIP Proxies MUST NOT generate IMDNs but MUST forward them like any
   other SIP request.

   Intermediaries forward a SIP MESSAGE request to multiple recipients
   according to [I-D.ietf-sip-uri-list-message].

   If an intermediary receives an IM, the intermediary examines the
   body.  If the body is of type "message/cpim" the intermediary then
   looks for a Disposition-Notification CPIM header field in the
   message.  If the Disposition-Notification CPIM header field has
   either the value "positive-delivery" or "negative-delivery", and, in
   processing the IM, the intermediary generates a SIP 2xx class
   response to the MESSAGE request, then the intermediary performs the
   following actions.




Burger & Khartabil        Expires June 12, 2009                [Page 29]

Internet-Draft                    IMDN                     December 2008


   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.
   Just because a downstream entity received a MESSAGE request does not
   mean the message was relayed to its ultimate destination or was
   delivered.  Thus, the intermediary cannot say delivery occurred just
   because it received a 2xx response.

   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
   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 display notification, it forwards it using
   the rules in Section 8.


13.  Transporting Messages using MSRP

   MSRP [RFC4975] already provides a built-in mechanism to supply
   positive and negative delivery reports.  These reports do not provide
   built-in Display or Processing notifications.  However, these
   notifications in session mode are not as useful as they are for page-
   mode.  This is because the base use case for MSRP is that the
   recipient user agent immediately renders SEND requests sequentially,
   providing the session experience.  This is unlike page-mode requests
   where a user has to actively initiate the display of the message.
   That is, they need to click on a button, open a message, and so on to
   read the message.

   If new requirements arise in the future determining the need for IMDN
   in MSRP, new specifications can be drafted.




Burger & Khartabil        Expires June 12, 2009                [Page 30]

Internet-Draft                    IMDN                     December 2008


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 the IM transport protocol carries the IMDN, 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 an IM Sender with IMDNs by
      convincing a URI-List server to send IMDNs to an unsuspecting IM
      Sender.
   o  A malicious intermediary or node attempts to flood a target node
      with IMDNs by inserting the target's address in the From field or
      IMDN-Record-Route field
   o  A malicious node in the network that attempts to modify an IMDN
      from an 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 discover 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



Burger & Khartabil        Expires June 12, 2009                [Page 31]

Internet-Draft                    IMDN                     December 2008


      to make it appear that the IM was displayed to the user read later
      than it 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 an IM Recipient's
      IMDN would also serve the purpose of detecting an 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.
      Signing the IMDN provides integrity protection.  While an
      intermediary can replace the IMDN body, the IM Sender (the
      recipient of the IMDN) can validate the signature and note the
      IMDN does not come directly from the IM Receiver.  This is not a
      problem if the IM Sender trusts the intermediary.  Likewise, an
      IMDN in response to a signed IM without a signature indicates
      something bad might have happened.
   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 accessing the IM
   Sender's public certificate in order to verify the signature in the
   IM.

   CPIM security considerations [RFC3862] apply here, as this is an
   extension of CPIM.  In order to make the IMDN mechanism independent
   of the transport protocol, the Work Group made the design choice of
   putting routing information into the IMDN application layer payload.
   One consequence of this choice is it eliminates the possibility of
   having end-to-end encryption.

   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.

   One way to address the potential for a malicious node to use the IMDN
   system to anonomize attacks is to log all IMDN requests on the IM



Burger & Khartabil        Expires June 12, 2009                [Page 32]

Internet-Draft                    IMDN                     December 2008


   Recipient User Agent.  This allows for tracking of attacks, if only
   after they occur.  Note this also puts a burden on the IM Recipient
   User Agent host.  Limited User Agents may not be able to preserve
   much of a log.

   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, display notification
   could be forged to indicate that an IM has been displayed to the
   Recipient.  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 whose member information is not disclosed.  In this situation,
   the user will learn of the list members.  Therefore, in this case,



Burger & Khartabil        Expires June 12, 2009                [Page 33]

Internet-Draft                    IMDN                     December 2008


   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.

   It is possible for a list server to not understand IMDN.  IM
   Recipients may note the To header field is a list name and not the IM
   Recipient's name.  In this case, the IM Recipient can take the
   appropriate action if it wishes to keep its identity private.

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

14.3.  IMDN as a Certified Delivery Service

   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.  Moreover, the IM Recipient may bypass the IMDN
   issuing mechanism through policy or manipulation of their User Agent
   Server.


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 name space.

   This specification follows the guidelines of RFC 3023 [RFC3023].

   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 [RFC3023].

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

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




Burger & Khartabil        Expires June 12, 2009                [Page 34]

Internet-Draft                    IMDN                     December 2008


   Interoperability considerations: none.

   Published specification: This document.

   Applications which use this media type: This document type is used to
   support 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@gmail.com)

   Intended Usage: COMMON

   Author/change controller: The IETF .

15.2.  XML Registration

   This section registers a new XML name space and schema, as per
   guidelines in the IETF XML Registry [IANA].

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

   XML: The schema for this name space is in Section 11.1.9 above.

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

15.3.  Registration for urn:ietf:params:imdn

   Registry name: imdn

   Specification: RFC XXXX.  Additional values may be defined by a
   Standards Action [RFC2434] that updates or obsoletes RFC XXXX.

   Repository: [RFC EDITOR: fill in by IANA]

   Index value: The index value is a CPIM message IMDN header 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:



Burger & Khartabil        Expires June 12, 2009                [Page 35]

Internet-Draft                    IMDN                     December 2008


      a) replacing any non-URN characters (as defined by RFC 2141[URN])
      with the corresponding '%hh' escape sequence (per RFC 3986
      [RFC2396]); 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'.

   Initial values;

                                (preamble)

            +--------------------------+---------------------+
            | Index Value              | Reference           |
            +--------------------------+---------------------+
            | Disposition-Notification | RFCXXXX Section 6.2 |
            | Message-ID               | RFCXXX Section 6.3  |
            | Original-To              | RFCXXX Section 6.4  |
            | IMDN-Record-Route        | RFCXXX Section 6.5  |
            | IMDN-Route               | RFCXXX Section 6.6  |
            +--------------------------+---------------------+

                                (postamble)

15.4.  Content-Disposition: notification

   This document registers one new Content-Disposition header field
   "disposition-types": notification.  The authors request that this
   value be recorded in the IANA registry for Mail 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

   Special thanks to Jari Urpalainen for the thorough review and
   suggestions for the RelaxNG Schema.

   The authors would also like to thank Paul Kyzivat, Ben Campbell, Adam
   Roach, Gonzalo Camarillo, Frank Ellermann, Sean Olson, Eva Leppanen,



Burger & Khartabil        Expires June 12, 2009                [Page 36]

Internet-Draft                    IMDN                     December 2008


   Miguel Garcia, Eric McMurry, Jon Peterson, and Robert Sparks for
   their comments and support.  In addition, we would like to thank the
   Gen-Art reviewer extrodinaire, Spencer Dawkins.


17.  References

17.1.  Normative References

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

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

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

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

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

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

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

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

17.2.  Informative References

   [RFC3261]  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.

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

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

   [RFC3798]  Hansen, T. and G. Vaudreuil, "Message Disposition
              Notification", RFC 3798, May 2004.



Burger & Khartabil        Expires June 12, 2009                [Page 37]

Internet-Draft                    IMDN                     December 2008


   [RFC4975]  Campbell, B., Mahy, R., and C. Jennings, "The Message
              Session Relay Protocol (MSRP)", RFC 4975, September 2007.

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

   [I-D.ietf-sip-uri-list-message]
              Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
              MESSAGE Requests in the Session Initiation Protocol
              (SIP)", draft-ietf-sip-uri-list-message-03 (work in
              progress), December 2007.


Authors' Addresses

   Eric Burger
   New Hampshire
   USA

   Phone:
   Fax:   +1 603 457 5933
   Email: eburger@standardstrack.com


   Hisham Khartabil
   Ericsson Australia
   Melbourne
   Australia

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




















Burger & Khartabil        Expires June 12, 2009                [Page 38]

Internet-Draft                    IMDN                     December 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Burger & Khartabil        Expires June 12, 2009                [Page 39]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/