One document matched: draft-ietf-simple-imdn-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<rfc category="std" docName="draft-ietf-simple-imdn-07" ipr="full3978">
<front>
<title abbrev="IMDN">Instant Message Disposition Notification</title>
<author fullname="Eric Burger" initials="E." surname="Burger">
<organization>BEA Systems, Inc.</organization>
<address>
<postal>
<street>4 Van de Graaff Dr.</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>USA</country>
</postal>
<phone>+1 781 993 7437</phone>
<facsimile>+1 603 457 5933</facsimile>
<email>eric.burger@bea.com</email>
</address>
</author>
<author fullname="Hisham Khartabil" initials="H." surname="Khartabil">
<organization></organization>
<address>
<postal>
<street></street>
<city>Melbourne</city>
<code></code>
<country>Australia</country>
</postal>
<phone>+61 416 108 890</phone>
<email>hisham.khartabil@gmail.com</email>
</address>
</author>
<date day="2" month="April" year="2008" />
<area>RAI</area>
<workgroup>SIMPLE</workgroup>
<abstract>
<t>Instant Messaging (IM) refers to the transfer of messages between
users in real-time. This document provides a mechanism whereby endpoints
can request Instant Message Disposition Notifications (IMDN), including
delivery, processing, and read notifications, for page-mode instant
messages. <vspace blankLines="1" /> The Common Profile for Instant
Messaging (CPIM) data format specified in RFC 3862 is extended with new
header fields that enable endpoints to request IMDNs. A new message
format is also defined to convey IMDNs. <vspace blankLines="1" /> This
document also describes how SIP entities behave using this
extension.</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>In many user-to-user message exchange systems, message senders often
wish to know if the human recipient actually received or read a message.
<vspace blankLines="1" /> <xref target="RFC2821">Electronic Mail</xref>
deals with this situation with <xref target="RFC3798">Message Delivery
Notifications</xref>. 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 <xref
target="RFC3798">RFC 3798</xref>. The fixed format ensures that an
automaton can process the message.</t>
<t>The common presence and instant messaging (CPIM) format, Message/CPIM
<xref target="RFC3862"></xref>, is a message format used to generate
instant messages. The session initiation protocol, SIP <xref
target="RFC3261"></xref>, can carry instant messages generated using
message/CPIM in SIP MESSAGE requests <xref target="RFC3428"></xref>.</t>
<t>This document extends the Message/CPIM message format in much the
same way Message Delivery Notifications extends Electronic Mail. This
extension enables Instant Message Senders to request, create, and send
Instant Message Disposition Notifications (IMDN). This mechanism works
for page-mode as well as session mode instant messages. This document
only discusses page-mode. Session mode is left for future
standardisation efforts.</t>
<t>IMDNs include positive delivery, negative delivery (i.e., a message
did not get delivered successfully), read notifications (i.e., a message
was rendered) as well as processed notifications. By using CPIM header
fields, the IMDN request and delivery are abstracted outside the
transport protocol allowing interoperability between different IM
systems.</t>
</section>
<section anchor="Conventions" title="Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>This document refers generically to the sender of a message in the
masculine (he/him/his) and the recipient of the message in the feminine
(she/her/hers). This convention is purely for convenience and makes no
assumption about the gender of a message sender or recipient.</t>
</section>
<section anchor="terminology" title="Terminology">
<t><list style="symbols">
<t>IM: An Instant Message generated using the Message/CPIM
format.</t>
<t>IMDN: An Instant Message Disposition Notification generated using
the Message/CPIM format that carries an IMDN XML document.</t>
<t>Message: an IM or an IMDN generated using the Message/CPIM
format.</t>
<t>IM Sender: An endpoint (User Agent) generating and sending an IM.
Also, the endpoint request IMDNs for an IM. Quite often, the IM
Sender is the IMDN Recipient. However, that is not always the case,
since the IMDN uses the From header in the CPIM message. That value
is often the IM Sender's Address of Record (AOR). This address may
in fact resolve to different User Agents.</t>
<t>IM Recipient: An endpoint (User Agent) that receives IMs. The IM
Recipient, as the node that presumably renders the IM to the user,
generates and sends delivery IMDNs to IMs, if requested by the IM
Sender and allowed by the IM Recipient.</t>
<t>Endpoint: An IM Sender or an IM Recipient.</t>
<t>Intermediary: An entity in the network, most often an application
server, including URI-List servers and Store-and-Forward servers,
that forwards an IM to its final destination. Intermediaries also
can generate and send processing IMDNs to IMs, if requested by the
IM Sender and allowed by policy.</t>
<t>Gateway: An intermediary that translates between different IM
systems that use different protocols.</t>
<t>IMDN Payload: An XML document carrying the disposition
notification information. In this specification, it is of MIME type
"message/imdn+xml".</t>
<t>Disposition type: the type of IMDN that can be requested. This
specification defines three, namely "delivery", "processing" and
"read" disposition types.</t>
<t>Transport Protocol Message: A SIP or other protocol message that
contains an IM or IMDN.</t>
</list></t>
</section>
<section title="Overview">
<t>The diagram below shows the basic protocol flow. An IM Sender creates
an IM, adds IMDN request information the IM Sender is interested in
receiving and then sends the IM. At a certain point in time, the IM
Recipient or an intermediary determines that the user or application has
received, did not receive, read, or otherwise disposed the IM. The
mechanism by which an IM Recipient determines its user has read an IM is
beyond the scope of this document. At that point, the IM Recipient or
intermediary automatically generates a notification message to the IM
Sender. This notification message is the Instant Message Disposition
Notification (IMDN).</t>
<figure title="Basic IMDN Message Flow">
<artwork><![CDATA[+--------------+ +--------------+
| IM Sender | | IM Recipient |
|IMDN Recipient| | IMDN Sender |
+--------------+ +--------------+
| |
| |
| 1. IM requesting IMDN |
|-------------------------------------->|
| |
| |
| 2. IMDN (disposition) |
|<--------------------------------------|
| |
| |
]]></artwork>
</figure>
<t>Note that the recipient of an IMDN, in some instances, may not be the
IM Sender. This is specifically true for page-mode IMs where the Address
of Record (AOR) of the IM Sender, that is present in the IM, resolves to
a different location or user agent than the IM originated. This could
happen, for example, if resolving the AOR results in forking the request
to multiple user agents. For simplicity, the rest of this document
assumes that the IM Sender and the IMDN Recipient are the same and
therefore will refer to both as the IM Sender.</t>
</section>
<section anchor="disposition-states" title="Disposition Types">
<t>There are three broad categories of disposition states. They are
delivery, processing, and read.</t>
<section title="Delivery">
<t>The delivery notification type indicates whether the IM has been
delivered to the IM Recipient or not. The delivery notification type
can have the following states: <list style="symbols">
<t>"delivered" to indicate successful delivery.</t>
<t>"failed" to indicate failure in delivery.</t>
<t>"forbidden" indicate denial for the IM Sender to receive the
requested IMDN. The IM Recipient can send the "forbidden" state,
but usually it is an intermediary that sends the message if one
configures it to do so. For example, it is possible the
administrator has disallowed IMDNs.</t>
<t>"error" to indicate an error in determining the fate of an
IM.</t>
</list></t>
</section>
<section title="Processing">
<t>The processing notification type indicates that an intermediary has
processed an IM. The processing notification type can have the
following states: <list style="symbols">
<t>"processed" is a general state of the IM indicating that the
intermediary has performed its task on the IM.</t>
<t>"stored" state indicates that the intermediary stored the IM
for later delivery.</t>
<t>"forbidden" indicate denial for the IM Sender to receive the
requested IMDN. The "forbidden" state is sent by an intermediary
that is configured to do so. For example, the administrator has
disallowed IMDNs.</t>
<t>"error" to indicate an error in determining the fate of an
IM.</t>
</list></t>
</section>
<section title="Read">
<t>The read notification type indicates whether the IM Recipient
rendered the IM to the user or not. The read notification type can
have the following states: <list style="symbols">
<t>"read" is a state indicating that the IM has been rendered to
the user.</t>
<t>"forbidden" indicate denial, by the IM Recipient, for the IM
Sender to receive the requested IMDN.</t>
<t>"error" to indicate an error in determining the fate of an
IM.</t>
</list></t>
<t>In addition to text, some IMs may contain audio, video, and still
images. Therefore, the state "read" includes playing the audio or
video file to the user.</t>
<t>Since there is no positive acknowledgement from the user, one
cannot determine <spanx>a priori</spanx> the user actually read the
IM. Thus, one cannot use the protocol described here as a
non-repudiation service.</t>
</section>
</section>
<section title="New CPIM Header Fields">
<t>This specification extends the CPIM data format specified in RFC 3862
<xref target="RFC3862"></xref>. A new name space is created as well as a
number of new CPIM header fields.</t>
<section title="CPIM Header Field Namespace">
<t>Per <xref target="RFC3862">CPIM</xref>, this specification defines
a new name space for the CPIM extension header fields defined in the
following sections. The name space is: <vspace blankLines="1" />
urn:ietf:params:imdn <vspace blankLines="1" /> As per <xref
target="RFC3862">CPIM</xref> requirements, the new header fields
defined in the following sections are prepended, in CPIM messages, by
a prefix assigned to the URN through the NS header field of the CPIM
message. The remaining of this specification always assumes an NS
header field like this one: <vspace blankLines="1" /> NS: imdn
<urn:ietf:params:imdn>.</t>
<t>Of course, clients are free to use any prefix while servers and
intermediaries must accept any legal name space prefix
specification.</t>
</section>
<section title="Disposition-Notification">
<t>The IM Sender MUST include the Disposition-Notification header
field to indicate the desire to receive IMDNs from the IM Recipient,
for that specific IM. <xref target="syntax"></xref> defines the
syntax.</t>
</section>
<section title="Message-ID">
<t>The IM Sender MUST include the Message-ID header field in the IM
that he wishes to receive an IMDN on. The Message-ID contains a
globally unique message identifier the IM Sender can use to correlate
received IMDNs. When the IM Sender receives an IMDN, it can compare
its value with the value of the <message-id> element present in
the IMDN payload. IMDNs also carry this header field. Note that since
the IMDN is itself an IM, the Message-ID of the IMDN will be different
than the Message-ID of the original IM. <xref target="syntax"></xref>
defines the syntax.</t>
</section>
<section title="Original-To">
<t>An intermediary MAY insert an Original-To header field to the IM.
The value of the Original-To field MUST be the address of the IM
Receiver. The IM Recipient uses this header to indicate the original
IM address in the IMDNs. The IM Recipient does this by populating the
<original-recipient-uri> element in the IMDN. The intermediary
MUST insert this header if the intermediary changes the CPIM To header
field value. The header field MUST NOT appear more than once in an IM.
The intermediary MUST NOT change this header field value if it is
already present. <xref target="syntax"></xref> defines the syntax.</t>
</section>
<section title="IMDN-Record-Route">
<t>An intermediary MAY insert an IMDN-Record-Route header field to the
IM. The value of the IMDN-Record-Route header field MUST be the
address of the intermediary. Multiple IMDN-Record-Route header fields
can appear in an IM. <xref target="syntax"></xref> defines the
syntax.</t>
</section>
<section title="IMDN-Route">
<t>The IMDN-Route header field provides routing information by
including one or more addresses where to route the IMDN. An
intermediary that needs the IMDN to flow back through the same
intermediary MUST add the IMDN-Record-Route header. When the IM
Recipient creates the corresponding IMDN, the IM Recipient copies the
IMDN-Record-Route headers into corresponding IMDN-Route header fields.
<xref target="syntax"></xref> defines the syntax.</t>
</section>
</section>
<section anchor="endpoint-behaviour" title="Endpoint Behaviour">
<section title="IM Sender">
<section anchor="construct_im" title="Constructing Instant Messages">
<t>An IM is constructed using CPIM Message Format defined in RFC
3862 <xref target="RFC3862"></xref>.</t>
<section title="Adding a Message-ID Header Field">
<t>If the IM sender requests the reception of IMDNs, the IM sender
MUST include a Message-ID header field. The Message-ID field is
populated with a value that is unique with at least 32 bits of
randomness. This header field enables the IM Sender to match any
IMDNs with their corresponding IMs.</t>
</section>
<section title="Adding a DateTime Header Field">
<t>Some devices are not able to retain state over long periods.
For example, mobile devices may have memory limits or battery
limits. These limits may mean these devices may not be able to, or
may chose not to, keep sent messages for the purposes of
correlating IMDNs with sent IMs. To make some use of IMDN in this
case, we add a time stamp to the IM to indicate when the user sent
the message. The IMDN returns this time stamp to enable the user
to correlate the IM with the IMDN at the human level. We use the
DateTime CPIM header field for this purpose. Thus, if the IM
Sender would like an IMDN, the IM Sender MUST include the DateTime
CPIM header field.</t>
</section>
<section title="Adding a Disposition-Notification Header Field">
<t>The Disposition-Notification conveys the type of disposition
notification requested by the IM sender. There are three types of
disposition notification: delivery, processing, and read. The
delivery notification is further subdivided into failure and
success delivery notifications. An IM Sender requests failure
delivery notification by including a Disposition-Notification
header field with value "negative-delivery". Similarly, a success
notification is requested by including a Disposition-Notification
header field with value "positive-delivery". The IM Send can
request both types of delivery notifications for the same IM.</t>
<t>The IM Sender can request a processing notification by
including a Disposition-Notification header field with value
"processing".</t>
<t>The IM Sender can also request a read notification. The IM
Sender MUST include a Disposition-Notification header field with
the value "read" to request a read request.</t>
<t>The absence of this header field or the presence of the header
field with an empty value indicates that the IM Sender is not
requesting any IMDNs. Disposition-Notification header field values
are comma separated. The IM Sender MAY request more than one type
of IMDN for a single IM.</t>
<t>Future extensions may define other disposition notifications
not defined in this document.</t>
<t><xref target="syntax"></xref> describes the formal syntax for
the Disposition-Notification header field. The following is an
example CPIM body of an IM where the IM Sender requests positive
and negative delivery notifications, but neither read notification
nor processing notifications:</t>
<figure>
<artwork><![CDATA[
From: Alice <im:alice@example.com>
To: Bob <im:bob@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: 34jk324j
DateTime: 2006-04-04T12:16:49-05:00
imdn.Disposition-Notification: positive-delivery, negative-delivery
Content-type: text/plain
Content-length: 12
Hello World
]]></artwork>
</figure>
</section>
</section>
<section title="Matching IMs with IMDNs">
<t>An IM Sender matches an IMDN to an IM by matching the Message-ID
header field value in the IM with the <message-id> element
value in the body of the IMDN. If the IM was delivered to multiple
recipients, the IM Sender uses the <recipient-uri> element and
the <original-recipient-uri> element in the XML body of the
IMDN it received to determine if the IM was sent to multiple
recipients and to identify the IM Recipient that sent the IMDN.</t>
<t>An IM Sender can determine an IMDN is a disposition notification
by noting the Content-Disposition in the IMDN is "notification".
This does mean the IM Sender MUST understand the Content-Disposition
MIME header in CPIM messages.</t>
</section>
<section title="Keeping State">
<t>This specification does not mandate the IM Sender to keep state
for a sent IM.</t>
<t>Once an IM Sender sends an IM containing an IMDN request, it MAY
preserve the IM context, principally the Message-ID, and other
user-identifiable information such as the IM subject or content, and
date and time it was sent. Without preservation of the IM context,
the IM Sender will not be able to correlate the IMDN with the IM it
sent. The IM Sender may find it impossible to preserve IM state if
it has limited resources or does not have non-volatile memory and
then loses power.</t>
<t>There is, however, the concept of "Sent Items" box in an
application that stores sent IMs. This "Sent Items" box has the
necessary information and may have a fancy user interface indicating
the state of a sent IM. A unique Message-ID for this purpose proves
to be useful. The length of time for items to remain in the "Sent
Items" box is a user choice. The user is usually free to keep or
delete items from the "Sent Items" box as she pleases or as the
memory on the device reaches capacity.</t>
<t>Clearly, if an IM Sender loses its sent items state, for example,
the user deletes items from the "Send Items" box, the client may use
a different display strategy in response to apparently unsolicited
IMDNs.</t>
<t>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.</t>
<t>IMDNs may legitimately never be received. Likewise, the recipient
may take a long time to actually read the message, so the time
between the sending of an IM and the generation and ultimate receipt
of the IMDN may simply take a very long time. Some clients may
choose to purge the state associated with the sent IM. This is the
reason for adding the time stamp in the IM and having it returned in
the IMDN. This gives the user some opportunity of remembering what
IM was sent. For example if the IMDN indicates that the IM the user
sent at 2 p.m. last Thursday was delivered, the user has a chance of
remembering that they sent an IM at 2 p.m. last Thursday.</t>
</section>
<section title="Aggregation of IMDNs">
<t>An IM Sender may send an IM to multiple recipients in one
Transport Protocol Message (typically using a <xref
target="I-D.ietf-sip-uri-list-message">URI-List server</xref>) and
request IMDNs. An IM Sender that requested IMDNs MUST be prepared to
receive multiple aggregated or non-aggregated IMDNs. See <xref
target="aggregate-intermediary"></xref> for details.</t>
</section>
</section>
<section title="IM Recipient">
<section title="Constructing IMDNs">
<t>IM recipients examine the contents of the
Disposition-Notification header field of the CPIM message to
determine if the recipient needs to generate an IMDN for that IM.
Disposition-Notification header fields of CPIM messages can include
one or more values. IM recipients may need to generate zero, one, or
more IMDNs for that IM, for example a delivery notification as well
as a 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. That is, it must
not generate a delivery notification indicating "delivered" then
followed by a delivery notification indicating "failed" for the same
IM. If the IM Sender requested only failure notifications and the IM
was successfully delivered, then no IMDNs will be generated. If the
IM recipient does not understand a value of the
Disposition-Notification header field, the IM recipient ignores that
value.</t>
<t>The IM Recipient MUST NOT generate "processing"
notifications.</t>
<t>A Disposition-Notification header field MUST NOT appear in an
IMDN since it is forbidden to request an IMDN for an IMDN. An IM
Sender MUST ignore a delivery notification request in an IMDN if
present. The IM Sender MUST NOT send an IMDN for an IMDN.</t>
<t>An IMDN MUST contain a Message-ID header field. The same rules of
uniqueness for the Message-ID header field that appears in an IM
apply to an IMDN. The Message-ID header field in the IMDN is
different and unrelated to the one in the IM.</t>
<t>An IM may contain an IMDN-Record-Route header field (see <xref
target="intermediary-behaviour"></xref> for details). If
IMDN-Record-Route header fields appear in the IM, the IM Recipient
constructing the IMDN MUST copy the contents of the
IMDN-Record-Route header fields into IMDN-Route header fields in the
IMDN and maintain the order. The IMDN is then sent to the URI in the
top IMDN-Route header field. IMDN-Record-Route header fields do not
make sense in an IMDN and therefore MUST NOT be placed in an IMDN.
IMDN Recipients MUST ignore it if present.</t>
<t>As stated in <xref target="RFC3862">CPIM</xref>, CPIM messages
may need to support MIME headers other than Content-type. IM
Recipients MUST insert a Content-Disposition header field, set to
the value "notification". This indicates to the IM Sender that the
message is an IMDN to an IM it has earlier sent.</t>
<section anchor="generate-delivery-notification"
title="Constructing Delivery Notifications">
<t>The IM Recipient constructs a delivery notification in a
similar fashion as an IM, using a CPIM body <xref
target="RFC3862"></xref> that carries a Disposition Notification
XML document formatted according to the rules specified in <xref
target="imdn-format"></xref>. The MIME type of the Disposition
Notification XML document is "message/imdn+xml".</t>
<t><xref target="syntax"></xref> defines the schema for an
IMDN.</t>
<t>An example CPIM body of IMDN looks like the following:</t>
<figure>
<artwork><![CDATA[
From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: d834jied93rf
Content-type: message/imdn+xml
Content-Disposition: notification
Content-length: ...
<?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri>
im:bob@example.com
</original-recipient-uri>
<disposition>
<delivery/>
</disposition>
<status>
<delivered/>
</status>
<note lang="en">The IM was successfully Delivered</note>
</imdn>
]]></artwork>
</figure>
</section>
<section anchor="generate-read-notification"
title="Constructing Read Notifications">
<t>The IM Recipient constructs a read notification in a similar
fashion as the delivery notification. See <xref
target="generate-delivery-notification"></xref> for details.</t>
<t><xref target="syntax"></xref> defines the schema for an
IMDN.</t>
<t>An example looks like the following:</t>
<figure>
<artwork><![CDATA[
From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: dfjkleriou432333
Content-type: message/imdn+xml
Content-Disposition: notification
Content-length: ...
<?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri>
im:bob@example.com
</original-recipient-uri>
<disposition>
<read/>
</disposition>
<status>
<read/>
</status>
<note lang="en">The IM has been read</note>
</imdn>
]]></artwork>
</figure>
<t>There are situations where the IM Recipient cannot determine if
or when the IM has been read. The IM Recipient in this case
generates a read notification with a <status> value of
"error" to indicate an internal error by the server. Note that the
IM Recipient may choose to ignore any IMDN requests and not to
send any IMDNs. An IM recipient may not wish to let a sender know
she read, or did not read, a particular message. Likewise, she may
not want anyone to know if she reads messages. This could be on a
per-message, per-sender, or programmed policy choice.</t>
</section>
</section>
</section>
</section>
<section anchor="intermediary-behaviour" title="Intermediary Behaviour">
<t>In this context, intermediaries are application servers (including
URI-List servers and Store-and-Forward server) and gateways. A gateway
is a server that translates between different IM systems that use
different protocols.</t>
<t>A URI-List server may change the IM Recipient address from its own to
the address of the final recipient of that IM for every copy it makes
that it sends to the list members (see <xref
target="I-D.ietf-sip-uri-list-message"></xref> for details). In this
case, if the IM Sender is requesting an IMDN, the intermediary SHOULD
add an Original-To header field to the IM populating it with the address
that was in the CPIM To header field before it was changed. That is, the
intermediary populates the Original-To header field with the
intermediary address. Of course, one may configure an intermediary to
restrict it from re-writing or populating the Original-To field. An
intermediary MUST NOT add an Original-To header field if one already
exists. An intermediary MAY have an administrative configuration to not
reveal the original Request-URI, and as such, MUST NOT add an
Original-To header.</t>
<t>An intermediary MAY choose to remain on the path of IMDNs for a
specific IM. It can do so by adding a CPIM IMDN-Record-Route header
field as the top IMDN-Record-Route header field and populating it with
its own address. An intermediary that does not support this extension
will obviously not add the IMDN-Record-Route header field. This allows
IMDNs to traverse directly from the IM Recipient to the IM Sender even
if the IM traversed an intermediary not supporting this extension.</t>
<t>An intermediary receiving an IMDN checks the top IMDN-Route header
field. If that header field carries the intermediary address, the
intermediary removes that value and forwards the IMDN to the address
indicated in the now top IMDN-Route header field. If no additional
IMDN-Route header fields are present, the IMDN is forwarded to the
address in the CPIM To header field.</t>
<t>An intermediary MUST remove any information about the final
recipients of a list if the list membership is not disclosed. The
intermediary does that by removing the <recipient-uri> element
and/or <original-recipient-uri> element from the body of the IMDN
before forwarding it to the IM Sender.</t>
<section anchor="generate-processing-notification"
title="Constructing Processing Notifications">
<t>Intermediaries are the only entities that construct processing
notifications. They do so only if the IM Sender has requested a
"processing" notification by including a Disposition-Notification
header field with value "processing".</t>
<t>The intermediary can create and send "processing" notifications
indicating that an IM has been processed or stored. The intermediary
MUST NOT send more than one IMDN for the same disposition type. I.e.,
it must not send a "processing" notification indicating that an IM is
being "processed" followed by another IMDN indicating that the same IM
is "stored".</t>
<t>An intermediary constructs a "processing" notification in a similar
fashion as the delivery notification. See <xref
target="generate-delivery-notification"></xref> for details.</t>
<t>An example looks like the following:</t>
<figure>
<artwork><![CDATA[
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>
]]></artwork>
</figure>
<t>There are situations where the intermediary cannot know the fate of
an IM. The intermediary in this case generates a processing
notification with a <status> value of "error" to indicate
so.</t>
</section>
<section anchor="aggregate-intermediary" title="Aggregation of IMDNs">
<t>As previously described, URI-List servers are intermediaries.</t>
<t>A URI-List server may choose to aggregate IMDNs using local policy
for making such a decision or it may send individual IMDNs instead.
When a URI-List server receives an IM and decides to aggregate IMDNs,
it can wait for a configurable period of time or until all recipients
have sent the IMDN, whichever comes first, before the URI-List server
sends an aggregated IMDN. Note that some IMDNs, for example "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.</t>
<t>A URI-List server MAY choose to send multiple aggregated IMDNs. A
timer can be started and when it fires, the URI-List server can
aggregate whatever IMDNs it has so far for that IM, send the
aggregated IMDN and restart the timer for the next batch. This is
needed for scenarios where the IM Sender has requested more than one
IMDN for a specific IM, for example, delivery notifications as well as
read notifications, or when the URI-List server is short on resources
and chooses to prioritise forwarding IMs over IMDNs.</t>
<t>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.</t>
<t>Please note the references to timers in the above paragraphs are
not normative and are only present to help describe one way one might
implement aggregation.</t>
<t>A URI-List server MAY aggregate IMDNs for the case where the list
membership information is not disclosed. There may be scenarios where
the URI-List server starts sending aggregated IMDNs and switch to
individual ones or visa versa. A timer firing so often may in fact
have that effect.</t>
<t>The aggregated IMDN is constructed using the multipart/mixed MIME
type and including all the received IMDNs as message/imdn+xml as
individual payloads.</t>
<t>Below is an example of aggregated IMDNs.</t>
<figure>
<artwork><![CDATA[
From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: d834jied93rf
Content-type: multipart/mixed;
boundary="imdn-boundary"
Content-Disposition: notification
Content-length: ...
--imdn-boundary
Content-type: message/imdn+xml
<?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri>
im:bob@example.com
</original-recipient-uri>
<disposition>
<delivery/>
</disposition>
<status>
<delivered/>
</status>
<note lang="en">The IM was successfully Delivered</note>
</imdn>
--imdn-boundary
Content-type: message/imdn+xml
<?xml version="1.0" encoding="UTF-8"?>
<imdn xlmns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2006-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri>
im:bob@example.com
</original-recipient-uri>
<disposition>
<read/>
</disposition>
<status>
<read/>
</status>
<note lang="en">The IM was successfully Delivered</note>
</imdn>
--imdn-boundary
]]></artwork>
</figure>
</section>
</section>
<section anchor="identifying-messages" title="Identifying Messages">
<t>Messages are typically carried in a transport protocol like SIP <xref
target="RFC3261"></xref>. If the payload carried by the transport
protocol does not contain any parts of type Message/CPIM then the
message is an IM. If the payload contains any parts of type
Message/CPIM, and none of those parts contains a payload that is of type
"message/imdn+xml", the message is an IM. It is not valid to attempt to
carry both an IM and an IMDN in a multipart payload in a single
transport protocol message.</t>
<t>A message is identified as a delivery notification by examining its
contents. The message is a delivery notification if the Content-type
header field present has a value of "message/imdn+xml", the
Content-Disposition header field has a value of "notification", and the
<disposition> element in that xml body has a sub-element
<delivery>.</t>
<t>A message is identified as a processing notification or read
notification in a similar fashion as a delivery notification. The
difference is that the <disposition> element in that xml body has
a sub-element of <processing> and <read> respectively.</t>
</section>
<section anchor="syntax" title="Header Fields Formal Syntax">
<t>The following syntax specification uses the message header field
syntax as described in Section 3 of <xref target="RFC3862">RFC
3862</xref>. <vspace blankLines="1" /> Header field syntax is described
without a name space qualification. Following the rules in <xref
target="RFC3862">RFC 3862</xref>, header field names and other text are
case sensitive and MUST be used as given, using exactly the indicated
upper case and lower case letters.</t>
<figure>
<artwork><![CDATA[
Disposition-Notification =
"Disposition-Notification" ": "
[(notify-req *(COMMA notify-req))]
notify-req =
("negative-delivery" / "positive-delivery" /
"processing" / "read" / Token) *(SEMI disp-notif-params)
disp-notify-params = generic-param
Message-ID = "Message-ID" ": " Token
Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"
IMDN-Record-Route =
"IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
]]></artwork>
</figure>
</section>
<section anchor="imdn-format" title="IMDN Format">
<section title="Structure of XML-Encoded IMDN Payload">
<t>An IMDN Payload is an XML document <xref target="XML"></xref> that
MUST be well formed and MUST be valid according to schemas, including
extension schemas, available to the validater and applicable to the
XML document. The IMDN Payload MUST be based on XML 1.0 and MUST be
encoded using UTF-8. <vspace blankLines="1" /> The name space
identifier for elements defined by this specification is a URN <xref
target="URN"></xref>, using the name space identifier 'ietf' defined
by <xref target="URN_NS"></xref> and extended by <xref
target="IANA"></xref>. This urn is: urn:ietf:params:xml:ns:imdn.
<vspace blankLines="1" /> This name space declaration indicates the
name space on which the IMDN is based. <vspace blankLines="1" /> 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. <vspace blankLines="1" /><disposition> and
<status> can be extended in the future to include new
sub-elements not defined in this document, as described in <xref
target="S.schema"></xref>.</t>
<section title="The <message-id> Element">
<t>The <message-id> element is mandatory according to the XML
schema and carries the message id that appeared in the Message-ID
header field of the IM.</t>
</section>
<section title="The <datetime> Element">
<t>The <datetime> element is mandatory and carries the date
and time the IM was sent (not the IMDN). This information is
obtained from the DateTime header field of the IM.</t>
</section>
<section title="The <recipient-uri> Element">
<t>The <recipient-uri> element is optional and carries the URI
of the final recipient. This information is obtained from the CPIM
To header field of the IM.</t>
</section>
<section title="The <original-recipient-uri> Element">
<t>The <original-recipient-uri> element is optional and
carries the URI of the original recipient. It MUST be present if the
IM carried the Original-To header field. This information is
obtained from the Original-To header field of the IM.</t>
</section>
<section title="The <subject> Element">
<t>The <subject> element is optional and carries the text that
was in the Subject header field, if any. This allows for a human
level correlation between an IM and an IMDN.</t>
</section>
<section title="The <disposition> Element">
<t>The <disposition> element is mandatory and carries the
disposition type that the IM Sender requested and is being reported.
It can carry one of the sub-elements <delivery>,
<processing>, <read> or any other future extension.</t>
</section>
<section title="The <status> Element">
<t>The <status> element is mandatory and carries the result of
the disposition request in the <disposition> element. For
disposition type <delivery>, it can carry one of the
sub-elements <delivered>, <failed>, <forbidden> or
<error>. For disposition type <read>, it can carry one
of the sub-elements <read>, <forbidden> or
<error>. For disposition type <processing>, it can carry
one of the sub-elements <processed>, <stored>,
<forbidden> or <error>. <forbidden> means the
disposition was denied. <error> means internal server error.
It can also carry any other future extension.</t>
</section>
<section title="The <note> Element">
<t>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.</t>
</section>
</section>
<section anchor="mime-type" title="MIME Type for IMDN Payload">
<t>The MIME type for the IMDN Payload is "message/imdn+xml". The IMDN
MUST identify the payload as MIME type "message/imdn+xml" in the
Content-type header field.</t>
</section>
<section anchor="schema" title="The RelaxNG Schema">
<figure>
<artwork><![CDATA[<?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>
]]></artwork>
</figure>
</section>
</section>
<section title="Transporting Messages using SIP">
<section title="Endpoint Behaviour">
<section title="Sending Requests">
<t>The IM Sender constructs a SIP MESSAGE request using <xref
target="RFC3428">RFC 3428</xref>. 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 <xref
target="RFC3862">"message/cpim"</xref> for both IMs and IMDNs. The
IM Sender constructs the payload according to <xref
target="endpoint-behaviour"></xref>.</t>
<t>The IM Sender constructs a SIP MESSAGE request to multiple
recipients in a similar manner as a SIP MESSAGE request to a single
recipient. <xref
target="I-D.ietf-sip-uri-list-message">Multiple-Recipient MESSAGE
Requests in SIP</xref> describes the differences.</t>
<t>IM senders can remain anonymous. For example, the sender can set
the SIP From header field of the SIP message to an anonymous URI. As
there is no return address, anonymous IM senders SHOULD NOT request
disposition notifications. An IM Recipient can ignore such request
if the IM Sender is anonymous.</t>
</section>
<section title="Sending Responses">
<t>An endpoint receiving a SIP MESSAGE request constructs a SIP
response according to RFC 3428 <xref target="RFC3428"></xref>. Of
course, an endpoint will send a SIP response to the MESSAGE request
regardless of the type of message (IM or IMDN) is has received, or
the disposition type it has been asked for.</t>
</section>
<section title="Receiving Requests">
<section title="Instant Message">
<t>A SIP MESSAGE request is identified as an IM by examining its
contents according to <xref
target="identifying-messages"></xref>.</t>
<t>If an IM Recipient received a SIP MESSAGE request that is an IM
that requested a positive-delivery notification, and that IM
Recipient has constructed and sent a SIP 2xx class response, it
MAY generate a positive-delivery notification after making sure
that the IM has been delivered to the user or application. A
gateway, for example, can generate a 2xx response before the final
recipient received the IM. The IM Recipient constructs a
positive-delivery notification according to <xref
target="generate-delivery-notification"></xref>. The IM Recipient
places the message as the payload in a SIP MESSAGE request.</t>
<t>If an IM Recipient received a SIP MESSAGE request that is an IM
that requested a negative-delivery, and that IM Recipient has
constructed and sent a 2xx class response, it SHOULD generate a
negative-delivery notification if it learnt that the final
recipient or application did not receive the IM (a gateway, for
example, can generate a 2xx response before it has an error
response from downstream or before any internal timers fire
waiting for a response). The negative-delivery notification is
constructed according to <xref
target="generate-delivery-notification"></xref>. The message is
then placed as the payload in a SIP MESSAGE request. <vspace
blankLines="1" /> If an IM Recipient received a SIP MESSAGE
request that is an IM that requested a negative-delivery
notification, and the IM Recipient has constructed and sent an
non-2xx final response, it MUST NOT generate a negative-delivery
notification.</t>
<t>If an IM Recipient received a SIP MESSAGE request that is an IM
that requested a read notification, and that IM Recipient has
constructed and sent a SIP 2xx class response, it MAY generate a
read notification after making sure that the IM has been presented
to the user or application. It is outside the scope of this
document how such determination can be made. Note that the option
to send a read notification or not can be left to the user. An
application may allow a user to configure such choice. The IM
Recipient constructs the read notification according to <xref
target="generate-read-notification"></xref>. The IM Recipient
places the message as the payload in a SIP MESSAGE request.</t>
<t>For IMDNs, the IM Recipient populates the SIP Request-URI and
the SIP To header field using the address that appeared in the SIP
From header field in the IM.</t>
</section>
<section title="Delivery Notification">
<t>A SIP MESSAGE request is identified as delivery notification by
examining its contents according to <xref
target="identifying-messages"></xref>.</t>
</section>
<section title="Read Notification">
<t>A SIP MESSAGE request is identified as read notification by
examining its contents according to <xref
target="identifying-messages"></xref>.</t>
</section>
</section>
</section>
<section anchor="sip-intermediary-behaviour"
title="Intermediary Behaviour">
<t>In this context, intermediaries include application servers,
including URI-List servers, Store-and-Forward servers, and gateways.
SIP Proxies MUST NOT generate IMDNs but MUST forward them like any
other SIP request.</t>
<t>Intermediaries forward a SIP MESSAGE request to multiple recipients
according to <xref target="I-D.ietf-sip-uri-list-message"></xref>.</t>
<t>If an intermediary receives an IM, the intermediary examines the
body. If the body is of type "message/cpim" the intermediary then
looks for a Disposition-Notification CPIM header field in the message.
If the Disposition-Notification CPIM header field has either the value
"positive-delivery" or "negative-delivery", and, in processing the IM,
the intermediary generates a SIP 2xx class response to the MESSAGE
request, then the intermediary performs the following actions.</t>
<t>If the Disposition-Notification header field contains a value of
"positive-delivery", the intermediary MUST NOT generate a delivery
notification if it receives a SIP 2xx class response for the sent IM.
Just because a downstream entity received a MESSAGE request does not
mean the message was relayed to its ultimate destination or was
delivered. Thus, the intermediary cannot say delivery occurred just
because it received a 2xx response.</t>
<t>If the Disposition-Notification header field contains a value of
"negative-delivery", the intermediary SHOULD generate a delivery
notification if it receives a SIP 4xx, 5xx or 6xx class final response
for the sent IM. If it has received a SIP 2xx class response followed
by a negative-delivery notification, the intermediary forwards that
negative-delivery notification or aggregates it.</t>
<t>If the Disposition-Notification header field contains a value of
"processing", the intermediary MAY generate a processing notification
after it has forwarded or stored the IM. The rest of the procedures in
<xref target="generate-processing-notification"></xref> apply.</t>
<t>The procedure for generating such IMDN is the same as that of an IM
Recipient (<xref target="generate-delivery-notification"></xref>).
<vspace blankLines="1" /> The <recipient-uri> element of the XML
body is populated with the URI of the IM Recipient.</t>
<t>If an intermediary receives a SIP MESSAGE request carrying a
positive delivery notification or a read notification, it forwards it
using the rules in <xref target="intermediary-behaviour"></xref>.</t>
</section>
</section>
<section title="Transporting Messages using MSRP">
<t>MSRP already provides a built-in mechanism to supply positive and
negative delivery reports. These reports do not provide built-in Read or
Processing notifications. However, these notifications in session mode
are not as useful as they are for page-mode. This is because the base
use case for MSRP is that the recipient user agent immediately renders
SEND requests sequentially, providing the session experience. This is
unlike page-mode requests where a user has to actively read the message.
That is, they need to click on a button, open a message, and so on to
read the message.</t>
<t>If new requirements arise in the future determining the need for IMDN
in MSRP, new specifications can be drafted.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>IMDNs provide a fine-grained view of the activity of the IM Recipient
and thus deserves particularly careful confidentiality protection so
that only the intended recipient of the IMDN will receive the IMDN. In
most cases, the intended recipient of the IMDN is the IM Sender.</t>
<t>Since the IM transport protocol carries the IMDN, all security
considerations of the underlying IM protocol also apply to the
IMDNs.</t>
<t>The threats in the IMDN system, over and beyond the threats inherent
to IM include the following: <list style="symbols">
<t>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.</t>
<t>A malicious endpoint attempts to flood an IM Sender with IMDNs by
convincing a URI-List server to send IMDNs to an unsuspecting IM
Sender.</t>
<t>A malicious node in the network that attempts to modify an IMDN
from an IM Recipient.</t>
<t>A malicious intermediary attempts to forward an IMDN from an IM
Recipient to the IM Sender, where the IM Recipient would not
normally forward the IMDN to that IM Sender if the IM Recipient knew
the identity of the IM Sender.</t>
<t>A malicious endpoint that attempts to discover for a Request-URI
of an endpoint beyond an intermediary, where the endpoint would
normally wish to keep its identity private from the malicious
endpoint.</t>
<t>A malicious node in the network that attempts to eavesdrop on
IMDN traffic to, for example, learn Request-URI or traffic pattern
information.</t>
<t>A malicious node in the network attempts to stage a denial of
service attack on an intermediary by requesting a large list
expansion.</t>
</list></t>
<t>The protocol cannot protect against attacks that include the
following: <list style="symbols">
<t>A malicious intermediary directly revealing the identity of a
downstream endpoint that would not normally wish its identity
revealed. Keeping such information private is an intermediary
implementation issue.</t>
<t>A malicious IM Recipient that alters the time of the IMDN. There
is no protocol mechanism for ensuring that the IM Recipient does not
lie about the time or purposely holds an IMDN for transmission to
make it appear that the user read an IM later than they actually
did.</t>
<t>A deletion attack on an IMDN. This is a trade-off between privacy
and security. The privacy considerations allow the IM Recipient to
silently ignore an IMDN request. Any mechanism that would reliably
indicate that a malicious node deleted an IM Recipient's IMDN would
also serve the purpose of detecting an IM Recipient that chose not
to issue an IMDN.</t>
</list></t>
<t>To combat eavesdropping, modification, and man-in-the-middle attacks,
we require some level of authentication and integrity protections. That
said, there are circumstances where strong integrity would be overkill.
The presumption is the IM Sender has and sets the expectation for the
level of protection. The procedures for integrity protection are as
follows. <list style="symbols">
<t>If the IM Recipient has a certificate, it MUST sign the IMDN.
Signing the IMDN provides integrity protection. While an
intermediary can replace the IMDN body, the IM Sender (the recipient
of the IMDN) can validate the signature and note the IMDN does not
come directly from the IM Receiver. This is not a problem if the IM
Sender trusts the intermediary. Likewise, an IMDN in response to a
signed IM without a signature indicates something bad might have
happened.</t>
<t>If the IM is encrypted, the IM Recipient or intermediary MUST
encrypt the IMDN body, as an attacker may attempt to discern the
user's activity profile and identity from sniffing IMDNs on the
network.</t>
<t>The two above rules are cumulative.</t>
</list>The IM Recipient or intermediary MUST be capable of accessing
the IM Sender's public certificate in order to verify the signature in
the IM.</t>
<t><xref target="RFC3862">CPIM security considerations</xref> apply
here, as this is an extension of CPIM. In order to make the IMDN
mechanism independent of the transport protocol, the Work Group made the
design choice of putting routing information into the IMDN application
layer payload. One consequence of this choice is it eliminates the
possibility of having end-to-end encryption.</t>
<t>An attacker can mount a distributed denial of service attack on a
node by sending lots of IMs to the node with IMDN requests. Note that
this is the same problem as there is without IMDN; IMDN simply linearly
increases the load on the node under attack. One can mitigate, but not
eliminate this threat by the endpoint immediately ignoring requests that
are not authenticated.</t>
<t>Likewise, an attacker can mount a denial of service attack on an
intermediary by asking the intermediary to explode a large list.</t>
<t>The following security considerations apply when using IMDNs:</t>
<section title="Forgery">
<t>IMs can be forged. To protect against that, an IM can be signed. An
intermediary that receives a signed message and needs to modify any
part of it that is included in the signature (like adding an
Original-To header field to the CPIM header fields), MUST consume the
IM and create a new copy of it that the intermediary signs itself.
<vspace blankLines="1" /> IMDNs may be forged as easily as ordinary
IMs. Endpoints and intermediaries that wish to make automatic use of
IMDNs should take appropriate precautions to minimize the potential
damage from denial-of-service attacks. Security threats related to
forged IMDNs include the sending of a falsified IMDN when the
indicated disposition of the IM has not actually occurred. For
example, read notification could be forged to indicate that an IM
Recipient has read the IM. Unsolicited IMDNs is also another form of
forgery.</t>
</section>
<section title="Confidentiality">
<t>There may be cases where an IM Recipient does not wish to reveal
the information that he has received or in fact read the IM. In this
situation, it is acceptable for the IM Recipient to silently ignore
requests for an IMDN. It is strongly RECOMMENDED that the IM Recipient
obtain the user's consent before sending an IMDN. Circumstances where
the IM Recipient does not ask for the user's consent include IM
systems that, for regulatory reasons, are required to issue an IMDN,
such as in the health care field or financial community.</t>
<t>An IM Recipient can obtain such consent by a prompt or dialog box
on a per-IM basis, globally through the user's setting of a
preference, or other, user-configurable mechanism. The user might also
indicate globally that IMDNs are never to be sent or that a
"forbidden" IMDN status is always sent in response to a request for an
IMDN.</t>
<t>There are situations where a user sends an IM and requests IMDNs to
a list whose member information is not disclosed. In this situation,
the user will learn of the list members. Therefore, in this case, the
URI-List server MUST remove any information about list members. If the
number of members in the list is also not disclosed, the URL-List
server MUST only deliver one aggregated IMDN. Alternatively, the
URI-list server MAY reject the IM.</t>
<t>It is possible for a list server to not understand IMDN. IM
Recipients may note the To is a list name and not the IM Recipient's
name. In this case, the IM Recipient can take the appropriate action
if it wishes to keep its identity private.</t>
<t>An unencrypted IMDN could reveal confidential information about an
encrypted IM. The same level of security applied to an IM MUST be
applied to its IMDNs. For example, if an IM is signed and encrypted,
the IMDN must be signed and encrypted.</t>
</section>
<section title="Non-Repudiation">
<t>IMDNs cannot be relied on as a guarantee that an IM was or was not
seen by the user. Even if IMDNs are not actively forged, they may be
lost in transit. Moreover, the IM Recipient may bypass the IMDN
issuing mechanism through policy or manipulation of their User Agent
Server.</t>
</section>
</section>
<section title="IANA Considerations">
<section title="message/imdn+xml MIME TYPE">
<t>This document registers a new MIME type "message/imdn+xml", and
registers a new XML name space. <vspace blankLines="1" /> This
specification follows the guidelines of <xref target="RFC3023">RFC
3023</xref>. <vspace blankLines="1" /> MIME media type: message
<vspace blankLines="1" /> MIME subtype name: imdn+xml <vspace
blankLines="1" /> Mandatory parameters: none <vspace blankLines="1" />
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 <xref target="RFC3023"></xref>. <vspace
blankLines="1" /> Encoding considerations: Same as encoding
considerations of application/xml as specified in RFC 3023 <xref
target="RFC3023"></xref>. <vspace blankLines="1" /> Security
considerations: See section 10 of RFC 3023 <xref
target="RFC3023"></xref> and <xref target="security"></xref> of this
document. <vspace blankLines="1" /> Interoperability considerations:
none. <vspace blankLines="1" /> Published specification: This
document. <vspace blankLines="1" /> Applications which use this media
type: This document type is used to support CPIM based instant
messaging. <vspace blankLines="1" /> Additional information: None
<vspace blankLines="1" /> Magic number: None <vspace blankLines="1" />
File extension: .cl or .xml <vspace blankLines="1" /> Macintosh file
type code: "TEXT" <vspace blankLines="1" /> Personal and email address
for further information: Hisham Khartabil (hisham.khartabil@gmail.com)
<vspace blankLines="1" /> Intended Usage: COMMON <vspace
blankLines="1" /> Author/change controller: The IETF .</t>
</section>
<section title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:imdn">
<t>This section registers a new XML name space, as per guidelines in
the IETF XML Registry <xref target="IANA"></xref>. <vspace
blankLines="1" /> URI: The URI for this name space is
urn:ietf:params:xml:ns:imdn. <vspace blankLines="1" /> Registrant
Contact: IETF, SIMPLE working group, Hisham Khartabil
(hisham.khartabil@gmail.com) .</t>
</section>
<section anchor="S.schema" title="Schema Registration">
<t>This section registers a new XML schema per the procedures in <xref
target="IANA"></xref>. Extensions MUST be standards track
documents.<vspace blankLines="1" /> URI: urn:ietf:params:xml:ns:imdn
<vspace blankLines="1" /> Registrant Contact: IETF, SIMPLE working
group, Hisham Khartabil (hisham.khartabil@gmail.com) <vspace
blankLines="1" /> The XML for this schema can be found as the sole
content of <xref target="schema"></xref>.</t>
</section>
<section title="Registration for urn:ietf:params:imdn">
<t>Registry name: imdn <vspace blankLines="1" /> Specification: RFC
XXXX. Additional values may be defined by standards track RFCs that
update or obsolete RFC XXXX (Specification Required). <vspace
blankLines="1" /> Repository: http://www.iana.org/assignments/imdn
<vspace blankLines="1" /> Index value: The index value is a CPIM
message IMDN header name, which may consist of a sequence from a
restricted set of US-ASCII characters, as defined above. <vspace
blankLines="1" /> URN Formation: The URI for a header is formed from
its name by: <list>
<t>a) replacing any non-URN characters (as defined by RFC
2141<xref target="URN"></xref>) with the corresponding '%hh'
escape sequence (per <xref target="RFC2396">RFC 3986</xref>);
and</t>
<t>b) prepending the resulting string with
'urn:ietf:params:imdn:'.</t>
</list> <vspace blankLines="1" /> Thus, the URI corresponding to the
CPIM message IMDN header 'Disposition-Notification:' would be
'urn:ietf:params:imdn:Disposition-Notification'.</t>
</section>
<section title="Message/CPIM Header Field Registration">
<t>This document registers the following message/cpim header fields in
the imdn fields registry: <vspace blankLines="1" />
Disposition-Notification - [RFCXXXX] <vspace blankLines="1" />
Message-ID - [RFCXXXX] <vspace blankLines="1" /> Original-To -
[RFCXXXX] <vspace blankLines="1" /> IMDN-Record-Route - [RFCXXXX]
<vspace blankLines="1" /> IMDN-Route - [RFCXXXX]</t>
</section>
<section title="Content-Disposition: notification">
<t>This document registers one new Content-Disposition header field
"disposition-types": notification. The authors request that this value
be recorded in the IANA registry for Content-Dispositions. <vspace
blankLines="1" /> Descriptions of this "disposition-types", including
motivation and examples, are given in <xref
target="generate-delivery-notification"></xref> and <xref
target="identifying-messages"></xref>. <vspace blankLines="1" /> Short
descriptions suitable for the IANA registry are: <vspace
blankLines="1" /> notification the body of the message is a
notification according to an earlier request for a disposition
notification to an instant message</t>
</section>
</section>
<section anchor="Ack" title="Acknowledgements">
<t>The authors would like to thank Paul Kyzivat, Ben Campbell, Adam
Roach, Gonzalo Camarillo, Sean Olson, Eva Leppanen, Miguel Garcia, Eric
McMurry, Jari Urpalainen, Jon Peterson, and Robert Sparks for their
comments and support. In addition, we would like to thank the Gen-Art
reviewer extrodinaire, Spencer Dawkins.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement
Levels</title>
<author initials="S." surname="Bradner">
<organization></organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="RFC3862">
<front>
<title>Common Presence and Instant Messaging (CPIM): Message
Format</title>
<author initials="G." surname="Klyne">
<organization></organization>
</author>
<author initials="D." surname="Atkins">
<organization></organization>
</author>
<date month="August" year="2004" />
</front>
<seriesInfo name="RFC" value="3862" />
</reference>
<reference anchor="IANA">
<front>
<title>The IETF XML Registry</title>
<author initials="M." surname="Mealling">
<organization></organization>
</author>
<date month="January" year="2004" />
</front>
<seriesInfo name="RFC" value="3688" />
</reference>
<reference anchor="URN">
<front>
<title>The URN Syntax</title>
<author initials="R." surname="Moats">
<organization></organization>
</author>
<date month="May" year="1997" />
</front>
<seriesInfo name="RFC" value="2141" />
</reference>
<reference anchor="RFC3023">
<front>
<title>XML Media Types</title>
<author initials="M" surname="Murata">
<organization></organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="3023" />
</reference>
<reference anchor="XML">
<front>
<title>Extensible Markup Language (XML) 1.0 (Second Edition)</title>
<author initials="T." surname="Bray">
<organization></organization>
</author>
<date month="October" year="2000" />
</front>
<seriesInfo name="" value="W3C CR CR-xml11-20011006" />
</reference>
<reference anchor="RFC2396">
<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifier
(URI): Generic Syntax</title>
<author fullname="Tim Berners-Lee" initials="T."
surname="Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web
Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country>
</postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri>
</address>
</author>
<author fullname="Roy T. Fielding" initials="R." surname="Fielding">
<organization abbrev="Day Software">Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country>
</postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri>
</address>
</author>
<author fullname="Larry Masinter" initials="L." surname="Masinter">
<organization abbrev="Adobe Systems">Adobe Systems
Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country>
</postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri>
</address>
</author>
<date month="January" year="2005" />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of
characters that identifies an abstract or physical resource. This
specification defines the generic URI syntax and a process for
resolving URI references that might be in relative form, along
with guidelines and security considerations for the use of URIs on
the Internet. The URI syntax defines a grammar that is a superset
of all valid URIs, allowing an implementation to parse the common
components of a URI reference without knowing the scheme-specific
requirements of every possible identifier. This specification does
not define a generative grammar for URIs; that task is performed
by the individual specifications of each URI scheme.</t>
</abstract>
</front>
<seriesInfo name="STD" value="66" />
<seriesInfo name="RFC" value="3986" />
<format octets="141811"
target="ftp://ftp.isi.edu/in-notes/rfc3986.txt" type="TXT" />
<format octets="213584"
target="http://xml.resource.org/public/rfc/html/rfc3986.html"
type="HTML" />
<format octets="163534"
target="http://xml.resource.org/public/rfc/xml/rfc3986.xml"
type="XML" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials="J." surname="Rosenberg et al.">
<organization></organization>
</author>
<author initials="H." surname="Shulzrinne">
<organization></organization>
</author>
<author initials="G." surname="Camarillo">
<organization></organization>
</author>
<author initials="A." surname="Johnston">
<organization></organization>
</author>
<author initials="J." surname="Peterson">
<organization></organization>
</author>
<author initials="R." surname="Sparks">
<organization></organization>
</author>
<author initials="M." surname="Handley">
<organization></organization>
</author>
<author initials="E." surname="Schooler">
<organization></organization>
</author>
<date month="June" year="2002" />
</front>
<seriesInfo name="RFC" value="3261" />
</reference>
<reference anchor="RFC3428">
<front>
<title>SIP Extension for Instant Messaging</title>
<author initials="B." surname="Campbell">
<organization></organization>
</author>
<date month="December" year="2002" />
</front>
<seriesInfo name="RFC" value="3428" />
</reference>
<reference anchor="RFC2821">
<front>
<title>Simple Mail Transfer Protocol</title>
<author initials="J." surname="Klensin">
<organization></organization>
</author>
<date month="April" year="2001" />
</front>
<seriesInfo name="RFC" value="2821" />
</reference>
<reference anchor="RFC3798">
<front>
<title>Message Disposition Notification</title>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization></organization>
</author>
<author fullname="G. Vaudreuil" initials="G." surname="Vaudreuil">
<organization></organization>
</author>
<date month="May" year="2004" />
</front>
<seriesInfo name="RFC" value="3798" />
</reference>
<reference anchor="URN_NS">
<front>
<title>The URN Namespace for IETF Documents</title>
<author initials="R." surname="Moats">
<organization></organization>
</author>
<date month="August" year="1999" />
</front>
<seriesInfo name="RFC" value="2648" />
</reference>
<reference anchor="I-D.ietf-sip-uri-list-message">
<front>
<title>Multiple-Recipient MESSAGE Requests in the Session Initiation
Protocol (SIP)</title>
<author fullname="Miguel Garcia-Martin" initials="M"
surname="Garcia-Martin">
<organization></organization>
</author>
<author fullname="Gonzalo Camarillo" initials="G"
surname="Camarillo">
<organization></organization>
</author>
<date day="21" month="December" year="2007" />
<abstract>
<t>This document specifies a mechanism that allows a SIP User
Agent Client (UAC) to send a SIP MESSAGE request to a set of
destinations, by using a SIP URI-list (Uniform Resource Identifier
list) service. The UAC sends a SIP MESSAGE request that includes
the payload along with the URI list to the MESSAGE URI-list
service, which sends a MESSAGE request including the payload to
each of the URIs included in the list.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-sip-uri-list-message-03" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-list-message-03.txt"
type="TXT" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 22:46:33 |