One document matched: draft-khartabil-simple-im-report-00.txt
SIMPLE H. Khartabil
Internet-Draft Telio
Expires: November 5, 2005 May 4, 2005
Instant Message Delivery and Read Reports
draft-khartabil-simple-im-report-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 5, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Instant Messaging (IM) refers to the transfer of messages between
users in near real-time.
This document extends Message/CPIM message format to enable endpoints
to request, create and send a delivery report as well as a read
report for a page-mode as well as session mode instant messages.
This document also describes how SIP entities behave using this
extension.
Khartabil Expires November 5, 2005 [Page 1]
Internet-Draft IM Delivery and Read Reports May 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Constructing Requests . . . . . . . . . . . . . . . . . . . . 3
3.1 Instant Message . . . . . . . . . . . . . . . . . . . . . 3
3.2 Delivery Report . . . . . . . . . . . . . . . . . . . . . 4
3.3 Read Report . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Identifying Messages . . . . . . . . . . . . . . . . . . . 6
4. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 6
5. Status Report XML Schema . . . . . . . . . . . . . . . . . . . 6
5.1 Structure of XML-Encoded status-report . . . . . . . . . . 6
5.2 MIME Type for status-report Document . . . . . . . . . . . 7
5.3 The XML Schema . . . . . . . . . . . . . . . . . . . . . . 7
6. Transporting Message/CPIM messages using SIP . . . . . . . . . 7
6.1 Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 7
6.1.1 Sending Requests . . . . . . . . . . . . . . . . . . . 7
6.1.2 Sending Responses . . . . . . . . . . . . . . . . . . 7
6.1.3 Receiving Requests . . . . . . . . . . . . . . . . . . 8
6.2 Intermediary Behaviour . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1 Normative References . . . . . . . . . . . . . . . . . . . 9
10.2 Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Khartabil Expires November 5, 2005 [Page 2]
Internet-Draft IM Delivery and Read Reports May 2005
1. Introduction
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 a delivery report as well as a read report
for a page-mode as well as session mode instant messages. This
document also describes how SIP [9] 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. Constructing Requests
3.1 Instant Message
A Message/CPIM formatted instant message is contructed using RFC 3862
[2]. The content-type header field indicates the MIME type of the
request payload.
In this extension, the Message/CPIM MUST contain a Message-ID header
if a delivery or read report is requested. The Message-ID field is
populated with a value that is random is space and time. This header
field enables the message sender to match any delivery and/or read
reports and need not be present if the instant message sender is not
requesting any reports.
The sender can request two types of delivery reports: a failure
delivery report and a success delivery report. A failure delivery
report is requested by including a Receipt-Request header field with
value "negative-delivery". Similarly, a success report is requested
by including a Receipt-Request header field with value "positive-
delivery". Both types of reports can be requested for the same
message.
The sender can also request a read report. It is requested by
including a Receipt-Request 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 reports. This
aids receivers of instant messages that do not support this feature.
Khartabil Expires November 5, 2005 [Page 3]
Internet-Draft IM Delivery and Read Reports May 2005
The Receipt-Request header fields can be comma separated.
The default Content-Disposition of an instant message is "render".
Therefore, the absence of such header indicates "render".
If an endpoint sending an Instant message and has requested a
positive-delivery, negative-delivery and/or read report, it MUST NOT
start any timers.
The formal syntax of the Request-Receipt header field can be found in
Section 4. The following in an example Message/CPIM instant message
where the user requests positive and negative delivery reports, but
not read report:
Content-type: Message/CPIM
From: Alice <im:alice@example.com>
To: Bob <im:bob@example.com>
Message-ID: 34jk324j
Receipt-Request: positive-delivery, negative-delivery
Content-type: text/plain
Content-length: 12
Hello World
3.2 Delivery Report
A delivery report is constructed in a similar fashion as an instant
message, using RFC 3862 [2]. For delivery reports, the content-type
MUST be of type "message/status-report". It is an XML document. The
schema is described Section 5. The delivery report MUST contain a
Content-Disposition header field with value "confirm". This
indicates to the receiver that the contents of the message are a
confirmation according to an earlier request for a report to an
instant message. The recipient SHOULD render to the end user a
message indicating such confirmation.
The delivery report SHOULD NOT contain a Message-ID header field.
An example looks like the following:
Khartabil Expires November 5, 2005 [Page 4]
Internet-Draft IM Delivery and Read Reports May 2005
Content-type: Message/CPIM
From: Bob <im:bob@example.com>
To: Alice <im:alice@example.com>
Content-type: message/status-report
Content-Disposition: confirm
Content-length: ...
<status-report>
<message-id>34jk324j</message-id>
<recipient-uri>bob@example.com</recipient-uri>
<type>delivery</type>
<status>200</status>
<note lang="en">The message was successfully Delivered</note>
</status-report>
Request-Receipt header MUST NOT appear in a Message/CPIM messages
that represents a delivery report.
3.3 Read Report
A read report is constructed in a similar fashion as the delivery
report. See Section 3.2 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/status-report
Content-Disposition: confirm
Content-length: ...
<status-report>
<message-id>34jk324j</message-id>
<recipient-uri>bob@example.com</recipient-uri>
<type>read</type>
<status>200</status>
<note lang="en">The message has been read</note>
</status-report>
Request-Receipt header MUST NOT appear in a Message/CPIM messages
that represents a read report.
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 report with a <status> value of "485".
Khartabil Expires November 5, 2005 [Page 5]
Internet-Draft IM Delivery and Read Reports May 2005
This indicates that the result of the read report request cannot be
determined or is ambiguous.
3.4 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 "application/status-report+xml".
A Message/CPIM message is identified as a delivery report by
examining its contents. In the case of a "message/cpim" body, the
message is a delivery report if: the content-type header field
present in the message/cpim body has a value of "application/
status-report+xml", the Content-Disposition header field has a value
of "render", and the <type> element in that xml body has a value of
"delivery". An endpoint matches a delivery report to an instant
message by matching the Message-ID header field value with the
<message-id> element value in the body of the delivery report. If
the message was delivered to multiple recipients, the <recipient-uri>
element in the XML body is used to identify the recipient.
A Message/CPIM message request is identified as a read report and is
matched to an instant message in a similar fasion as a delivery
report. The difference is that the <type> element in that xml body
has a value of "read".
4. Header Fields Formal Syntax
The following syntax specification uses the message header syntax as
described in Section 3 of RFC3862 [2].
Receipt-Request =
"Receipt-Request" ": " (receipt-req *(COMMA receipt-req))
receipt-req = "negative-delivery" / "positive-delivery" / "read"
Message-ID = "Message-ID" ": " Token
5. Status Report XML Schema
5.1 Structure of XML-Encoded status-report
A status-report 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
status-report documents MUST be based on XML 1.0 and MUST be encoded
Khartabil Expires November 5, 2005 [Page 6]
Internet-Draft IM Delivery and Read Reports May 2005
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:status-report.
This namespace declaration indicates the namespace on which the
status report is based on.
5.2 MIME Type for status-report Document
The MIME type for the status-report document is "application/
status-report+xml". The SIP [9] MESSAGE request [10] that is used to
carry the status report that also carries payload type information
MUST identify the payload as MIME type "simple-filter+xml" in the
Content-Type header field.
5.3 The XML Schema
6. Transporting Message/CPIM messages using SIP
6.1 Endpoint Behaviour
6.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]. The payload is contructed
according to Section 3.1.
A SIP MESSAGE request to multiple recipients is contracted in a
similar manner as SIP MESSAGE request to a single recipient. The
differences are indicated in [12].
6.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 receipt it has been
asked for or the type of MESSAGE request it has received (instant
message or report).
Khartabil Expires November 5, 2005 [Page 7]
Internet-Draft IM Delivery and Read Reports May 2005
6.1.3 Receiving Requests
6.1.3.1 Instant Message
A SIP MESSAGE request is identified as an instant message by
examining its contents according to Section 3.4.
If an endpoint received a SIP MESSAGE request that contains a Messge/
CPIM payload that requested a positive-report, and that endpoint has
constructed and sent a SIP 2xx class response, it MUST generate a
positive-report 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-report is
constructed according to Section 3.2. 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-report, and that endpoint has
constructed and sent an 2xx class response, it MUST generate a
negative-report 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-report is
constructed according to Section 3.3. 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-report, and the endpoint has constructed and sent an error
response, it MUST NOT generate a negative-report.
6.1.3.2 Delivery Report
A SIP MESSAGE request is identified as delivery report by examining
its contents according to Section 3.4.
6.1.3.3 Read Report
A SIP MESSAGE request is identified as read report by examining its
contents according to Section 3.4.
6.2 Intermediary Behaviour
An intermediary that behaves as an application server or a gateway
needs to conform to this section.
A SIP MESSAGE request to multiple recipients is forwarded according
to [12].
Khartabil Expires November 5, 2005 [Page 8]
Internet-Draft IM Delivery and Read Reports May 2005
If an intermediary generates a SIP 2xx class response to a SIP
MESSAGE request it has received that is an instant message, it
examines if the body was of type "message/cpim". If so, it checks if
there is the header Receipt-Request with a value "positive-delivery"
and/or "negative-delivery". If so, it needs to send a delivery
report as soon as it receives a transactional response for the
instant message. The contruction of a delivery report is performed
according to Section 3.2.
If the Receipt-Request contains a value of "positive-delivery", the
intermediary MUST NOT generate a delivery report 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 Receipt-Request contains a value of "negative-delivery", the
intermediary MUST generate a delivery report 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
report. The generation of such report is the same procedure as that
for an endpoint (Section 3.2).
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-
report, it statelessly forwards that request.
7. Security Considerations
8. IANA Considerations
9. Acknowledgements
The author would like to thank Paul Kyzivat, Ben Campbell, Adam Roach
and Gonzalo Camarillo for their comments and support.
10. References
10.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.
Khartabil Expires November 5, 2005 [Page 9]
Internet-Draft IM Delivery and Read Reports May 2005
[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.
10.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.
[12] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in SIP", draft-ietf-sipping-uri-list-message-02,
November 2004.
Author's Address
Hisham Khartabil
Telio
P.O. Box 1203 Vika
Oslo
Norway
Phone: +47 2167 3544
Email: hisham.khartabil@telio.no
Khartabil Expires November 5, 2005 [Page 10]
Internet-Draft IM Delivery and Read Reports May 2005
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 (2005). 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.
Khartabil Expires November 5, 2005 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-22 23:37:32 |