Internet DRAFT - draft-ietf-simple-messaging-requirements
draft-ietf-simple-messaging-requirements
SIMPLE M. Isomaki
Internet-Draft Nokia
Intended status: Informational J. Rosenberg
Expires: December 24, 2006 Cisco Systems
June 22, 2006
Advanced Instant Messaging Requirements for the Session Initiation
Protocol (SIP)
draft-ietf-simple-messaging-requirements-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 December 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Session Initiation Protocol (SIP) supports the basic instant
messaging service in both page and session mode. This document
defines a set of requirements for instant messaging capabilities that
are beyond the scope of the baseline specifications.
Isomaki & Rosenberg Expires December 24, 2006 [Page 1]
Internet-Draft IM Requirements June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Instant Messaging Disposition Notifications . . . . . . . . . 3
4. Is-Composing . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Content Capabilities . . . . . . . . . . . . . . . . . . . . . 7
6. Page-Mode Groups . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Isomaki & Rosenberg Expires December 24, 2006 [Page 2]
Internet-Draft IM Requirements June 2006
1. Introduction
The Session Initiation Protocol (SIP) defines several specifications
that support Instant Messaging (IM). The SIP MESSAGE method [3]
allows for "page-mode" messaging, offering a service in some aspects
similar to Short Message Service (SMS) in wireless networks. A more
advanced capability, called session mode messaging, uses the SIP
INVITE method to establish a session where messages are transported
using Message Session Relay Protocol (MSRP) [9]. This makes it
possible to combine messaging with other media such as audio and
video. Also, many regular SIP capabilities to be directly applied to
instant messaging, such as conferencing [10].
However, there are many additional features that exist in current,
proprietary IM systems. Some of these features do not require
protocol extensions in order to be deployed (IM message archival, for
example). However, others do.
This document provides requirements for a number of advanced IM
features which require additional standardization activity in
addition to the basic SIP MESSAGE and MSRP work. For some of the
requirements presented here the relevant standardization work has
actully been already concluded. In those cases the related
specifications are called out and referenced.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
3. Instant Messaging Disposition Notifications
In most cases, an IM is delivered immediately to the recipient.
Indeed, this is the principal motivation behind the "Instant" in
"Instant Messaging". However, in many systems, an instant message
can be sent even when the recipient is not available. Indeed, even
if they are available when the message is sent, the user may log off
before the message can be delivered. In addition to basic delivery
reporting, the sender may be interested when the recipient has
actually "read" the message or the message has been at least
displayed to the user in some way.
Typically, this is dealt with through a combination of two features.
Isomaki & Rosenberg Expires December 24, 2006 [Page 3]
Internet-Draft IM Requirements June 2006
The first is message archival and retrieval. These features allow
the intended recipient to retrieve their messages at a later time.
To support this, the receiving domain stores the content of the IM,
allowing the user to fetch it later. In this regard, it is very
similar to existing email systems. Existing protocols, such as IMAP4
[8], can be used for the retrieval functions of IM.
The second feature is message disposition notification. This feature
allows the sender to be notified when the message has been delivered
to the recipient and when the recipient has "read" the message. This
feature exists in SMS, email [11] and several commercia IM systems.
A similar function is needed for SIP-based instant messaging.
Certainly, much of the email specifications for message delivery
confirmation can be reused for IM. However, much of it is email-
specific, and IM introduces some new requirements. The following
requirements apply to IM disposition notifications:
REQ-DISNOT-1: It MUST be possible for the sender of an IM to
request a delivery notification and/or a read notification.
REQ-DISNOT-2: It MUST be possible for the recipient of the message
to immediately indicate to the sender that the recipient supports
delivery and/or read notifications.
REQ-DISNOT-3: It MUST be possible that the disposition
notifications can be sent and received at any point in the future
after the actual IM has been sent, without introducing any limits
on such a time window.
REQ-DISNOT-4: The delivery notification MUST be capable of
indicating that the message was delivered to the intended target.
REQ-DISNOT-5: The delivery notification MUST be capable of
indicating whether the message was delivered successfully, or
whether, when it was delivered, the recipient geneeated an error.
It MUST be possible for the sender to learn the specific error
condition.
REQ-DISNOT-6: The disposition notification MUST indicate the time
when the message was delivered or read.
REQ-DISNOT-7: The disposition notification MUST contain enough
information to allow the sender of the original IM to correlate
the notification with the correct message, provided that the
sender has stored the contents of the sent message. In addition
the notification MUST be able to carry information that might be
helpful to a sender who no longer has the original message
Isomaki & Rosenberg Expires December 24, 2006 [Page 4]
Internet-Draft IM Requirements June 2006
available, such as the original To, From, Content-Type and
Content-Length headers.
REQ-DISNOT-8: It MUST be possible for the message sender (the
recipient of the notification) to authenticate the sender of the
notification. There is no explicit requirement for confidentialy
of the notification.
REQ-DISNOT-9: As it is anticipated that this mechanism will be
used frequently from wireless devices, it SHOULD keep overhead to
a minimum, and in particular, SHOULD NOT provide extraneous
information not relevant to the above requirements.
REQ-DISNOT-10: When an IM is sent to an intermediary that will
relay it to a group of recipients, it MUST be possible for the
sender to ask that disposition notifications are generated by each
final recipient separately.
REQ-DISNOT-11: When an IM is sent to an intermediary that will
relay it to a group of recipients, it MUST be possible for the
sender to ask that the intermediary will generate summary reports
based on reports it receives from each final recipient. [OPEN
ISSUE: Is this needed?]
REQ-DELNOT-12: Any error condition reported by the notification
MAY contain a textual description of the error meant for human
consumption [OPEN ISSUE: How about internationalization?]
REQ-DELNOT-13: If an IM is being relayed through a gateway, for
example, to SMS, the delivery report SHOULD be able to indicate
such a condition [OPEN ISSUE: Is this needed?]]
4. Is-Composing
Many commercial instant messaging and presence systems provide a
feature generally referred to as "is-typing". This feature is used
during instant messaging chat sessions. Whenever one user is in the
process of typing a message to another user, the recipient-to-be can
see that a message is in progress. This avoids a common problem
where both participants are typing replies at the same time, so that
the resulting stream of converation is not well synchronized.
Generalizing this concept, the idea is really to allow one
participant to inform another participant that they are composing a
message of some type. By conveying a type, a broader set of features
can be enabled. For example, if one user indicates that they are
Isomaki & Rosenberg Expires December 24, 2006 [Page 5]
Internet-Draft IM Requirements June 2006
composing a message of type audio/basic, the other user will know
that a voice IM is coming.
The specification of how is-composing indicators are generated and
represented is available as RFC 3994 [13]. It has been designed
based on the requirements listed in this Section.
REQ-COMP-1: The is-composing feature MUST work with instant
messaging sessions [9].
REQ-COMP-2: Either side in the session should be able to indicate
that they can receive the indicators. The indicators MUST NOT be
sent from A to B if B does not explicitly indicate that they can
receive them.
REQ-COMP-3: It MUST be possible for indicators to be sent in only
one direction, i.e., A sends them to B, but B does not send them
to A.
REQ-COMP-4: It MUST be possible for usage of the indicators to be
added or removed to any IM session after the session has begun.
REQ-COMP-5: The indicator MUST be able to inform the recipient
that the sender has begun composing a message.
REQ-COMP-6: The indicator MUST be able to inform the recipient
that the sender has stopped composing a message.
REQ-COMP-7: The indicator MUST be able to convey the MIME type of
the message that is being composed.
REQ-COMP-8: The indicator must be synchrnonized with the message
stream itself. That is, if a recipient gets an indicator that a
user has stopped composing a message, and they also get a message,
the recipient must be able to know which came first.
REQ-COMP-9: It must be possible to provide end-to-end message
integrity and authentication over the indicators.
REQ-COMP-10: It must be possible to associate the is-composing
indicator with a particular instant messaging session.
REQ-COMP-11: It should be possible to interwork is-composing
indicators between CPIM compliant systems, possibly with some loss
of functionality, but with integrity and authentication in tact.
Isomaki & Rosenberg Expires December 24, 2006 [Page 6]
Internet-Draft IM Requirements June 2006
REQ-COMP-12: It should be possible for is-composing indicators to
work, possibly with loss of functionality, in page mode.
REQ-COMP-13: The is-composing indicator should not result in an
increase on the load of proxies.
REQ-COMP-14: It must be possible to receive delivery confirmation
reports for is-composing indicators [OPEN ISSUE: This is related
to the question on whether disposition notifications will be
supported for session-mode messaging.]
REQ-COMP-15: The overhead of the indicators should be minimal.
5. Content Capabilities
Although traditionally used with text, an IM can contain any kind of
content. There is an increasing trend to send multimedia content,
including audio, video, and even applications, over IM. However,
recipients may not wish to receive content that they do not
understand, or is over a particular size limit.
Handling these "content capabilities" is done differently for page
mode and session mode. In session mode, the initial offer/answer
exchange [4] can be used to convey content capabilities. Indeed, the
messaging sessions mechanism allows for negotiation of supported
content types. However, some additional aspects of negotiation are
required:
REQ-CONTENT-1: A UA MUST be able to indicate the maximum message
size it is willing to receive.
This requirement has been met in MSRP via the a=max-size
attribute.
In page mode messaging, a 413 response can be sent if a MESSAGE
request is too large. However, there is no way to indicate what the
largest allowed size is:
REQ-CONTENT-2: A 413 response MUST be capable of indicating the
maximum allowed message size. [OPEN ISSUE: Is this needed?]
Note that, there is no requirement to support transcoding of content
at an intermediary in order to reduce the size of a sent message to
match that of a recipient.
Isomaki & Rosenberg Expires December 24, 2006 [Page 7]
Internet-Draft IM Requirements June 2006
6. Page-Mode Groups
The baseline SIP MESSAGE specification does not have explicit support
for sending page mode messages to groups or multiple recipients.
This capability is addressed by the Multi-recipient MESSAGE request
[12] specification to meet the following requirements.
REQ-GROUP-1: It MUST be possible to address a page-mode IM to a
group.
REQ-GROUP-2: Each recipient of a group page IM MUST be capable of
determining the set of other recipients that got the request.
REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc
group, where the identities of the recipients are carried in the
message itself.
REQ-GROUP-4: It MUST be possible for the recipient of a group IM
to send a message to all other participants that received the same
group IM (i.e., Reply-To-All).
7. IANA Considerations
There are no IANA Considerations associated with this specification.
8. Security Considerations
Security requirements are discussed above where relevant.
9. Acknowledgments
This draft includes requirements contributed by Aki Niemi [14]. Eric
Burger, Ben Campbell, Hisham Khartabil, Paul Kyzivat, Aki Niemi, Sean
Olson and Robert Sparks provided valuable comments.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Isomaki & Rosenberg Expires December 24, 2006 [Page 8]
Internet-Draft IM Requirements June 2006
10.2. Informative References
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779,
February 2000.
[6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[7] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail
- version 2", RFC 2421, September 1998.
[8] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.
[9] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-14 (work in progress),
February 2006.
[10] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
[11] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 3464, January 2003.
[12] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-message-07 (work in progress),
February 2006.
[13] Schulzrinne, H., "Indication of Message Composition for Instant
Messaging", RFC 3994, January 2005.
[14] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless
Systems", draft-niemi-simple-im-wireless-reqs-02 (work in
progress), October 2003.
Isomaki & Rosenberg Expires December 24, 2006 [Page 9]
Internet-Draft IM Requirements June 2006
Authors' Addresses
Markus Isomaki
Nokia
Keilalahdentie 2-4
Helsinki, 02150
Finland
Phone: +358 50 5225984
Email: markus.isomaki@nokia.com
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Isomaki & Rosenberg Expires December 24, 2006 [Page 10]
Internet-Draft IM Requirements June 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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).
Isomaki & Rosenberg Expires December 24, 2006 [Page 11]