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, <http://www.ietf.org/rfc/rfc3261.txt>.
[5] Klyne, G., "Common Presence and Instant Messaging (CPIM):
Message Format", RFC 3862, August 2004,
<http://www.ietf.org/rfc/rfc3862.txt>.
[6] Campbell, B., "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002,
<http://www.ietf.org/rfc/rfc3428.txt>.
[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]