SIMPLE                                                         E. Burger
Internet-Draft                                        Cantata Technology
Expires: November 27, 2006                                  H. Khartabil
                                                                   Telio
                                                            May 26, 2006


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

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.

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 endpoints
   to request, create and send IM Disposition Notifications (IMDN),
   including delivery and read notifications, for page-mode as well as
   session mode instant messages.  This document also describes how SIP



Burger & Khartabil      Expires November 27, 2006               [Page 1]


Internet-Draft         IM Disposition Notification              May 2006


   and MSRP entities behave using this extension.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Disposition States . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  delivered  . . . . . . . . . . . . . . . . . . . . . .  5
       3.1.2.  read . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Endpoints Behaviour  . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Constructing Instant Messages  . . . . . . . . . . . . . .  5
     4.2.  Constructing IMDNs . . . . . . . . . . . . . . . . . . . .  6
       4.2.1.  Constructing Delivery Notification . . . . . . . . . .  7
       4.2.2.  Constructing Read Notification . . . . . . . . . . . .  8
     4.3.  Aggregation of IMDNs . . . . . . . . . . . . . . . . . . .  8
     4.4.  Keeping State  . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Intermediary Behaviour . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Aggregation of IMDNs . . . . . . . . . . . . . . . . . . . 10
   6.  Identifying Messages . . . . . . . . . . . . . . . . . . . . . 11
   7.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  CPIM Header Namespace  . . . . . . . . . . . . . . . . . . 11
     7.2.  Disposition-Notification . . . . . . . . . . . . . . . . . 12
     7.3.  Message-ID . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.4.  Original-To  . . . . . . . . . . . . . . . . . . . . . . . 12
     7.5.  Really-From  . . . . . . . . . . . . . . . . . . . . . . . 12
     7.6.  Really-To  . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Header Fields Formal Syntax  . . . . . . . . . . . . . . . . . 12
   9.  IMDN Format  . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Structure of XML-Encoded imdn  . . . . . . . . . . . . . . 13
       9.1.1.  The <message-id> Element . . . . . . . . . . . . . . . 13
       9.1.2.  The <datetime> Element . . . . . . . . . . . . . . . . 13
       9.1.3.  The <recipient-uri>; Element . . . . . . . . . . . . . 14
       9.1.4.  The <original-recipient-uri>; Element  . . . . . . . . 14
       9.1.5.  The <subject>; Element . . . . . . . . . . . . . . . . 14
       9.1.6.  The <disposition> Element  . . . . . . . . . . . . . . 14
       9.1.7.  The <status> Element . . . . . . . . . . . . . . . . . 14
       9.1.8.  The <note> Element . . . . . . . . . . . . . . . . . . 14
     9.2.  MIME Type for imdn Document  . . . . . . . . . . . . . . . 14
     9.3.  The XML Schema . . . . . . . . . . . . . . . . . . . . . . 15
   10. Transporting Message/CPIM messages using SIP . . . . . . . . . 15
     10.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 15
       10.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 15
       10.1.2. Sending Responses  . . . . . . . . . . . . . . . . . . 15
       10.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 15
     10.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 16
   11. Transporting Message/CPIM messages using MSRP  . . . . . . . . 17



Burger & Khartabil      Expires November 27, 2006               [Page 2]


Internet-Draft         IM Disposition Notification              May 2006


     11.1. Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 17
       11.1.1. Sending Requests . . . . . . . . . . . . . . . . . . . 17
       11.1.2. Sending Responses  . . . . . . . . . . . . . . . . . . 18
       11.1.3. Receiving Requests . . . . . . . . . . . . . . . . . . 18
     11.2. Intermediary Behaviour . . . . . . . . . . . . . . . . . . 18
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     12.1. Forgery  . . . . . . . . . . . . . . . . . . . . . . . . . 21
     12.2. Confidentiality  . . . . . . . . . . . . . . . . . . . . . 21
     12.3. Non-Repudiation  . . . . . . . . . . . . . . . . . . . . . 22
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
     13.1. message/imdn+xml MIME TYPE . . . . . . . . . . . . . . . . 22
     13.2. URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:imdn  . . . . . . . . . . . . . . . 23
     13.3. Schema Registration  . . . . . . . . . . . . . . . . . . . 23
     13.4. Message/CPIM Header Field registration . . . . . . . . . . 23
     13.5. Content-Disposition: notification  . . . . . . . . . . . . 24
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     15.2. Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27





























Burger & Khartabil      Expires November 27, 2006               [Page 3]


Internet-Draft         IM Disposition Notification              May 2006


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, 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 can also be used to carry Message/CPIM messages.

   This document extends Message/CPIM message format to enable endpoints
   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
   negative delivery notifications (i.e. a message did not get delivered
   successfully).  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.

   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 or an intermediary determines the recipient
   has received, did not receive or has read the message or otherwise
   disposed the message.  The mechanism by which an instant message user
   agent determines its user has read a message is beyond the scope of
   this document.  At that point, the recipient user agent or



Burger & Khartabil      Expires November 27, 2006               [Page 4]


Internet-Draft         IM Disposition Notification              May 2006


   intermediary automatically generates a notification message to the
   sender.  This notification message is the Instant Message Disposition
   Notification (IMDN).

3.1.  Disposition States

   There are two broad categories 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 may not be the same user agent that sent the
   instant message.  This is specifically true for page-mode instant
   messages where the Address of Record (AOR) of the IM sender present
   in the IMDN resolves to a different location to where the IM
   originated.  Also, some devices may not implement the concept of
   "Sent Items" box and therefore no information about an IM is stored.
   It is therefore necessary to add a time stamp in the IM to indicate
   when it was sent in order to enable the human user to correlate the



Burger & Khartabil      Expires November 27, 2006               [Page 5]


Internet-Draft         IM Disposition Notification              May 2006


   IM with the IMDN.  This time stamp is returned in the IMDN in order
   to enable the user to correlate the IM with the IMDN at the human
   level.  The message/CPIM DateTime header field is used for this
   purpose.  The message/CPIM IM MUST contain a DateTime header field if
   an IMDN is requested.

   In this specification, the sender can request two types of delivery
   notifications: a failure delivery notification and a success delivery
   notification.  A failure delivery notification is requested by
   including a Disposition-Notification header field with value
   "negative-delivery".  Similarly, a success notification is requested
   by including a Disposition-Notification header field with value
   "positive-delivery".  Both types of notifications can be requested
   for the same message.

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

   The absence of this header or the presence of the header with empty
   value 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 IM.

   The formal syntax of the Disposition-Notification header field can be
   found in Section 8.  The following in an example Message/CPIM instant
   message where the user requests positive and negative delivery
   notifications, but not 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 one type of IMDN for a single IM, For example a delivery
   notification as well as a read notification.  In this case the



Burger & Khartabil      Expires November 27, 2006               [Page 6]


Internet-Draft         IM Disposition Notification              May 2006


   endpoint constructing IMDNs MUST be able to construct multiple IMDNs
   per IM.

   Disposition-Notification header MUST NOT 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 of
   the IMDN MUST ignore it if present.

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

   If Really-From header fields appear in the IM, the endpoint
   constructing the IMDN MUST copy the contents of the Really-From
   header fields into Really-To header fields in the IMDN and maintain
   the order.  The IMDN is then sent to the address in the top Really-To
   header field.

4.2.1.  Constructing Delivery Notification

   A delivery notification is constructed in a similar fashion as an
   instant message, using RFC 3862 [2].  For delivery notifications, the
   content-type MUST be of type "message/imdn+xml".  It is an XML
   document.  The schema is described Section 9.  The delivery
   notification MUST contain a Content-Disposition header field with
   value "notification".  This indicates to the receiver that the
   contents of the message are a notification according to an earlier
   request 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: 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>



Burger & Khartabil      Expires November 27, 2006               [Page 7]


Internet-Draft         IM Disposition Notification              May 2006


                 </imdn>

4.2.2.  Constructing Read Notification

   A read notification is constructed in a similar fashion as the
   delivery notification.  See Section 4.2.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>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 the message has been read.  The recipient user agent in
   this case generates a read notification with a <status> value of
   "error" to indicate an internal error by the server.

4.3.  Aggregation of IMDNs

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

   Disposition-Notification: positive-delivery;aggregate, read




Burger & Khartabil      Expires November 27, 2006               [Page 8]


Internet-Draft         IM Disposition Notification              May 2006


   An endpoint that requested an aggregated IMDN MUST be prepared to
   receive multiple aggregated IMDNs.  See Section 5.1 for details.

   An endpoint 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
   for details.  Note that the "aggregate" parameter is a hint for
   intermediaries and does not require the intermediaries to aggregate
   IMDNs.

4.4.  Keeping State

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

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

   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 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 that forwards an IM may change the recipient address



Burger & Khartabil      Expires November 27, 2006               [Page 9]


Internet-Draft         IM Disposition Notification              May 2006


   in the CPIM To header field when forwarding (for example, a URI-List
   server change the recipient address from its own to the address of
   the final recipient of that message).  In this case, the intermediary
   MUST add a CPIM Original-To header to the CPIM message populating it
   with the address of the sender.

   An intermediary MAY choose to remain on the path of IMDNs for a
   specific IM.  It can do so by adding a CPIM Really-From header field
   as the top Really-From 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 an IMDN checks the top Really-To header
   field.  If that header field carries the intermediary address, the
   intermediary pops that header and forwards the IMDN to the address
   indicated in the now top Really-To header.

   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 from
   the body of the IMDN before forwarding it to the IM sender.

5.1.  Aggregation of IMDNs

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

   When a URI-List server receives an instant message, it needs to
   examine Disposition-Notification header fields.  If an IMDN request
   contains the "aggregate" parameter, the URI-List server MUST wait for
   a configurable period of time or until all recipients have sent the
   IMDN (whichever comes first) before the URI-List server sends an
   aggregated IMDN.  Note that some IMDNs, for example read
   notifications, may never come due to user settings.  It is an
   administrator configuration and an implementation issue how long to
   wait before sending an aggregated IMDN and before a URI-List server
   removes state for that IM.  A URI-List server may choose to send
   multiple aggregated IMDNs even if the 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 IM,
   send the aggregated IMDN and restart the timer for the next batch.
   This is needed for scenarios where the IM sender has requested more
   than one IMDN for a specific IM, for example, delivery notifications
   as well as read notifications, or when the URI-List server is short
   on resources and chooses to prioritise forwarding IMs over IMDNs.  A
   second timer can be running and when it fires, the state of the IM is
   deleted.  In this case, the URI-List server consumes any IMDNs that
   might arrive after that time.



Burger & Khartabil      Expires November 27, 2006              [Page 10]


Internet-Draft         IM Disposition Notification              May 2006


   A URI-List server MAY aggregate IMDNs even if the IM sender did not
   request from it to do so.  This is to handle the case where the list
   membership information is not disclosed.

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

   There are scenarios where an intermediary needs to generate IMDNs,
   see Section 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 in the request of
   the transport protocol, the message is an instant message if the
   content-type header field present 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 the case of a message/cpim body, the
   message is a delivery notification if: the content-type header field
   present in the message/cpim body has a value of "message/imdn+xml",
   the Content-Disposition header field has a value of "notification",
   and the <disposition> element in that xml body has a value of
   "delivery".  An endpoint matches a delivery notification to an
   instant message by matching the Message-ID 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 or the <original-recipient-uri> element
   in the XML body is used to identify the recipient.

   A Message/CPIM message request is identified as a read notification
   and is matched to an instant message in a similar fashion as a
   delivery notification.  The difference is that the <disposition>
   element in that xml body has a value of "read".


7.  Header Fields

7.1.  CPIM Header Namespace

   Per CPIM [2], IMDN uses a namespace for the CPIM headers.  The
   namespace is
   urn:ietf:params:cpim-headers:imdn

   All of the header definitions in this document refer to this



Burger & Khartabil      Expires November 27, 2006              [Page 11]


Internet-Draft         IM Disposition Notification              May 2006


   namespace.

7.2.  Disposition-Notification

   The Disposition-Notification header field is a Message/CPIM extension
   that is used by the instant message sender to indicate the request to
   receive IMDNs for that specific IM.  This header field is optional
   and is not needed if 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 a Message/CPIM extension that is used
   by the instant message 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 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 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 syntax is defined in Section 8.

7.5.  Really-From

   The Really-From header field is a Message/CPIM extension that is
   added to an IM by an intermediary in order to indicate that it wants
   the IMDN to be sent to it.  The syntax is defined in Section 8.
   Multiple Really-From headers can appear in an IM

7.6.  Really-To

   The Really-To header field is a Message/CPIM extension that is added
   to an IMDN by an endpoint by copying the contents of te Really- From
   header that appeared in the IM.  This header is used by the endpoint
   and intermediaries to route IMDNs to the final destination.  The
   syntax is defined in Section 8.  Multiple Really-From headers can
   appear in an IMDN.


8.  Header Fields Formal Syntax

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



Burger & Khartabil      Expires November 27, 2006              [Page 12]


Internet-Draft         IM Disposition Notification              May 2006


   Disposition-Notification =
             "Disposition-Notification" ": " [(notify-req *(COMMA notify-req))]
   notify-req = ("negative-delivery" / "positive-delivery" / "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 = "Really-From" ": "  [ Formal-name ] "<" URI ">"

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



9.  IMDN Format

9.1.  Structure of XML-Encoded imdn

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

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

9.1.1.  The <message-id> Element

   The <message-id> element is optional 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.  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.



Burger & Khartabil      Expires November 27, 2006              [Page 13]


Internet-Draft         IM Disposition Notification              May 2006


9.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 To header
   field of the IM.

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

   The <original-recipient-uri> element is optional and carries the URI
   of the final 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.  The <subject>; Element

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

9.1.6.  The <disposition> Element

   The <disposition> is element mandatory and carries the disposition
   type that the IM sender requested and is being reported.  I can carry
   the values "delivery", "read" and any other future extension.

9.1.7.  The <status> Element

   The <status> element is mandatory and carries the result of the
   disposition request in the <disposition> element.  It can carry the
   values "success" to mean the disposition was successful, "failure" to
   mean the disposition fail, "forbidden" to mean the disposition was
   denied, "error" to mean internal server error, and any other future
   extension.

9.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.  MIME Type for imdn Document

   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 the IMDN that also carries payload type information MUST
   identify the payload as MIME type "message/imdn+xml" in the Content-
   Type header field.




Burger & Khartabil      Expires November 27, 2006              [Page 14]


Internet-Draft         IM Disposition Notification              May 2006


9.3.  The XML Schema



10.  Transporting Message/CPIM messages using SIP

10.1.  Endpoint Behaviour

10.1.1.  Sending Requests

   A SIP MESSAGE request is constructed using RFC 3428 [10].  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 and
   IMDNs.  The payload is constructed according to Section 4.

   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.  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 has been
   asked for or the type of MESSAGE request it has received (instant
   message or IMDN).

10.1.3.  Receiving Requests

10.1.3.1.  Instant Message

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

   If an endpoint received a SIP MESSAGE request that is carrying an IM
   and that contains a Messge/CPIM payload that requested a positive-
   delivery notification, and that endpoint has constructed and sent a
   SIP 2xx class response, it MAY generate a positive-delivery
   notification after making sure that the instant message 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).  The positive-delivery
   notification is constructed according to Section 4.2.1.  The message/
   cpim message is then placed as the payload in a SIP MESSAGE request.

   If an endpoint received a SIP MESSAGE request that contains a Messge/
   CPIM payload that requested a negative-delivery, and that endpoint



Burger & Khartabil      Expires November 27, 2006              [Page 15]


Internet-Draft         IM Disposition Notification              May 2006


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

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

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

10.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.  Read Notification

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

10.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 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, it



Burger & Khartabil      Expires November 27, 2006              [Page 16]


Internet-Draft         IM Disposition Notification              May 2006


   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" and/or "negative-delivery".  If so, it MUST send
   a delivery notification after receiving a transactional response for
   the instant message.

   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.  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 generate a delivery
   notification if it receives a SIP 4xx, 5xx or 6xx class final
   response for the sent instant message or if it has received a SIP 2xx
   class response followed by a negative-delivery notification.  The
   generation of such IMDN is the same procedure as that for an endpoint
   (Section 4.2.1).

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

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


11.  Transporting Message/CPIM messages using MSRP

11.1.  Endpoint Behaviour

11.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 and IMDNs.  The
   payload is constructed according to Section 4.

   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
   still relevant.  Therefore, an endpoint MUST NOT create MSRP SEND
   requests requiring a positive-delivery notification or a negative-
   delivery notification.




Burger & Khartabil      Expires November 27, 2006              [Page 17]


Internet-Draft         IM Disposition Notification              May 2006


   For SEND requests that are IMDNs, the sender 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 also MUST NOT request an IMDN for a SEND request that is
   an IMDN.

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

11.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 does not need to start a timer and the
   receiver does not send a transactional response.

11.1.3.  Receiving Requests

11.1.3.1.  Instant Message

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

11.1.3.2.  Read Report

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

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



Burger & Khartabil      Expires November 27, 2006              [Page 18]


Internet-Draft         IM Disposition Notification              May 2006


   intermediary MUST NOT generate IMDNs.  A Store-and-Forwards server
   (the equivalent of a voicemail 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.  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.  Security Considerations

   Instant Message IMDNs provide a fine-grained view of the activity of
   the entity receiving the IM 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).

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


   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 with IMDNs by
      convincing a URI-List server to send IMDNs to an unsuspecting
      user.

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

   o  A malicious intermediary attempts to forward an IMDN from a
      Reporting endpoint to the Requesting endpoint, where the Reporting
      endpoint would not normally forward the IMDN to that Requesting
      endpoint if the Reporting endpoint knew the identity of the
      Requesting endpoint.

   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



Burger & Khartabil      Expires November 27, 2006              [Page 19]


Internet-Draft         IM Disposition Notification              May 2006


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

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

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




Burger & Khartabil      Expires November 27, 2006              [Page 20]


Internet-Draft         IM Disposition Notification              May 2006


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

   The following security considerations apply when using message IMDNs:

12.1.  Forgery

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

12.2.  Confidentiality

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

   A user agent can obtain such consent by a prompt or dialog box on a
   per-message 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 IMDNs to
   a list who's member information is not disclosed.  In this situation,
   the sender will learn of the list members.  The URI-List server MUST
   only deliver one aggregated IMDN.  Alternatively, the list server MAY



Burger & Khartabil      Expires November 27, 2006              [Page 21]


Internet-Draft         IM Disposition Notification              May 2006


   reject the IM.

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

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

13.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 of this document.

   Interoperability considerations: none.

   Published specification: This document.

   Applications which use this media type: This document type has been
   used to support SIP and MSRP based instant messaging.




Burger & Khartabil      Expires November 27, 2006              [Page 22]


Internet-Draft         IM Disposition Notification              May 2006


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




Burger & Khartabil      Expires November 27, 2006              [Page 23]


Internet-Draft         IM Disposition Notification              May 2006


13.5.  Content-Disposition: notification

   content-disposition notification .


14.  Acknowledgements

   The author would like to thank Paul Kyzivat, Ben Campbell, Adam Roach
   and Gonzalo Camarillo for their comments and support.


15.  References

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




Burger & Khartabil      Expires November 27, 2006              [Page 24]


Internet-Draft         IM Disposition Notification              May 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.







































Burger & Khartabil      Expires November 27, 2006              [Page 25]


Internet-Draft         IM Disposition Notification              May 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


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

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






























Burger & Khartabil      Expires November 27, 2006              [Page 26]


Internet-Draft         IM Disposition Notification              May 2006


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.




Burger & Khartabil      Expires November 27, 2006              [Page 27]