From: http://www.ietf.org/internet-drafts/draft-burger-simple-im-cancel-request-00.txt Title: Instant Message Cancellation Suggestion Reference: IETF SIMPLE Working Group, Internet Draft 'draft-burger-simple-im-cancel-request-00' Date: August 17, 2007 I-D Tracker: http://ietfreport.isoc.org/idref/draft-burger-simple-im-cancel-request' See also: SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group http://www.ietf.org/html.charters/simple-charter.html -- if this URI goes AWOL, try: http://www.ietf.org/html.charters/OLD/simple-charter.html IETF SIMPLE WG Status Pages http://tools.ietf.org/wg/simple (SIMPLE) Working Group Supplemental Home Page (Hisham Khartabil) http://www.softarmor.com/simple/ Extensible Messaging and Presence Protocol (XMPP) http://xml.coverpages.org/xmpp.html ============================================================================== 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 To: Jane Mistress NS: 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 23499fuq34fu im:jblow@example.com im:jane@example.net --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. 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]