One document matched: draft-burger-simple-im-cancel-request-00.txt
SIMPLE E. Burger
Internet-Draft BEA Systems, Inc.
Intended status: Standards Track August 17, 2007
Expires: February 18, 2008
Instant Message Cancellation Suggestion
draft-burger-simple-im-cancel-request-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 February 18, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes a mechanism for a user agent client to
request the marking of a previously sent Instant Message as
cancelled. From a user's perspective, the user agent server, or
other proxies or relay points in the network, can effectively remove
the first message, giving the impression the first message was
cancelled. This document describes the utility of such a function,
as well as the futility of attempting to create a true message
cancellation feature.
Burger Expires February 18, 2008 [Page 1]
Internet-Draft IM Cancel August 2007
Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
This document uses the term "server" to refer to the user agent
server acting on behalf of a message recipient. The term "client"
refers to the user agent client acting on behalf of a message sender.
The term "sender" refers to the person or automaton that requests the
user agent client to send a message. The term "recipient" refers to
the person or automaton that receives the message from the client, as
processed and displayed by the server. The term "first message" is a
message a client sends to a server that will become of interest to
the client in that it will want to cancel delivery of that first
message. The terms "cancellation suggestion," "cancellation
request," "recall message," "cancel message," and "cancellation
message" are all interchangeable notations for a message sent by the
client to the server to suggest to the server to cancel a first
message.
This document refers generically to the sender of a message in the
masculine (he/him/his) and the recipient of the message in the
feminine (she/her/hers). This convention is purely for convenience
and makes no assumption about the gender of a message sender or
recipient.
Burger Expires February 18, 2008 [Page 2]
Internet-Draft IM Cancel August 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Things We Cannot Do . . . . . . . . . . . . . . . . . . . 5
2.2. Things We Can Do . . . . . . . . . . . . . . . . . . . . . 5
2.3. Instant Message Overview . . . . . . . . . . . . . . . . . 6
2.4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Detailed Client Behavior . . . . . . . . . . . . . . . . . 9
3.2. Detailed Server Behavior . . . . . . . . . . . . . . . . . 10
3.3. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . . . 12
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6.1. Schema and Namespace . . . . . . . . . . . . . . . . . . . 14
6.2. Registration of MIME Media Type . . . . . . . . . . . . . 14
6.3. New Content-Disposition Parameter . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Burger Expires February 18, 2008 [Page 3]
Internet-Draft IM Cancel August 2007
1. Introduction
Some proprietary electronic mail systems provide mechanisms for
canceling the delivery of a message after the user sends a first
message. Some people call this "recalling a message." Users have
demanded this feature, most often to cancel messages sent in error,
to cancel a message they wish to supercede with another message, or
to cancel the future delivery of a message. Although a useful
feature, there are a number of practical problems implementing the
feature. For example, in the user guide [4] for a common proprietary
electronic mail system, about 50% of the text describes why a cancel
(recall) request may not work. This is more especially worth
mentioning given the proprietary electronic mail system identified
above is in a closed, controlled environment. These issues are even
more difficult to overcome when interworking messaging systems in
separate administrative domains.
Some issues to consider include:
o Race conditions: If the recipient has already received and read
the message, it is not possible to make that message go away, or,
for that matter, force the recipient to forget they read the
message.
o Security: Such a mechanism must reliably ensure that the sender
and only the sender may issue a cancel request.
o Non-repudiation: Such a mechanism must not allow someone to send a
message, have it read by the recipient, and then make the message
silently disappear without a trace.
o User expectations: Users must understand they are, at best, asking
politely for their previously sent message to be ignored. There
is a very high likelihood their request will be denied due to
policy, recipient choice, or the fact the recipient already read
the message before the sender makes the cancel message request.
One might reasonably ask, "Why not just send another user-level
message saying, 'Ignore That'?" The reason is simple. There will be
deployments where policy encourages cancellation, paired with
implementations that do cancellation. In this case, a standard
request format will facilitate interoperation.
The challenge is this: how to provide the functionality the market
demands, without over-promising too much to users, while maintaining
security, privacy, and non-repudiation of sent messages, in a secure,
reliable manner. This document describes such a mechanism for
Instant Message (IM) systems.
Burger Expires February 18, 2008 [Page 4]
Internet-Draft IM Cancel August 2007
2. Approach
2.1. Things We Cannot Do
There is no way to guarantee this mechanism will catch all messages
once sent. That is a physics problem that is beyond our ability to
change, unless you find a way to turn back time.
Because of non-repudiation issues, we cannot create a mechanism to
offer the sender the ability to silently delete a message. Of
course, recipients may have policies that do allow for the
suppression of messages when they receive a message cancellation
request. However, that is a user interface implementation issue that
is beyond the scope of the protocol. As a reminder, servers SHOULD
NOT silently delete messages, unless local policy allows and user
agreement is secured. Otherwise, silently deleting messages opens
the recipient to fraud and other abuse.
Also because of non-repudiation issues, we cannot have the mechanism
offer the sender the ability to replace a message. Again, this
capability would make the recipient open to fraud and abuse. For
example, the first message could be "Buy ABC - I have privileged
information that the company will announce a major new contract and
the stock price will rise." The second message, replacing the first
is, "Let us go for a walk." In an audit, law enforcement would not
know that securities fraud occurred. Likewise, the recipient can
insist they received the buy suggestion, but would have no way to
prove it. By the definition of non-repudiation, there is no
circumstance where one can replace an existing message with another
one without some indication to the recipient. Thus we will not
attempt to do the impossible here.
Users can emulate a replaces functionality by sending a suggestion
(request) for the recipient to ignore the first message and then send
a second message. We call this a suggestion here only because
request has the connotation of a high likelihood of the granting of
the request.
2.2. Things We Can Do
What we are trying to accomplish is the sending user wishes to, in an
automated way, let the receiving user know the first message was sent
in error. In conversation or writing, the dialog would be something
like, "Meet me at 4pm ... ... ... Oops, I cannot make 4pm, how about
6pm?" We here propose an automated method of accomplishing the same
thing.
It is important to understand that we are at best making a suggestion
Burger Expires February 18, 2008 [Page 5]
Internet-Draft IM Cancel August 2007
for processing at the recipient's user agent or store-and-forward
servers acting on behalf of the recipient.
In protocol terms, we are sending a special message that an automaton
can process to indicate the sender's request to ignore the first
message.
2.3. Instant Message Overview
The SIP Extension for Instant Messaging document [5] describes the
use of SIP for carrying instant messages. Likewise, the XMPP IM and
Presence document [6] describes the use of XMPP for carrying instant
messages. Since what we are doing is providing a mechanism at the
application level for making a cancellation request, this mechanism
is transport-independent.
Being an application-layer request, we carry the request in a CPIM
message [2]. The client identifies the message for cancellation by
using the Message-ID facility, as described in IMDN [3]. An
interesting scenario is where the user sends a first message with an
IMDN request and then subsequently sends a cancellation request
against that message. In this case, the user might get a response
giving them a hint as to whether or not their cancellation request
was successful. Of course, all of the caveats specified in IMDN,
namely the likelihood of the sender getting no responses, would apply
here.
2.4. Overview
The diagram below depicts the basic protocol flow. The client
creates an IM. That IM includes the Message-ID header, to uniquely
identify the message. At a certain point in time, the client decides
he does not want the system to deliver the message. Thus he sends a
delivery cancellation request against the first message. The client
does this by sending a message cancellation request, referencing the
Message-ID of the first message.
Burger Expires February 18, 2008 [Page 6]
Internet-Draft IM Cancel August 2007
+--------------+ +--------------+
| IM Sender | | IM Recipient |
|IMDN Recipient| | IMDN Sender |
+--------------+ +--------------+
| |
| |
| 1. IM with Message-ID |
|-------------------------------------->|
| |
| |
| 2. IM with cancel request |
| referencing message #1's |
| Message-ID |
|-------------------------------------->|
| |
| |
We can combine the message cancellation request with IMDN [3]. This
opens some interesting possibilities. For example, if the sender
receives a "read" IMDN, he knows not to bother to attempt sending an
automated cancellation message. He knows already it is too late.
Conversely, if the sender has not received a "read" IMDN, he knows
there is a small chance the server may process his cancellation
request before the recipient has read the first message. Of course,
the lack of an IMDN read message does not guarantee the cancel
message will have any effect. First, policy at the server may
prevent the sending of IMDN "read" messages. Thus, the recipient may
have already read the message. Second, there is a relatively large
glare window between the time the recipient reads a message and sends
a "read" IMDN and the time the sender composes and sends a
cancellation message.
Likewise, by requesting an IMDN on the cancellation message itself, a
sender could know whether the server honored the cancellation
request. In a single administrative domain with a set of common,
known policies, it would be possible to implement a message recall
(cancellation) mechanism, subject to the caveats found, for example,
in [4]. Namely, the client cannot cancel a message already read at
the server.
Clearly, in situations that span multiple administrative domains or
where policies are unknown or private, there is no way to know if the
server processed the request, if the server received the request at
all, or if it simply has the policy to ignore requests.
Reiterating, it is important to note that local policy at the
recipient may prevent the recipient's user agent from sending any
acknowledgements of receipt of a message, that the user agent
Burger Expires February 18, 2008 [Page 7]
Internet-Draft IM Cancel August 2007
displayed the message for the user, or that the user agent received
or acted upon a message cancellation request.
3. Protocol Operation
The cancellation request is an application-layer request. Thus we
encapsulate the request in a CPIM message. The client needs to
uniquely identify the message to cancel. The client does this by
including the Message-ID header, as defined by IMDN [3], in the first
message. When the client sends a subsequent message to suggest a
message cancellation, the client includes the Message-ID of the first
message. Relying on the Message-ID header means using the
urn:ietf:params:imdn namespace.
One might create a protocol that guarantees a best efforts attempt to
process the cancellation request by having the mechanism use the CPIM
[2] Require machinery. However, given the low probability of the
recipient actually executing the request, we do not use the Require
machinery. More importantly, the same privacy considerations against
using Require for IMDN applies here. Namely, the policy of ignoring
IMDN or cancel requests is itself privileged information. Failing a
Require request would expose the recipient's policy. Thus we cannot
use Require for indicating mandatory support of cancellation request
policy.
Instead of requiring understanding of this mechanism, we use the same
mechanism as MIME [7]. We include a user-readable message describing
the message cancellation request, in the event the server is unable
to honor the request to cancel the message. In this case, the server
will presumably render the cancellation request. Having a human
readable part at the head indicating the request to cancel the first
message gives the recipient a clue what the sender wishes to
accomplish.
The server, upon receiving the request, can do any of the following.
The server can silently remove the first message, if the server has
not yet displayed the message, and such action is within the
recipient's policy. The server can indicate the first message is
stale. The server can ignore the request to cancel the message. Or,
if the server does not understand the message cancellation request
protocol, the server will simply display the cancellation request,
which will contain user-readable text indicating the first message is
stale.
Since the cancellation processing occurs at the server, it is the
recipient's policy that matters here. No matter how much the sender
may wish for a message to silently disappear, it is up to the
Burger Expires February 18, 2008 [Page 8]
Internet-Draft IM Cancel August 2007
recipient to honor that request. As noted in Section 2.1, it is not
possible to guarantee the server will do any processing at all.
Likewise, due to policy, security, and privacy concerns, it is not
possible to require the server to support and honor cancel and IMDN
in an Internet. It may be possible to do all of this in a single
administrative domain following a set of policies imposed above Layer
7. However, that is all beyond the scope of this document and the
work of the IETF. All that we have done here is provide the tools to
create such a regime.
3.1. Detailed Client Behavior
Since the server needs to be able to uniquely identify the first
message sent by the client, the client MUST include and populate the
Message-ID CPIM header, as specified by IMDN [3].
Because of the security implications of random endpoints injecting
message cancellation requests, we strongly RECOMMEND all messaging
between the client and the server use a secure, authenticated message
path.
When the client desires to cancel the first message, the client sends
a new message to the server. The content of the message MUST be
multipart/mixed. The message content MUST have exactly one part with
a multipart preamble. The MIME preamble MUST be present and is a
user-readable message describing the desire for the recipient to
ignore the first message. This is to offer interoperability with
recipients not conforming to this specification. The first MIME body
part MUST be of type message/im-cancel+xml. Section 4 describes the
syntax of the IM cancellation request. The Content-Disposition of
this body part MUST be cancel-request.
The preamble MUST have enough information so the recipient user can
make sense of the request. At the very least, it MUST include the
values of the sender (CPIM From:), recipient (CPIM To:), and time
(CPIM DateTime:) header fields. It is RECOMMENDED to include the
CPIM Subject: header field, as well. The first MIME body part MUST
include the original Message-ID, the original From, and the original
To CPIM header fields. An example might be as follows.
Burger Expires February 18, 2008 [Page 9]
Internet-Draft IM Cancel August 2007
From: Joe Blow <im:jblow@example.com>
To: Jane Mistress <im:jane@example.net>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: R234fiuncq4
Content-type: multipart/mixed; boundary=number42
Content-length: ...
The sender Joe Blow (jblow@example.com) requests you ignore the message
sent to you (jane@example.net) at 1:05pm on August 21, 2007, with the
subject, "I love you and miss you terribly".
--number42
content-type: message/im-cancel+xml
Content-Disposition: cancel-request
<?xml version="1.0" encoding="UTF-8"?>
<imCancel xmlns="urn:ietf:params:xml:ns:imCancel">
<Message-ID>23499fuq34fu</message-id>
<From>im:jblow@example.com</From>
<To>im:jane@example.net</To>
</imCancel>
--number42--
Note that the Message-ID, "23499fuq34fu", in the XML body refers to
the CPIM Message-ID of the first message. The Message-ID,
"R234fiuncq4", in the CPIM headers is the Message-ID of this
cancellation request.
If the client would like to request notification as to whether the
server executed the cancellation request, the client MUST include the
Disposition-Notification header, as described in IMDN.
3.2. Detailed Server Behavior
This section describes the detailed server behavior when a server
receives a cancel message request. The following section describes
proxy or back-to-back user agent behavior.
When the server receives a cancel message request, it first examines
the user's policy for handling cancel message requests. Policies can
range from ignoring all cancellation requests, silently processing
requests if it can, notifying the user of the request and asking what
to do, adding a visual indicator to the first message to show it is
stale, simply displaying the user-readable cancellation message, or
some combination of these. The server MUST apply the user-selected
policy to the cancellation request.
Burger Expires February 18, 2008 [Page 10]
Internet-Draft IM Cancel August 2007
The rest of this section describes server behavior when it is the
user policy to honor cancellation requests.
The server MUST authenticate the source of the message. If the
source of the message is not the same as the source of the first
message, the server MUST ignore the request.
OPEN ISSUE: There are lots of ways of authenticating the source of
the message. I would offer that mandating one way of doing it
would guarantee interoperability. Next best is to have a
negotiation mechanism. Last is to leave the text as it is, which
means that whatever works works, but also leaves us open to a
sender using, for example TLS and the receiver expecting S/MIME.
TLS: Pro: easy to establish for a session; no key distribution
problem; already there. Con: requires the sender to issue the
cancel message from the same physical device he sent the first
message from.
S/MIME: Pro: simple to compare cryptographic signatures to
determine the source of the cancel message is the same as the
source of the first message; enables the sender (human) to use any
of his devices to cancel the message. Con: requires public key
distribution.
Silent: Pro: really smart servers could pick up the source from
TLS and yet calculate the source from S/MIME. Best (or worst) of
all worlds?
The server MUST validate the Message-ID, From, and To elements of the
cancel message request match the Message-ID, From, and To fields of
the first message's CPIM headers.
Once validated, the server SHOULD remove the message from pending
messages to display, if policy allows. However, the server MUST NOT
remove a message that it has already displayed. Once displayed or
entered into a local log, the server can only indicate the message is
stale.
If a cancel message arrives at the server, referring to a message
that the server has not seen, the server MAY hold the message for a
short period of time (i.e., less than 300 seconds) to see if a
corresponding first message arrives. If the corresponding first
message arrives to the cancel message, then the server MUST perform
its appropriate cancel request processing.
If the corresponding first message does not arrive in a timely
manner, the server SHOULD ignore the message. Keeping state for
these messages creates an opportunity for a denial-of-service attack.
The server MAY respond with an appropriate IMDN if the client
requested IMDN processing. The server absolutely MUST conform to the
Burger Expires February 18, 2008 [Page 11]
Internet-Draft IM Cancel August 2007
full IMDN specification, ensuring it generates an IMDN in this case
if and only if the server can verify the request comes from the same
place the server is to send the IMDN to. Of course, the server also
MUST conform to the IMDN policy restrictions, namely only sending
responses when local policy allows.
If the cancellation request message has Message-Notification set, the
server SHOULD notify the sender on the disposition of the cancel
request, unless server policy prohibits such processing. If the
server policy does allow this processing, the server SHOULD return
"read" if the first message was not displayed and the server honored
the cancel request. If the first message also has Message-
Notification set, the server SHOULD return "processed" in an IMDN
response to the first message, thus sending two responses in this
case. The server SHOULD return "processed" in all other cases where
server policy permits. In this case, the server will have displayed
the message already, and if the sender requested Message-
Notification, the server should have already sent a "read" IMDN. The
caveats are the normal caveats for IMDN. Namely, server policy might
restrict the sending of any IMDN's or the content contained in the
IMDN.
3.3. B2BUA Behavior
Back-to-back user agent (B2BUA) behavior roughly follows the behavior
for IMDN. One may use a B2BUA to gateway between IM and foreign
messaging systems, such as the short message service (SMS).
Likewise, one may use a B2BUA as a message list exploder.
The B2BUA MUST validate the Message-ID, From, and To elements of the
cancel message request match the Message-ID, From, and To fields of
the first message's CPIM headers. It is strongly RECOMMENDED the
server only accept cancel message requests from the authenticated
host and user that sent the first message. This does restrict the
sender such that they cannot use a different device to cancel the
first message. However, the added security is necessary, and given
the real-time nature of IM, this is not a limitation in practice.
The B2BUA SHOULD forward the cancellation request. This, of course,
assumes there is a similar cancel message directive in the target
network. Also, where possible, the B2BUA SHOULD honor the policies
of the user with respect to message cancellation processing.
If the B2BUA has not yet forwarded the first message, it SHOULD
remove the first message, assuming policy allows. If the sender of
the first message requested Message-Notification, the B2BUA SHOULD
return "processed" for the first message, per the caveats listed in
IMDN. If the sender of the cancel message requested Message-
Burger Expires February 18, 2008 [Page 12]
Internet-Draft IM Cancel August 2007
Notification, the B2BUA SHOULD return "read" if the first message was
not displayed and the server honored the cancellation request.
Otherwise, the B2BUA SHOULD return "processed".
If the B2BUA is a list exploder, there may be a mixed state of copies
of the message already forwarded and copies waiting for the server to
forward. In this case the B2BUA MAY remove the copies of the first
message and SHOULD forward the cancel request to the endpoints the
B2BUA has already sent the first message to. Again, the conditional
on the level of compliance depends on the end user's policy and
possibly the policy of the operator of the B2BUA.
4. Formal Syntax
This is the RelaxNG Schema for the imCancel XML type.
<?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:imCancel">
<start>
<element name="imCancel">
<element name="message-id">
<data type="token"/>
</element>
<element name="From">
<data type="token"/>
</element>
<element name="To">
<data type="token"/>
</element>
</element>
</start>
</grammar>
5. Security Considerations
The message cancellation request has a large set of security
considerations. The text deals with many of them. The major ones
are non-repudiation and recipient privacy.
Because of the dire consequences of message deletion from man-in-the-
middle attacks and from snooping attacks, we strongly RECOMMEND that
only messages from cryptographically authenticated sources can have
Burger Expires February 18, 2008 [Page 13]
Internet-Draft IM Cancel August 2007
the suggested cancellation processing applied if the cancel request
comes from a likewise cryptographically authenticated source.
6. IANA Considerations
6.1. Schema and Namespace
Per the IETF XML Registration Procedures [8], please register the
schema for message/im-cancel+xml, as described in Section 4.
Please register the namespace "urn:ietf:params:xml:ns:imCancel".
Registrant contact: IETF, SIMPLE working group, Eric Burger,
eburger@standardstrack.com.
6.2. Registration of MIME Media Type
Per the MIME Registration Procedures [9], please register the MIME
media type message/im-cancel+xml.
MIME media type name: message
MIME subtype name: im-cancel+xml
Required parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [10].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [10].
Security considerations: See section 10 of RFC 3023 [10] and
Section 5 of RFCXXXX.
Interoperability considerations: none.
Published specification: RFCXXXX.
Applications which use this media type: This document type supports
CPIM-based instant messaging.
Additional information:
Magic number: none
File extension: .cl or .xml
Burger Expires February 18, 2008 [Page 14]
Internet-Draft IM Cancel August 2007
Macintosh file type code: "TEXT"
Person & email address to contact for further information: Eric
Burger, eburger@standardstrack.com.
Intended usage: COMMON
Author/Change controller: IETF.
6.3. New Content-Disposition Parameter
Content-Disposition parameter name: cancel-request
Allowable values for this parameter: none
Description: the body identifies a previous message to be canceled
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", RFC 3862, August 2004.
[3] Burger, E. and H. Khartabil, "Instant Message Disposition
Notification", draft-ietf-simple-imdn-04 (work in progress),
May 2007.
7.2. Informative References
[4] Microsoft, "How message recall works", File http://
office.microsoft.com/en-us/outlook/HA010917601033.aspx, 2003.
[5] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[6] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
October 2004.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
Burger Expires February 18, 2008 [Page 15]
Internet-Draft IM Cancel August 2007
[8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[9] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[10] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
Appendix A. Contributors
The idea for this draft came from the document
draft-ren-sipping-replace-instant-message-01 by Da Qi Ren, Qian Sun,
and Linyi Tian, all of Huawei Technologies in Shenzhen, China. All
of these people have provided some text and corrections on this
document. As always, complete and valuable comments and alternate
text came from Spencer Dawkins.
Appendix B. Acknowledgements
Coming, I am sure.
Author's Address
Eric W. Burger
BEA Systems, Inc.
USA
Phone: +1 781 993 7437
Fax: +1 603 457 5944
Email: eric.burger@bea.com
URI: http://www.standardstrack.com
Burger Expires February 18, 2008 [Page 16]
Internet-Draft IM Cancel August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Burger Expires February 18, 2008 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 03:52:32 |