Network Working Group M. Stafford Internet-Draft J. Shih Intended status: Standards Track M. Wuthnow Expires: July 14, 2007 Cingular Wireless January 10, 2007 Disposition Notification Requirements for Deferred Messaging draft-stafford-simple-dmdn-00.txt 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 July 14, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Stafford, et al. Expires July 14, 2007 [Page 1] Internet-Draft Notification for Deferred Messages January 2007 Abstract This memo expands the set of use cases for SIP MESSAGE and SIP- controlled MSRP sessions. Following OMA, the new use cases include MSRP for one time messages that exceed the size limit for SIP requests over UDP, and extend the paradigm to deferred messaging. In deferred messaging, which is invoked when the intended recipient is not available, the message is sent to a store and forward server. The new requirements are for disposition notification functionality in this context. Table of Contents 1. requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Messaging Modes and Deferred Messaging . . . . . . . . . . . . 4 2.1. Standalone Message Modes: Page Mode and Large Message Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Deferred Messaging . . . . . . . . . . . . . . . . . . . . 4 2.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Description of Use Cases . . . . . . . . . . . . . . . . . . . 6 3.1. Deferred Messaging Delivery Notification . . . . . . . . . 6 3.2. Deferred Messaging Read Notification . . . . . . . . . . . 8 4. Further Comments . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Stafford, et al. Expires July 14, 2007 [Page 2] Internet-Draft Notification for Deferred Messages January 2007 1. requirements notation 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 [1]. Stafford, et al. Expires July 14, 2007 [Page 3] Internet-Draft Notification for Deferred Messages January 2007 2. Messaging Modes and Deferred Messaging IETF's SIMPLE working group distinguishes between standalone messages and messages that are exchanged within the context of a session. Page mode is defined for the former and session mode is defined for the latter. (See, for example, reference [2].) Following OMA, we expand the taxonomy for standalone messages. 2.1. Standalone Message Modes: Page Mode and Large Message Mode Page mode is as defined by IETF's SIMPLE working group: the SIP MESSAGE method [6] is used as a vehicle for transporting standalone messages. Following OMA's SIMPLE IM working group [10], we define large message mode for the exchange of standalone messages that exceed the 1300- byte size limit for SIP requests over UDP (cf Section 18.1.1 of [4]). As is the case with session mode, the SIP INVITE method is employed to establish an MSRP session [7], [9]. Transfer of the message then takes place at the MSRP layer. In large message mode, the MSRP session is torn down once the message transfer is complete. This contrasts with session mode, in which the MSRP session is long-lived, being torn down as a result of intervention by an end user (or perhaps when an inactivity timer fires). In fact, the presumption in large message mode is that end users are unaware of underlying MSRP sessions. Said differently, end users will not distinguish between page mode and large message mode, but instead will be presented with a unified standalone messaging experience. 2.2. Deferred Messaging OMA's SIMPLE IM working group also defines a notion of deferred messaging in the context of SIP and MSRP [10]. Deferred messaging comes into play when one IM subscriber wants to send a message to another subscriber who happens to be unavailable at the time. In this case, the message goes to a store and forward server, to be delivered once the intended recipient becomes available. 2.3. Motivation We stress the naturalness of the use cases that large message mode and deferred messaging are defined to accommodate. These concepts enable end users to interact via a unified composer for standalone messages. Suppose, for example, that an end user begins composing a standalone IM. The user would be put off by having to move to a different piece of client software if he/she extemporaneously decides Stafford, et al. Expires July 14, 2007 [Page 4] Internet-Draft Notification for Deferred Messages January 2007 to add an attachment, or intended recipient(s) become unavailable before message composition is completed. Stafford, et al. Expires July 14, 2007 [Page 5] Internet-Draft Notification for Deferred Messages January 2007 3. Description of Use Cases 3.1. Deferred Messaging Delivery Notification +---------+ +---------+ +---------+ | Alice's | | App | | Bob's | | UA | | Server | | UA | +---------+ +---------+ +---------+ | 1-3. SIP INVITE/200 OK/ACK | | |<-------------------------->| | | | | | 4-5. MSRP SEND/200 OK | | |<-------------------------->| | | | | | 6-7. SIP BYE/200 OK | | |<-------------------------->| | | | | | ========================================= | | = Bob's state changes- now available = | | = to receive IMs = | | ========================================= | | | | | | 8-10.SIP INVITE/200 OK/ACK | | |<-------------------------->| | | | | | 11-12. MSRP SEND/200 OK | | |<-------------------------->| | | | | | 13-14. SIP BYE/200 OK | | |<-------------------------->| | 15. SIP MESSAGE | | |<---------------------------| | | | | | 16. SIP 200 OK | | |--------------------------->| | Figure 1: Generic Signaling Flow In Figure 1, Alice wants to send a standalone message to Bob, but at the time Bob is not available to receive IMs. Due to the size of the intended payload, large message mode is invoked in steps 1 through 7: Alice's client software sends a SIP INVITE to an application server. An MSRP session is established, the message is shipped off to the server, and the session is torn down upon completion of the message transfer. Stafford, et al. Expires July 14, 2007 [Page 6] Internet-Draft Notification for Deferred Messages January 2007 Alice indicates that she wants to know when the message is received by Bob's UA. So Alice's UA includes a unique message identifier and a delivery notification request indicator in the body of the MSRP message. Once Bob becomes available to receive IMs, an MSRP session is set up, the message is transferred, and the session is torn down (steps 8 through 14 in the figure). Alice is then notified: a SIP MESSAGE is sent to her UA; the MESSAGE contains the aforementioned message identifier and a success indicator. Comments: o In the interest of simplicity, some details are omitted from Figure 1 (e.g., signaling flow through any SIP proxies that might be sitting between Alice and Bob, MSRP authentication, and so on). o We could just as easily have presented an analogous deferred- messaging flow for page mode. However, reference [3] suffices to implement that use case. o The means by which Bob's availability becomes apparent is unspecified. However, one obvious possibility is that the application server subscribes to Bob's presence (and Bob publishes a change to his presence status- which is not shown in the diagram). o The means by which Alice's SIP INVITE is routed to the application server is also left unspecified. Perhaps Alice has subscribed to Bob's presence, or possibly the application server has registered under Bob's SIP AoR. o Variability in the means by which Alice receives delivery notification is also possible- the figure just shows one example. An MSRP message could be sent instead (although that seems like overkill). Or, Bob's UA could initiate the SIP MESSAGE request, which could be routed either via the application server or "directly" to Alice. In a wireless environment, the approach shown would have the advantage that the SIP MESSAGE would only traverse one air interface. Moreover, this approach would readily accomodate cases in which Alice's state changes to IM-unavailable prior to message delivery. * NOTE: The application server is not acting as a SIP proxy here. Thus the flow of Figure 2 does not appear to violate [3]. The above comments notwithstanding, the crucial thing appears to be the presence of a unique message identifier, which allows Alice's UA Stafford, et al. Expires July 14, 2007 [Page 7] Internet-Draft Notification for Deferred Messages January 2007 to determine which message has been successfully delivered. 3.2. Deferred Messaging Read Notification +---------+ +---------+ +---------+ | Alice's | | App | | Bob's | | UA | | Server | | UA | +---------+ +---------+ +---------+ . . . . . . . . . | ========================================= | | = Bob receives IM(s) = | | ========================================= | . . . . . . . . . | ========================================= | | = Bob reads Alice's IM = | | ========================================= | | | | | | SIP MESSAGE | | SIP MESSAGE |<---------------------------| |<---------------------------| | | | | | SIP 200 OK | | |--------------------------->| SIP 200 OK | | |--------------------------->| Figure 2: Read Notification Flow In the previous example, Alice could just as easily have requested read notification. This use case, which is presented in Figure 2, is equally sensible- one can envision a standalone message (especially a deferred one) being presented to Bob via some sort of "inbox" representation. Details through the point where "Bob receives IMs" may be (but need not necessarily be) the same as in steps 1-14 of Figure 1. Note the following difference, however: in the delivery notification example of the previous section, the application server knows from the MSRP 200 OK that the IM has reached Bob's UA. In the read notification example of the current section, the server has no way of knowing unless Bob's UA initiates a new message exchange. The application server could either be acting as a SIP proxy or a B2BUA. If numerous IMs are waiting for Bob when he becomes available to Stafford, et al. Expires July 14, 2007 [Page 8] Internet-Draft Notification for Deferred Messages January 2007 receive IMs, there may be a significant pause between receiving Alice's message and reading it. (So read notification capability is nontrivial.) As in the previous example, existence of a unique message ID is crucial. Stafford, et al. Expires July 14, 2007 [Page 9] Internet-Draft Notification for Deferred Messages January 2007 4. Further Comments IMDN headers- that is, the CPIM header extensions defined in [3]- are a good fit for the use cases described above. Therefore this memo calls for the usage of IMDN headers to be extended to those use cases. Note that RFC 3862 [5] is the baseline CPIM data format specification. Stafford, et al. Expires July 14, 2007 [Page 10] Internet-Draft Notification for Deferred Messages January 2007 5. Security Considerations The security considerations detailed in [3] are applicable here. No new security considerations are introduced by the current memo. Stafford, et al. Expires July 14, 2007 [Page 11] Internet-Draft Notification for Deferred Messages January 2007 6. IANA Considerations The following items defined in [3] are pertinent in the context of the current memo: o The message/imdn+xml MIME TYPE o URN Sub-Namespace urn:ietf:params:xml:ns:imdn o Schema registration o Message/CPIM header fields o Content-Disposition: notification No new IANA considerations are introduced by the current memo. Stafford, et al. Expires July 14, 2007 [Page 12] Internet-Draft Notification for Deferred Messages January 2007 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Isomaki, M., "Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP)", draft-ietf-simple-messaging-requirements-00 (work in progress), June 2006. [3] Burger, E., "Instant Messaging Disposition Notification", draft-ietf-simple-imdn-02 (work in progress), November 2006. [4] Rosenberg, J., "SIP: Session Initiation Protocol", RFC 3261, June 2002, . [5] Klyne, G., "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004, . [6] Campbell, B., "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002, . [7] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-18 (work in progress), December 2006. [8] Jennings, C., "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", draft-ietf-simple-msrp-relays-10 (work in progress), December 2006. [9] Garcia-Martin, M., "A Session Description Protocol (SDP) Offer/ Answer Mechanism to Enable File Transfer", draft-ietf-mmusic-file-transfer-mech-00.txt (work in progress), December 2006. 7.2. Informative References [10] Open Mobile Alliance, "Instant Messaging Using SIMPLE Architecture", OMA-AD-SIMPLE_IM-V1_0-20061129-D, November 2006. Stafford, et al. Expires July 14, 2007 [Page 13] Internet-Draft Notification for Deferred Messages January 2007 Authors' Addresses Matthew W. Stafford Cingular Wireless 9505 Arboretum Blvd Austin, TX 78759 Email: matthew.stafford@cingular.com Jerry Shih Cingular Wireless 5565 Glenridge Connector Atlanta, GA 30342 Email: jerry.shih@cingular.com Mark S. Wuthnow Cingular Wireless 9505 Arboretum Blvd Austin, TX 78759 Email: mark.wuthnow@cingular.com Stafford, et al. Expires July 14, 2007 [Page 14] Internet-Draft Notification for Deferred Messages January 2007 Full Copyright Statement Copyright (C) The Internet Society (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 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). Stafford, et al. Expires July 14, 2007 [Page 15]