SIMPLE                                                         E. Burger
Internet-Draft                                        Cantata Technology
Expires: November 27, 2006
Intended status: Informational                              H. Khartabil
Expires: April 16, 2007                                            Telio
                                                            May 26,
                                                        October 13, 2006

                Instant Message Disposition Notification
                       draft-ietf-simple-imdn-00
                       draft-ietf-simple-imdn-01

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 November 27, 2006. April 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Instant Messaging (IM) refers to the transfer of messages between
   users in real-time.  This document extends Message/CPIM message format to enable provides a mechanism whereby
   endpoints
   to request, create and send IM can request Instant Message Disposition Notifications
   (IMDN), including delivery delivery, processing and read notifications, for
   page-mode as well as session mode instant messages.

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

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overview . .  4
     3.1.  Disposition States . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  delivered . . . . .  5
   5.  Disposition Types  . . . . . . . . . . . . . . . . .  5
       3.1.2.  read . . . . .  6
     5.1.  Delivery . . . . . . . . . . . . . . . . . . . .  5
   4.  Endpoints Behaviour . . . . .  6
     5.2.  Processing . . . . . . . . . . . . . . . .  5
     4.1.  Constructing Instant Messages . . . . . . . .  7
     5.3.  Read . . . . . .  5
     4.2.  Constructing IMDNs . . . . . . . . . . . . . . . . . . . .  6
       4.2.1.  Constructing Delivery Notification .  7
   6.  New CPIM Header Fields . . . . . . . . .  7
       4.2.2.  Constructing Read Notification . . . . . . . . . . .  7
     6.1.  CPIM Header Namespace  .  8
     4.3.  Aggregation of IMDNs . . . . . . . . . . . . . . . . .  7
     6.2.  Disposition-Notification . .  8
     4.4.  Keeping State . . . . . . . . . . . . . . .  8
     6.3.  Message-ID . . . . . . .  9
   5.  Intermediary Behaviour . . . . . . . . . . . . . . . . .  8
     6.4.  Original-To  . . .  9
     5.1.  Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 10
   6.  Identifying Messages .  8
     6.5.  IMDN-Record-Route  . . . . . . . . . . . . . . . . . . . . 11
   7.  Header Fields  8
     6.6.  IMDN-Route . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  CPIM Header Namespace  8
   7.  Endpoint Behaviour . . . . . . . . . . . . . . . . . . 11
     7.2.  Disposition-Notification . . . .  9
     7.1.  IM Sender  . . . . . . . . . . . . . . . . 12
     7.3.  Message-ID . . . . . . . .  9
       7.1.1.  Constructing Instant Messages  . . . . . . . . . . . .  9
       7.1.2.  Matching IMs with IMDNs  . . . . . 12
     7.4.  Original-To . . . . . . . . . . 10
       7.1.3.  Aggregation of IMDNs . . . . . . . . . . . . . 12
     7.5.  Really-From . . . . 10
       7.1.4.  Keeping State  . . . . . . . . . . . . . . . . . . . 12
     7.6.  Really-To . 11
     7.2.  IM Recipient . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Header Fields Formal Syntax
       7.2.1.  Constructing IMDNs . . . . . . . . . . . . . . . . . . 12
   9.  IMDN Format
   8.  Intermediary Behaviour . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Constructing Processing Notifications  . . . . . 13
     9.1.  Structure of XML-Encoded imdn . . . . . 15
     8.2.  Aggregation of IMDNs . . . . . . . . . 13
       9.1.1.  The <message-id> Element . . . . . . . . . . 16
   9.  Identifying Messages . . . . . 13
       9.1.2.  The <datetime> Element . . . . . . . . . . . . . . . . 13
       9.1.3.  The <recipient-uri>; Element 17
   10. Header Fields Formal Syntax  . . . . . . . . . . . . . 14
       9.1.4.  The <original-recipient-uri>; Element . . . . 17
   11. IMDN Format  . . . . . 14
       9.1.5.  The <subject>; Element . . . . . . . . . . . . . . . . 14
       9.1.6.  The <disposition> Element . . . . 18
     11.1. Structure of XML-Encoded IMDN Payload  . . . . . . . . . . 14
       9.1.7. 18
       11.1.1. The <status> <message-id> Element . . . . . . . . . . . . . . . . . 14
       9.1.8. 18
       11.1.2. The <note> <datetime> Element . . . . . . . . . . . . . . . . 19
       11.1.3. The <recipient-uri> Element  . . 14
     9.2. . . . . . . . . . . . 19
       11.1.4. The <original-recipient-uri> Element . . . . . . . . . 19
       11.1.5. The <subject> Element  . . . . . . . . . . . . . . . . 19
       11.1.6. The <disposition> Element  . . . . . . . . . . . . . . 19
       11.1.7. The <status> Element . . . . . . . . . . . . . . . . . 19
       11.1.8. The <note> Element . . . . . . . . . . . . . . . . . . 20
     11.2. MIME Type for imdn Document IMDN Paylaod . . . . . . . . . . . . . . . 14
     9.3. . 20
     11.3. The XML RelaxNG Schema . . . . . . . . . . . . . . . . . . . . . . 15
   10. 20
   12. Transporting Message/CPIM messages Messages using SIP  . . . . . . . . . 15
     10.1. . . . . . . 23
     12.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 15
       10.1.1. 24
       12.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 15
       10.1.2. 24
       12.1.2. Sending Responses  . . . . . . . . . . . . . . . . . . 15
       10.1.3. 24
       12.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 15
     10.2. 24
     12.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 16
   11. 25
   13. Transporting Message/CPIM messages Messages using MSRP . . . . . . . . 17
     11.1. . . . . . . . 26
     13.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 17
       11.1.1. 26
       13.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 17
       11.1.2. 26
       13.1.2. Sending Responses  . . . . . . . . . . . . . . . . . . 18
       11.1.3. 27
       13.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 18
     11.2. 27
     13.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 18
   12. 27
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     12.1. 28
     14.1. Forgery  . . . . . . . . . . . . . . . . . . . . . . . . . 21
     12.2. 30
     14.2. Confidentiality  . . . . . . . . . . . . . . . . . . . . . 21
     12.3. 30
     14.3. Non-Repudiation  . . . . . . . . . . . . . . . . . . . . . 22
   13. 31
   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
     13.1. 31
     15.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 22
     13.2. 31
     15.2. URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:imdn  . . . . . . . . . . . . . . . 23
     13.3. 32
     15.3. Schema Registration  . . . . . . . . . . . . . . . . . . . 23
     13.4. 32
     15.4. Message/CPIM Header Field registration . . . . . . . . . . 23
     13.5. 32
     15.5. Content-Disposition: notification  . . . . . . . . . . . . 24
   14. 33
   16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   15. 33
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     15.1. 33
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     15.2. 33
     17.2. Informative References . . . . . . . . . . . . . . . . . . 24 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 27 35

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 [12] deals with this situation with Message Delivery
   Notifications [13].  After the recipient views the message, her mail
   user agent generates a message delivery notification, Message Delivery Notification, or MDN.  The
   MDN is an e-mail that follows the format prescribed by RFC2298 [13].
   The fixed format ensures that an automaton can process the message.

   Message/CPIM [2] is a message format used to generate instant
   messages.  SIP [9] can carry instant messages generated using
   message/CPIM in SIP MESSAGE requests [10].  The MSRP [11] SEND
   message
   request can also be used to carry Message/CPIM messages.

   This document extends Message/CPIM message format (much like Message
   Delivery Notifications [13] extends Electronic Mail [12]) to enable endpoints
   Instant Message Senders to request, create and send Instant Message
   Disposition Notifications (IMDN) for a page-mode as well as session
   mode instant messages.  IMDNs include positive delivery and read notifications as well as delivery, negative
   delivery notifications (i.e. a message did not get delivered
   successfully). successfully), read
   notifications as well as processed notifications.  By using a CPIM
   headers, 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 pager-mode. page-mode.

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

2.  Conventions

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

3.  Overview

   The basic protocol flow is as follows.  A message sender marks a
   message for disposition notification.  At a certain point in time,
   the recipient user agent  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.

   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 or XML Document: An XML document carrying the
      disposition notification information.  It is always 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: An IM or an IMDN wrapped in a
      transport protocol like SIP or MSRP.

4.  Overview

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

3.1.  Disposition States

   There are two broad categories

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

   Note that the recipient of disposition states.  They are
   delivered and read.  Future extensions may introduce others

3.1.1.  delivered

   The "delivered" state indicates whether the Recipient has received
   the instant message or not (positive or negative delivery).

3.1.2.  read

   The "read" state indicates whether the Recipient displayed the
   instant message to the user or not.

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

4.  Endpoints Behaviour

4.1.  Constructing Instant Messages

   A Message/CPIM formatted instant message is constructed using RFC
   3862 [2].  The content-type header field indicates the MIME type of
   the request payload.

   In this extension, the Message/CPIM IM MAY contain a Message-ID
   header field if an IMDN is requested.  The Message-ID field is
   populated with a value that is unique in space and time.  This header
   field enables the message sender to match any notifications with
   their corresponding IMs.  This header need not be present if the
   instant message sender is not requesting any IMDNs or if no state of
   any kind is kept for an IM.

   The recipient on an IMDN an IMDN, in some instances, may not be the same user agent that sent the
   instant message.
   IM Sender.  This is specifically true for page-mode instant
   messages IMs where the
   Address of Record (AOR) of the IM sender Sender, that is present in the IMDN
   IMDN, resolves to a different location to where the IM originated.  Also, some devices may not implement
   For simplicity, the concept rest of
   "Sent Items" box and therefore no information about an IM is stored.
   It is therefore necessary to add a time stamp in this document assumes that the IM to indicate
   when it was sent in order to enable Sender
   and the human user IMDN Recipient are the same and therefore will refer to correlate both
   as the IM with the IMDN.  This time stamp is returned in the IMDN in order
   to enable 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 user IM has been
   delivered to correlate the IM with Recipient or not.  The delivery notification type
   can have the IMDN at following states:

   o  "delivered" to indicate successful delivery.

   o  "failed" to indicate failure in delivery.

   o  "forbidden" indicate denial by the human
   level.  The message/CPIM DateTime header field is used IM Recipient for this
   purpose.  The message/CPIM the IM MUST contain a DateTime header field if Sender
      to receive the requested IMDN.

   o  "error" to indicate an IMDN is requested.

   In this specification, error in determining the sender can request two types fate of delivery
   notifications: a failure delivery notification and a success delivery
   notification.  A failure delivery an IM.

5.2.  Processing

   The processing notification is requested type indicates that an IM has been
   processed by
   including a Disposition-Notification header field with value
   "negative-delivery".  Similarly, a success an intermediary.  The processing notification is requested
   by including a Disposition-Notification header field with value
   "positive-delivery".  Both types of notifications type can be requested
   for
   have the same message.

   The sender can also request a read notification.  It following states:

   o  "processed" is requested by
   including a Disposition-Notification header field with value "read".

   The absence of this header or the presence general state of the header with empty
   value IM indicating it has been
      processed.

   o  "stored" state indicates that the sender is not requesting any IMDNs.  This
   aids receivers of instant messages that do not support this feature.
   The Disposition-Notification header fields can be comma separated.
   Future extension may define other disposition notifications not
   defined in this document.  The IM sender MAY request more than one
   kind of IMDN for a single has been stored by the
      intermediary for later delivery.

   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.

5.3.  Read

   The formal syntax of read notification type indicates whether the Disposition-Notification header field can be
   found in Section 8. IM Recipient
   displayed 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 read.

   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 example Message/CPIM instant
   message where IM.

   Since there is no positive acknowledgement from the user, one cannot
   determine a priori that the user requests positive and negative delivery
   notifications, but not actually read notification:

         Content-type: Message/CPIM

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

         Hello World

4.2.  Constructing IMDNs

   As indicated earlier, an endpoint sending an IM may choose to request
   more than the IM.  Thus one type of IMDN for a single IM, For example MUST
   NOT use the protocol described here as a delivery
   notification non-repudiation service.

6.  New CPIM Header Fields

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

6.1.  CPIM Header Namespace

   Per CPIM [2], this case specification defines a new namespace for the
   endpoint constructing IMDNs MUST CPIM
   extension headers defined in the following sections.  The namespace
   is: urn:ietf:params:cpim-headers:imdn As per CPIM [2] requirements,
   the new headers defined in the following sections are prepended by
   the string "imdn." in CPIM messages.

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 with
   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 of the address of the IM Sender.  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 is mandatory if the intermediary changes the
   CPIM To header field value.  The header 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 able to construct multiple IMDNs
   per IM.

   Disposition-Notification 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 MUST NOT fields can appear in a Message/CPIM
   message that represents an IMDN since it does not make sense and is
   therefore forbidden to request an IMDN for an IMDN.  The recipient syntax
   is defined in Section 10.

7.  Endpoint Behaviour

7.1.  IM Sender

7.1.1.  Constructing Instant Messages

   An IM is constructed using RFC 3862 [2].  The Content-type header
   field indicates the MIME type of the IMDN request payload.

7.1.1.1.  Adding a Message-ID Header Field

   If the IM sender requests the reception of IMDNs, the IM sender MUST ignore it if present.

   An IMDN SHOULD NOT contain
   include a Message-ID header field.  The Message-ID field since it is used
   for matching an instant message populated
   with its IMDNs and no IMDNs are ever
   requested for IMDNs.  The recipient a value that is unique with 32 bits of the IMDN MUST ignore the
   Message-ID randomness.  This header
   field if present.

   If Really-From header fields appear in enables the IM, IM Sender to match any IMDNs with their
   corresponding IMs.

7.1.1.2.  Adding a DateTime Header Field

   Some devices may not implement the endpoint
   constructing 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 MUST copy in order to enable the contents of user
   to correlate the Really-From
   header fields into Really-To header fields in IM with the IMDN and maintain at the order. human level.  The DateTime
   header field is used for this purpose.  The IM MUST contain a
   DateTime header field if an IMDN is then sent to the address in requested.

7.1.1.3.  Adding a Disposition-Notification Header Field

   In this specification, the top Really-To
   header field.

4.2.1.  Constructing Delivery Notification

   A IM Sender can request two types of
   delivery notifications: a failure delivery notification is constructed in and a similar fashion as an
   instant message, using RFC 3862 [2].  For success
   delivery notifications, the
   content-type MUST be of type "message/imdn+xml".  It is an XML
   document.  The schema is described Section 9.  The notification.  An IM Sender requests failure delivery
   notification MUST contain by including a Content-Disposition Disposition-Notification header field
   with value "notification".  This indicates to the receiver that the
   contents of the message are "negative-delivery".  Similarly, a success notification according to an earlier
   request is
   requested by including a Disposition-Notification header field with
   value "positive-delivery".  Both types of delivery notifications can
   be requested for an IMDN to an instant message.

   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: same IM.

   The IM Sender can request a processing notification
                 Content-length: ...

                 <imdn>
                   <message-id>34jk324j</message-id>
                   <datetime>2006-04-04T12:16:49-05:00</datetime>
                   <recipient-uri>bob@example.com</recipient-uri>
                   <original-recipient-uri>bob@example.com</original-recipient-uri>
                   <disposition>delivery</disposition>
                   <status>success</status>
                   <note lang="en">The message was successfully Delivered</note>
                 </imdn>

4.2.2.  Constructing Read Notification

   A by including a
   Disposition-Notification header field with value "processing".

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

   The absence of this header or the presence of the header with empty
   value indicates that the IM Sender is not requesting any IMDNs.  The
   Disposition-Notification header fields can be comma separated.

   Future extension may define other disposition notifications not
   defined in this document.  The IM Sender MAY request more than one
   type of IMDN for a similar fashion as single IM.

   The formal syntax of the
   delivery notification.  See Disposition-Notification header field can be
   found in Section 4.2.1 for details.

   An 10.  The following in an example looks like IM where the following: IM
   Sender requests positive and negative delivery notifications, but not
   read notification nor processing notifications:

     Content-type: Message/CPIM

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

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

   There are situations where the recipient user agent cannot determine
   if or when 12

     Hello World

7.1.2.  Matching IMs with IMDNs

   An IM Sender matches an IMDN to an IM by matching the message has been read.  The recipient user agent Message-ID
   header field value in
   this case generates a read notification the IM with a <status> the <message-id> element value in
   the body of
   "error" the IMDN.  If the IM was delivered to indicate an internal error by multiple
   recipients, the server.

4.3. IM Sender uses the <recipient-uri> element or the
   <original-recipient-uri> element in the XML body of the IMDN it
   received to identify the IM Recipient (IMDN Sender).

7.1.3.  Aggregation of IMDNs

   An endpoint IM Sender may send an instant message IM to multiple recipients in one
   transport protocol message Transport
   Protocol Message (typically using a URI-List server) and request
   IMDNs.  If it does so, it  It MAY choose to either get one IMDN from each recipient IM Recipient
   individually or get an aggregated IMDN (the URI-
   List URI-List server
   aggregates the IMDNs and send the one or more aggregated IMDN). IMDNs).  The endpoint does so
   IM Sender requests aggregation by adding the Disposition-Notification
   header field parameter "aggregate".  The absence of such a parameter
   indicates that the endpoint IM Sender does not want wish for IMDNs to be
   aggregated.  Aggregation can be done requested per IMDN requested. disposition type.  For
   example, a IM sender Sender can request delivery notification to be
   aggregated but read reports notifications to be sent individually.  For
   example:

   Disposition-Notification: positive-delivery;aggregate, read
   The following is an example of an IM Sender requesting aggregation of
   both positive delivery notifications and read notifications:

   Disposition-Notification: positive-delivery;aggregate, read;aggregate

   An endpoint IM Sender that requested an aggregated IMDN MUST be prepared to
   receive multiple aggregated or non-aggregated IMDNs.  See Section 5.1 8.2
   for details.

   An endpoint IM Sender MUST be prepared to receive aggregated IMDNs even if it
   did not request the URI-List server to do so.  See again Section 5.1 8.2
   for details.  Note that the "aggregate" parameter is a hint for
   intermediaries and does not require the intermediaries to aggregate
   IMDNs.

4.4.

7.1.4.  Keeping State

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

   Once an endpoint IM Sender sends an instant message with IM containing an IMDN request, it MAY
   preserve the message IM context, principally the Message-ID, and other user-identifiable user-
   identifiable information such as the message IM subject or content, and date
   and time it was sent.  Without preservation of the
   message IM context, the Requesting endpoint IM
   Sender will not be able to correlate the IMDN with the outbound IM. IM it sent.
   The Requesting endpoint IM Sender may find it impossible to preserve message 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 messages. IMs.  This "Sent Items" box has the necessary
   information and may have a fancy user interface indicating the state
   of a sent message. IM.  Unique Message-ID for this purpose proves to be
   useful.  How long to keep  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 a requesting endpoint an IM Sender loses its sent items state (user deletes
   items from the "Send Items" box, box), the client may use a different
   display strategy in response to apparently unsolicited
   IMDN's.

   This specification also 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.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 MUST NOT appear in an IMDN since it
   does not mandate make sense and is therefore forbidden to request an IMDN for
   an IMDN.  IM sender Sender MUST ignore it if present.  The IM Sender MUST
   NOT send an IMDN to run any
   timers waiting for an IMDN.  There are no time limits associated with
   when disposition notifications may be received.

5.  Intermediary Behaviour

   In this context, application servers (including URI-List servers and
   Store-and-Forward server) and gateways are defined as intermediaries.

   An intermediary IMDN MUST contain a Message-ID header field.  The same rules of
   uniqueness for the Message-ID header field that forwards appears in an IM
   apply to an IMDN.

   An IM may change the recipient address
   in the CPIM To contain a IMDN-Record-Route header field when forwarding (for example, a URI-List
   server change (see Section 8 for
   details).  If IMDN-Record-Route header fields appear in the recipient address from its own to IM, the address of
   IM Recipient constructing the final recipient IMDN MUST copy the contents of that message).  In this case, the intermediary
   MUST add a CPIM Original-To
   IMDN-Record-Route header to the CPIM message populating it
   with fields into IMDN-Route header fields in the address of
   IMDN and maintain the sender.

   An intermediary MAY choose order.  The IMDN is then sent to remain on the path of IMDNs for a
   specific IM.  It can do so by adding a CPIM Really-From header field
   as address in
   the top Really-From IMDN-Route header and populating it with its own address.
   This works well with intermediaries that don't support this extension
   in that IMDNs would therefore traverse directly from receiver to
   sender or to intermediaries that do support the extension.

   An intermediary receiving field.

7.2.1.1.  Constructing Delivery Notifications

   A delivery notification is constructed in a similar fashion as an IMDN checks IM,
   using RFC 3862 [2].  For delivery notifications, the top Really-To header
   field.  If that Content-type
   MUST be of type "message/imdn+xml".  It is an XML document.  The
   schema is described Section 11.  The delivery notification MUST
   contain a Content-Disposition header field carries the intermediary address, with value "notification".
   This indicates to the
   intermediary pops IM Sender that header and forwards the message is an IMDN to an IM
   it has earlier sent.

   An example looks like the address
   indicated following:

   Content-type: Message/CPIM

   From: Bob <im:bob@example.com>
   To: Alice <im:alice@example.com>
   NS: imdn <urn:ietf:params:cpim-headers:imdn>
   imdn.Message-ID: d834jied93rf
   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>
         <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 now top Really-To header.
   delivery notification.  See Section 7.2.1.1 for details.

   An intermediary MUST remove any information about example looks like the final
   recipients of a list following:

   Content-type: Message/CPIM

   From: Bob <im:bob@example.com>
   To: Alice <im:alice@example.com>
   NS: imdn <urn:ietf:params:cpim-headers:imdn>
   imdn.Message-ID: dfjkleriou432333
   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>
         <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 list membership is not disclosed. IM has been read.  The
   intermediary does that by removing the <recipient-uri> element from
   the body IM Recipient in this case generates a
   read notification with a <status> value of the IMDN before forwarding it "error" to indicate an
   internal error by the IM sender.

5.1.  Aggregation of IMDNs server.

8.  Intermediary Behaviour

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

   When a (including URI-List server receives an instant message, it needs to
   examine Disposition-Notification header fields.  If servers and
   Store-and-Forward server) and gateways are defined as intermediaries.

   An intermediary that forwards an IMDN request
   contains IM MAY change the "aggregate" parameter, recipient address
   in the CPIM To header field when forwarding (for example, a URI-List
   server MUST wait for
   a configurable period of time or until all recipients have sent changes the
   IMDN (whichever comes first) before IM Recipient address from its own to the URI-List server sends an
   aggregated IMDN.  Note address
   of the final recipient of that some IMDNs, IM for example read
   notifications, may never come due every copy it makes to user settings.  It is an
   administrator configuration and an implementation issue how long be sent
   to
   wait before sending the list members).  In this case, the intermediary MUST add an aggregated IMDN and before a URI-List server
   removes state for that IM.  A URI-List server may choose
   Original-To header field to send
   multiple aggregated IMDNs even if the requester asked for one
   aggregated IM.  A timer can be started and when IM populating it fires, with the URI-
   List server can aggregate whatever IMDNs it has so far for address
   that IM,
   send the aggregated IMDN and restart the timer for was in the next batch.
   This To header field before it was changed.  I.e.  The
   Original-To header is needed for scenarios where populated with the IM sender has requested more
   than intermediary address.  An
   intermediary MUST NOT add an Original-To header field if one IMDN already
   exists.

   An intermediary MAY choose to remain on the path of IMDNs 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
   specific IM.  It can be running do so by adding a CPIM IMDN-Record-Route header
   field as the top IMDN-Record-Route header and when populating it fires, with its
   own address.  An intermediary that does not support this extension
   will obviously not add the state of IMDN-Record-Route header.  This allows
   IMDNs to traverse directly from the IM is
   deleted.  In this case, Recipient to the URI-List server consumes any IMDNs that
   might arrive after that time.

   A URI-List server MAY aggregate IMDNs IM Sender
   even if the IM sender did traversed an intermediary not
   request from it to do so.  This is to handle supporting this
   extension.

   An intermediary receiving an IMDN checks the case where top IMDN-Route header
   field.  If that header field carries the list
   membership information is not disclosed.

   The aggregated IMDN is constructed using intermediary address, the multipart/mixed MIME
   type
   intermediary pops that header and including all forwards the received IMDNs as message/imdn+xml as
   individual payloads.

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

6.  Identifying Messages

   Message/CPIM messages are typically carried in a transport protocol
   like SIP [9].  In the case of a "message/cpim" body address
   indicated in the request of
   the transport protocol, now top IMDN-Route header.  If no IMDN-Route headers
   are present, the message IMDN is an instant message if forwarded to the
   content-type header field present address in the message/cpim body has a
   value that is NOT "message/imdn+xml".

   A Message/CPIM message is identified as a delivery notification by
   examining its contents.  In To header
   field.

   An intermediary MUST remove any information about the case final
   recipients of a message/cpim body, list if the
   message list membership is a delivery notification if: the content-type header field
   present in not disclosed.  The
   intermediary does that by removing the <recipient-uri> element and/or
   <original-recipient-uri> element from the message/cpim body has a value of "message/imdn+xml", the Content-Disposition header field has a value of "notification",
   and IMDN before
   forwarding it to the <disposition> element in IM Sender.

8.1.  Constructing Processing Notifications

   Intermediaries are the only entities that xml body construct processing
   notifications.  They do so only if the IM Sender has requested a value of
   "delivery".  An endpoint matches a delivery
   processing notification to an
   instant message by matching the Message-ID including a Disposition-Notification
   header field value with
   the <message-id> element value in the body of the delivery
   notification.  If the message was delivered to multiple recipients,
   the <recipient-uri> element "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 <original-recipient-uri> element
   in the XML body same disposition type.  I.e.
   It must not send a processing notification indicating that an IM is used to identify
   being "processed" followed by another IMDN indicating that the recipient.

   A Message/CPIM message request same
   IM is identified as a read "stored".

   A processing notification
   and is matched to an instant message constructed in a similar fashion as a 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 difference is that 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.

   When a URI-List server receives an IM, it needs to examine
   Disposition-Notification header fields.  If an IMDN request contains
   the <disposition>
   element in that xml body has "aggregate" parameter, the URI-List server MUST wait for a value
   configurable period of "read".

7.  Header Fields

7.1.  CPIM Header Namespace

   Per CPIM [2], IMDN uses a namespace for time or until all recipients have sent the CPIM headers.  The
   namespace is
   urn:ietf:params:cpim-headers:imdn

   All of
   IMDN (whichever comes first) before the header definitions in this document refer URI-List server sends an
   aggregated IMDN.  Note that some IMDNs, for example read
   notifications, may never come due to this
   namespace.

7.2.  Disposition-Notification

   The Disposition-Notification header field user settings.  It is an
   administrator configuration and an implementation issue how long to
   wait before sending an aggregated IMDN and before a Message/CPIM extension URI-List server
   removes state for that is used by the instant message sender IM.

   A URI-List server MAY choose to indicate send multiple aggregated IMDNs even
   if the request to
   receive requester asked for one aggregated IM.  A timer can be started
   and when it fires, the URI-List server can aggregate whatever IMDNs
   it has so far for that specific IM.  This header field is optional IM, send the aggregated IMDN and restart the
   timer for the next batch.  This is not needed if for scenarios where the IM sender does not request an IMDN.  The
   syntax is defined in Section 8.

7.3.  Message-ID

   The Message-ID header field is
   Sender has requested more than one IMDN for a Message/CPIM extension that is used
   by specific IM, for
   example, delivery notifications as well as read notifications, or
   when the instant message sender URI-List server is short on resources and chooses to correlate received IMDNs by
   comparing its value with
   prioritise forwarding IMs over IMDNs.  A second timer can be running
   and when it fires, the value state of the <message-id> element
   present in the IMDN payload.  This header field is optional.  The
   syntax is defined in Section 8.

7.4.  Original-To

   The Original-To header field is a Message/CPIM extension that is
   added to an IM by an intermediary.  It is used by the instant message
   recipient to indicate in deleted.  In this case, the
   URI-List server consumes any IMDNs (by populating the <original-
   recipient-uri> element) the original address that might arrive after that time.

   A URI-List server MAY aggregate IMDNs even if the IM was sent to. Sender did not
   request it to do so.  This header is mandatory if to handle the intermediary changes case where the CPIM To
   header field value.  The syntax list
   membership information is defined in Section 8.

7.5.  Really-From not disclosed.  The Really-From header field is a Message/CPIM extension that is
   added URI-List server MAY
   also choose to ignore an IM by aggregation request and send individual
   IMDNs instead.

   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 in order to indicate that it wants
   the IMDN to be sent needs to it.  The syntax is defined in generate IMDNs,
   see Section 8.
   Multiple Really-From headers can appear 12.2 for further details.

9.  Identifying Messages

   Messages are typically carried in a transport protocol like SIP [9].
   The message is an IM

7.6.  Really-To

   The Really-To if the content-type header field is present in it
   has a Message/CPIM extension value that is added
   to an IMDN by an endpoint NOT "message/imdn+xml".

   A message is identified as a delivery notification by copying the contents of te Really- From
   header that appeared in examining its
   contents.  The message is a delivery notification if: the IM.  This Content-
   type header is used by field present has a value of "message/imdn+xml", the endpoint
   Content-Disposition header field has a value of "notification", and intermediaries to route IMDNs to
   the final destination.  The
   syntax <disposition> element in that xml body has a sub-element
   <delivery>.

   A message is defined identified as a processing notification or read
   notification in Section 8.  Multiple Really-From headers can
   appear a similar fashion as a delivery notification.  The
   difference is that the <disposition> element in an IMDN.

8. that xml body has a
   sub-element of <processing> and <read> respectively.

10.  Header Fields Formal Syntax

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

   Header syntax is described without a namespace qualification.
   Following the rules in RFC3862 [2], header 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 = "aggregate" / generic-param

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

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

   Really-From

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

   Really-From

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

9.

11.  IMDN Format

9.1.

11.1.  Structure of XML-Encoded imdn IMDN Payload

   An IMDN Payload is an XML document [7] 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 documents
   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]
   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 on. 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.

9.1.1.

   <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 optional mandatory according to the XML schema and
   carries the message id that appeared in the Message-ID header field
   of the IM, if any.  This element is mandatory if the IM contained a
   Message-ID header field.

9.1.2. 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
   Message/CPIM
   DateTime header field of the IM.

9.1.3.

11.1.3.  The <recipient-uri>; <recipient-uri> Element

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

9.1.4.

11.1.4.  The <original-recipient-uri>; <original-recipient-uri> Element

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

9.1.5.

11.1.5.  The <subject>; <subject> Element

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

9.1.6.

11.1.6.  The <disposition> Element

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

9.1.7.

11.1.7.  The <status> Element

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

9.1.8.

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.

9.2.

11.2.  MIME Type for imdn Document IMDN Paylaod

   The MIME type for the imdn document is "message/imdn+xml".  The SIP
   [9] MESSAGE request [10] or the MSRP SEND request [11] that is used
   to carry for the IMDN that also carries payload type information Payload is "message/imdn+xml".  The IMDN
   MUST identify the payload as MIME type "message/imdn+xml" in the Content-
   Type
   Content-type header field.

9.3.

11.3.  The XML RelaxNG Schema

10.

<?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 Message/CPIM messages Messages using SIP

10.1.

12.1.  Endpoint Behaviour

10.1.1.

12.1.1.  Sending Requests

   A SIP MESSAGE request is constructed using RFC 3428 [10].  The
   content-type
   Content-type header field indicates the MIME type of the request
   payload.  When using this extension, the content-type Content-type header field
   MUST be of MIME type "message/cpim" [2] for both Instant Messages IMs and IMDNs.  The
   payload is constructed according to Section 4. 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 [15].

10.1.2.

12.1.2.  Sending Responses

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

10.1.3. been
   asked for.

12.1.3.  Receiving Requests

10.1.3.1.

12.1.3.1.  Instant Message

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

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

   If an endpoint IM Recipient received a SIP MESSAGE request that contains a Messge/
   CPIM payload is an IM that
   requested a negative-delivery, and that endpoint 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 instant message IM (a GW, for example, can generate a 2xx response
   before it has been guaranteed that the final recipient has actually
   received the message). IM).  The negative-delivery notification is constructed
   according to Section 4.2.1. 7.2.1.1.  The message/cpim message is then placed as the
   payload in a SIP MESSAGE request.

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

   If an endpoint IM Recipient received a SIP MESSAGE request that is an IM and that
   contains a Messge/CPIM payload that
   requested a read notification, and that endpoint IM Recipient has constructed
   and sent a SIP 2xx class response, it MAY generate a read
   notification after making sure that the
   instant message IM has been presented to the
   user or application.  It is outside the scope of this document how a
   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 4.2.2. 7.2.1.2.  The message/cpim message is then placed
   as the payload in a SIP MESSAGE request.

10.1.3.2.

12.1.3.2.  Delivery Notification

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

10.1.3.3. 9.

12.1.3.3.  Read Notification

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

10.2. 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 then them like any
   other sip request.

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

   If an intermediary generates a SIP 2xx class response to a SIP
   MESSAGE request it has received that is an instant message, IM, it examines if the
   body was of type "message/cpim".  If so, it checks 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 instant message.
   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
   instant message. 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 MUST SHOULD generate a delivery
   notification if it receives a SIP 4xx, 5xx or 6xx class final
   response for the sent instant message IM or if it has received a SIP 2xx class
   response followed by a negative-delivery notification.

   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
   generation rest of the procedures
   in Section 8.1 apply.

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

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

   If an intermediary receives a SIP MESSAGE request carrying a positive
   delivery notification or a read notification, it statelessly forwards it.

11. it using
   the rules in Section 8.

13.  Transporting Message/CPIM messages Messages using MSRP

11.1.

13.1.  Endpoint Behaviour

11.1.1.

13.1.1.  Sending Requests

   MSRP Relays MUST NOT generate IMDNs.

   An MSRP SEND request is constructed using [11].  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 Instant Messages IMs and IMDNs.  The payload is
   constructed according to Section 4. 7.

   MSRP has built in delivery reports and therefore does not require
   delivery notifications as defined in this specification.  Read
   notifications and any future defined IMDN dispositions, however, as are
   still relevant.  Therefore, an endpoint IM Sender MUST NOT create MSRP SEND
   requests requiring a positive-delivery notification or a negative-
   delivery notification.

   For SEND requests that are IMDNs, the sender IM Recipient MUST NOT request a
   delivery report (an MSRP REPORT to a SEND request).  I.e.  It MUST
   populate the request with a Failure-Report header field with the
   value "no" and with a Success-Report header field with value "no" (or
   alternatively leave out that header field since it defaults to "no").
   The sender IM Recipient also MUST NOT request an IMDN for a SEND request
   that is an IMDN.

   An MSRP SEND request to multiple recipients is contracted constructed in a
   similar manner as a SEND request to a single recipient.  The
   differences are indicated in [14].

11.1.2.

13.1.2.  Sending Responses

   An endpoint receiving an MSRP SEND request constructs an MSRP
   response according to [11] if needed.  Section 7.2 of [11] describes
   when to send and when not to send an MSRP response.  For SEND
   requests that are IMDNs, a response MUST NOT be generated.  This is
   not a special case; for SEND requests that contain a Failure-Report
   header field with the value "no" and a Success-Report header field
   with value "no" the sender IM Sender does not need to start a timer and the
   receiver
   IM Recipient does not send a transactional response.

11.1.3.

13.1.3.  Receiving Requests

11.1.3.1.

13.1.3.1.  Instant Message

   An MSRP SEND request is identified as an instant message IM by examining its contents
   according to Section 6.

11.1.3.2. 9.

13.1.3.2.  Read Report

   An MSRP SEND request is identified as read notification by examining
   its contents according to Section 6. 9.  The receiver IM Sender MUST ignore any
   requests for read notification, or any kind of IMDNs for an IMDN.

11.2.

13.2.  Intermediary Behaviour

   In this context, application servers (including conference servers
   and Store-and-Forward server) and gateways are defined as
   intermediaries.  MSRP Relays MUST NOT generate IMDNs but MUST relay
   them.

   An MSRP SEND request to multiple recipients is forwarded according to
   [14].

   MSRP has built in delivery reports and therefore does not require
   delivery notifications as defined in this specification.  An MSRP
   intermediary MUST NOT generate IMDNs.  A Store-and-Forwards server
   (the equivalent of a voicemail voice-mail server) can send stored session IMs
   to their destination and forward the request for read notifications,
   if any.  The read notification most likely has to be an aggregated
   read notification for all the IMs that were stored for that session,
   and the aggregation has to be done at the endpoint. IM Recipient.  It is
   unknown at this point how a MSRP store-and-forward server
   communicates with the recipient in order to send the IMs.  This is
   outside the scope of this document and is left as a future exercise.

12.

14.  Security Considerations

   Instant Message

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

   Since the IMDN messages IMDNs are carried by using the IM protocol itself, all security
   considerations of the underlying IM protocol also apply to the IMDN messages. 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 user IM Sender with IMDNs by
      convincing a URI-List server to send IMDNs to an unsuspecting
      user. IM
      Sender.

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

   o  A malicious intermediary attempts to forward an IMDN from a
      Reporting endpoint an IM
      Recipient to the Requesting endpoint, IM Sender, where the Reporting
      endpoint IM Recipient would not
      normally forward the IMDN to that Requesting
      endpoint IM Sender if the Reporting endpoint IM Recipient
      knew the identity of the
      Requesting endpoint. 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 with a request for aggregated IMDN processing.

   Attacks the

   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
      issue
      implementation issue.

   o  A malicious Reporting endpoint IM Recipient that alters the time of the report. IMDN.  There
      is no protocol mechanism for ensuring the endpoint IM Recipient does not
      lie about the time or purposely holds an IMDN for transmission to
      make it appear that the user disposed of a message 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 Reporting
      endpoint IM Recipient
      to silently ignore an IMDN request.  Any mechanism that would
      reliably indicate that a malicious node deleted a Reporting
      endpoint's IM Recipient's
      IMDN would also serve the purpose of detecting a
      Reporting endpoint 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 sender of the IM Sender has and sets the
   expectation for the level of protection.  The procedures for
   integrity protection are as follows.

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

   o  If the IM is encrypted, the Reporting endpoint 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 reporting endpoint IM Recipient or intermediary MUST be capable of loading a user
   certificate.

   An attacker can mount a distributed denial of service attack on a
   node by sending lots of messages 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 a B2BUA an
   intermediary by asking the B2BUA intermediary to explode a large list and
   to direct the B2BUA intermediary to consolidate aggregate the IMDN's IMDNs from the targets of
   the list.

   The following security considerations apply when using message IMDNs:

12.1.

14.1.  Forgery

   Message

   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 to the CPIM headers), MUST consume the IM and
   create a new copy of it that the intermediary signs itself.

   IMDNs may be forged as easily as ordinary Instant Message.
   User agents 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 denial-
   of-service attacks.  Security threats related to forged message IMDNs include
   the sending of a falsified IMDN when the indicated disposition of the message
   IM has not actually occurred.  For example, read notification could
   be forged to indicate that a IM
   recipient Recipient has read the instant message. IM.
   Unsolicited IMDNs is also another form of forgery.

12.2.

14.2.  Confidentiality

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

   A user agent

   An IM Recipient can obtain such consent by a prompt or dialog box on
   a
   per-message 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 requesting requests IMDNs to a
   list who's member information is not disclosed.  In this situation,
   the sender user will learn of the list members.  The  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 list URI-list server MAY reject the IM.

   An unencrypted IMDN could reveal confidential information about an
   encrypted instant message. 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.

12.3.

14.3.  Non-Repudiation

   Message

   IMDNs cannot be relied on as a guarantee that an instant
   message IM was or was not
   seen by the recipient. 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 recipient on the IM.
   .

13. IM Recipient.

15.  IANA Considerations

13.1.

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

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

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

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

   Interoperability considerations: none.

   Published specification: This document.

   Applications which use this media type: This document type has been is used to
   support SIP and MSRP 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)

   Intended Usage: COMMON

   Author/change controller: The IETF .

13.2.

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

13.3.

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)

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

13.4. 11.3.

15.4.  Message/CPIM Header Field registration

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

   Disposition-Notification - [RFCXXXX]

   Message-ID - [RFCXXXX]

   Original-To - [RFCXXXX]
   IMDN-Record-Route - [RFCXXXX]

   IMDN-Route - [RFCXXXX].

13.5.

15.5.  Content-Disposition: notification

   content-disposition

   This document registers one new Content-Disposition header
   "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 .

14. according to an earlier request
   for a disposition notification to an instant message

16.  Acknowledgements

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

15.

17.  References

15.1.

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]  Bray, T., "Exensible "Extensible Markup Language (XML) 1.0 (Second
        Edition)",  W3C CR CR-xml11-20011006, October 2000.

   [8]  Ramsdell, B., "S/MIME Version 3 Message Specification",
        RFC 2633, June 1999.

15.2.

17.2.  Informative References

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

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

   [11]  Campbell, B., "The Message Session Relay Protocol",
          draft-ietf-simple-message-sessions-10, February 2005.
          draft-ietf-simple-message-sessions-15, June 2006.

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

   [13]  Fajman, R., "An Extensible Message Format for Message
         Disposition Notifications", RFC 2298, March 1998.

   [14]  Niemi, A., "Multi-part IM Sessions Using MSRP",
          draft-niemi-simple-chat-04, February 2006.

   [15]  Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
         Requests in SIP",  draft-ietf-sipping-uri-list-message-02,
         November 2004.  draft-ietf-sip-uri-list-message-00.txt,
         September 2006.

Authors' Addresses

   Eric Burger
   Cantata Technology
   18 Keewaydin Dr.
   Salem, NH  03079-2839
   USA

   Phone: +1 603 890 7587
   Fax:   +1 603 457 5944
   Email: eburger@brooktrout.com eburger@cantata.com

   Hisham Khartabil
   Telio
   P.O. Box 1203 Vika
   Oslo  0110
   Norway

   Phone: +47 2167 3544
   Email: hisham.khartabil@telio.no

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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 Statement

   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.

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The Internet Society (2006).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society. IETF
   Administrative Support Activity (IASA).