Network Working Group A. Niemi
Internet-Draft Nokia
Expires: August 28, 2003 February 27, 2003
Requirements for Instant Messaging in 3GPP Wireless Systems
draft-niemi-simple-im-wireless-reqs-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 August 28, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document lists the requirements specific to 3GPP wireless
Instant Messaging systems.
Niemi Expires August 28, 2003 [Page 1]
Internet-Draft 3GPP Reqs for IM February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. General Characteristics of Wireless Systems . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Addressing Requirements . . . . . . . . . . . . . . . . . . . 4
3.2 Message Content Requirements . . . . . . . . . . . . . . . . . 4
3.3 Message Delivery and Handling Requirements . . . . . . . . . . 5
3.4 Message Session Management and Operation Requirements . . . . 5
4. User Privacy Requirements . . . . . . . . . . . . . . . . . . 7
5. Charging Requirements . . . . . . . . . . . . . . . . . . . . 7
6. Security Requirements . . . . . . . . . . . . . . . . . . . . 7
7. Proposal for Next Steps . . . . . . . . . . . . . . . . . . . 8
Normative References . . . . . . . . . . . . . . . . . . . . . 8
Informative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
A. Changes from draft-niemi-simple-im-wireless-reqs-00 . . . . . 9
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Niemi Expires August 28, 2003 [Page 2]
Internet-Draft 3GPP Reqs for IM February 2003
1. Introduction
This document lists the requirements for instant messaging based on
3GPP specifications and the special characteristics of a wireless
environment. The requirements presented in this document complement
the requirements in [1], and relate to already ongoing work in the
SIMPLE WG. These requirements are proposed to be evaluated by the
working group, and incorporated in the relevant work items.
1.1 System Overview
Within the 3GPP IP Multimedia Core Network Subsystem (IMS) Messaging
work, two types of messaging services [4] have been identified:
Immediate Messaging
A sender expects near real time message delivery. Typically, the
sender is aware of the availability of the recipient a priori,
possibly through the use of the presence service.
Session Based Messaging
A sender and a recipient have to join a messaging session before
messages can be exchanged as part of the session. The
participants of the session expect near real time delivery of
messages. Mainly, the intended application for session based
messaging are multiparty messaging sessions, i.e., chat rooms,
where a group of participants exhange instant messages with each
others.
Both of these two messaging service types have properties which make
the Session Initiation Protocol (SIP) [5] very suitable for
addressing their requirements. Hence, the charter items in the
SIMPLE working group for defining instant messaging and message
sessions using SIP are considered as targets for the requirements
presented in this memo.
Note that some of the requirements herein may be more related to
the data manipulation requirements of SIMPLE systems [6], the SIP
conferencing requirements [7], and the conference policy data
requirements [8] work in the SIPPING WG.
1.2 Conventions
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 BCP 14, RFC 2119 [2].
In this document, terms "immediate messaging" and "instant messaging"
Niemi Expires August 28, 2003 [Page 3]
Internet-Draft 3GPP Reqs for IM February 2003
are interchangeable. Also, "message sessions" are used in place of
"session based messaging" to better align the terminology used in the
3GPP and IETF.
Note that the term "session based messaging" used by the 3GPP IMS
messaging often includes the notion of a multiparty message
session, which includes both conferencing and message sessions as
components.
2. General Characteristics of Wireless Systems
The radio interface of wireless systems is often a scarce resource.
As such, the message exchange over the radio interface should be
efficiently compact and kept to a minimum. All the mechanisms
developed should make efficient use of the radio interface.
As terminals can be rather small devices, the memory and power
consumption requirements, requirements for processing power, and for
screen size and rendering capabilities should be kept to a minimum.
Mandating support for additional protocols and mechanisms in the
wireless terminal must meet these criteria.
3. Requirements
This section lists the requirements for Instant Messaging in the 3GPP
IMS wireless environment. Generally, these protocol requirements
stem from the special characteristics of wireless systems, and the
specific set of capabilities specified by the 3GPP. More information
on these aspects can be found in 3GPP TS 23.228 [9].
3.1 Addressing Requirements
ADDR-REQ1: It MUST be possible to use a single address to identify
the recipient or sender of an instant message or a member
in a message session, irrespective of the messaging
system.
ADDR-REQ2: Use of E.164 numbers [3] in addressing instant messages
and message session requests MUST be supported.
3.2 Message Content Requirements
CONT-REQ1: It MUST be possible to carry any MIME encoded data in
Instant Messages and message sessions.
Niemi Expires August 28, 2003 [Page 4]
Internet-Draft 3GPP Reqs for IM February 2003
CONT-REQ2: The content size MUST NOT be limited by the Instant
Messaging, or message session protocols.
CONT-REQ3: It MUST be possible for the UA to announce its device
capabilities for messaging.
CONT-REQ4: It MUST also be possible to base handling of instant
messages on these capabilities and user preferences.
3.3 Message Delivery and Handling Requirements
DELIV-REQ1: It MUST be possible for the UA to store sent instant
messages, or messages pertaining to a particular message
session to a network-based repository.
DELIV-REQ2: It MUST be possible to redirect, block (and unblock), or
store to a network-based repository incoming instant
messages as part of a user configurable option.
DELIV-REQ3: This incoming message treatment MUST support instant
message selection based on sender address, message size,
message priority, message subject, message class,
message content type and availability of the recipient.
The mechanism MUST support instant message selection
based on other criteria.
DELIV-REQ4: It MUST also be possible to subsequently retrieve, list,
delete and forward the stored messages. It MUST also be
possible to upload messages to a network-based
repository for storage.
DELIV-REQ5: It MUST be possible for the sender of an instant message
to receive either positive or negative acknowledgements
of delivery for all sent messages.
3.4 Message Session Management and Operation Requirements
SESS-REQ1: It MUST be possible to create new Address-of-Records
(AOR) for message session based conferences, i.e., chat
rooms. These AORs are either ad-hoc style for short
lived conferences, or persistent, if the identification
of a conference focus is long lived.
SESS-REQ2: There MUST be a standardized mechanism by which such
ad-hoc or persistent AORs can be created, applied, and
discarded by the user.
Niemi Expires August 28, 2003 [Page 5]
Internet-Draft 3GPP Reqs for IM February 2003
SESS-REQ3: It MUST be possible for an administrator (or any user
with appropriate rights) of a chat room to control the
list of allowed participants.
SESS-REQ4: There MUST be a standardized mechanism by which such
authorization policy is inserted, manipulated and
removed.
SESS-REQ5: There MUST be a standard mechanism for an end device to
learn the address of the data manipulation interface
used for performing the aforementioned control functions
of a chat room.
SESS-REQ6: There MUST be standardized mechanisms by which an
administrator (or any user with appropriate rights) of a
chat room can invite new participants to an ongoing chat
room, and kick out existing participants.
SESS-REQ7: It MUST also be possible to send semi-permanent
invitations to a chat room to new participants.
Semi-permanent invitations do not require the invitee to
respond immediately. Also, the inviter MUST be able to
cancel the invitation, and/or set a validity period for
the invitation.
SESS-REQ8: It MUST be possible for the administrator of a chat room
to set the properties of a chat room, e.g., name, topic,
and maximum number of active participants. There MUST
be a standardized mechanism by which such properties are
set, manipulated, and removed.
SESS-REQ9: It MUST be possible for participant to request the
properties of a chat room, including the list of active
members. It MUST be possible to also receive automatic
updates of these properties.
SESS-REQ10: It MUST be possible to request and receive an indication
when a particular participant or participants in a chat
room are in the process of entering a message. It MUST
also be possible to disable sending such an activity
indication.
SESS-REQ11: It MUST be possible for the sender of a message to
receive either positive or negative acknowledgements of
delivery for all sent messages in a message session.
Niemi Expires August 28, 2003 [Page 6]
Internet-Draft 3GPP Reqs for IM February 2003
SESS-REQ12: It MUST be possible to send private messages between the
participants of a multiparty message session.
SESS-REQ13: It MUST be possible to send private messages to
participants who are using pseudonym identities or
nicknames.
SESS-REQ14: A private message MUST be delivered in the context of
the ongoing multiparty message session, and messages
intended for private consumption MUST NOT be delivered
to other than the intended recipient.
4. User Privacy Requirements
PRIV-REQ1: It MUST be possible for a recipient of an instant message
or a message session to see the identity of the
originator, unless the originator is anonymous or its
address is hidden.
PRIV-REQ2: It MUST be possible to originate anonymous instant
messages and message sessions.
PRIV-REQ3: It MUST be possible to originate instant messages and
message sessions using pseudonyms, or nicknames.
PRIV-REQ4: It MUST be possible to send private messages in a chat
room using a nickname or an anonymous identity.
OPEN ISSUE: To some extent, these requirements are already covered
in RFC 3324 [10] and RFC 3325 [10]. However, privacy requirements
for identities in message sessions and especially in multiparty
sessions remain open, and are for further study.
5. Charging Requirements
This document refers to the charging requirements of [1], and in
addition defines an additional, messaging specific requirement:
CHARG-REQ1: The instant messaging and message session protocols MUST
be able to support different charging models, including
ones where:
* only the sender of a message pays
* both the sender and the receiver of a message pay
Niemi Expires August 28, 2003 [Page 7]
Internet-Draft 3GPP Reqs for IM February 2003
* only the recipient of a message pays
6. Security Requirements
This document adopts the security requirements listed in [1], and
does not introduce any additional security requirements at this time.
7. Proposal for Next Steps
It is proposed that the SIMPLE Working Group evaluates the
requirements presented in this document and incorporates the relevant
ones in its current work items. Those requirements possibly falling
out of the scope of the SIMPLE WG should find a more suitable home,
possibly also in other standardization bodies.
It is not expected that this document be published as an RFC by the
IETF, but rather serve as a reference to various working group
requirements documents. It is also expected that this document is
used as a check list as requirements get included to other documents.
Normative References
[1] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP)
Release 5 requirements on the Session Initiation Protocol
(SIP)", draft-ietf-sipping-3gpp-r5-requirements-00 (work in
progress), October 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU-T Recommendation
E.164, 1991.
Informative References
[4] 3rd Generation Partnership Project, "IMS Messaging", TS 22.340,
December 2002.
[5] 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.
[6] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of
Data Elements in SIMPLE Systems", draft-ietf-simple-data-req-01
(work in progress), February 2003.
Niemi Expires August 28, 2003 [Page 8]
Internet-Draft 3GPP Reqs for IM February 2003
[7] Levin, O., "Requirements for Tightly Coupled SIP Conferencing",
draft-levin-sipping-conferencing-requirements-02 (work in
progress), November 2002.
[8] Koskelainen, P., "Requirements for conference policy data",
draft-koskelainen-sipping-conf-policy-req-00 (work in
progress), February 2003.
[9] 3rd Generation Partnership Project, "IP Multimedia Subsystem
(IMS)", TS 23.228, January 2003.
[10] Jennings, C., Peterson, J. and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[11] Watson, M., "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2002.
Author's Address
Aki Niemi
Nokia
P.O. Box 321
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Appendix A. Changes from draft-niemi-simple-im-wireless-reqs-00
o Updated the references
o Clarified the format of the requirements by adding labels and
reorganizing the requirements
o Removed a requirement for indirect content in IMS messaging
o Removed OPEN ISSUE on media sequencing
o Added the requirement for semi-permanent chat room invitations
o Added the requirement for chat room properties fetching/
notification
o Added the requirement for "isTyping"
Niemi Expires August 28, 2003 [Page 9]
Internet-Draft 3GPP Reqs for IM February 2003
o Added storage requirements, and clarified the message treatment
requirements
o Added the requirement for delivery acknowledgements to message
sessions
o Reordered some requirements between chapters 4 and 3
o Added an open issue on privacy requirements
o Added a general charging requirement
o Minor editorial fixes
Appendix B. Acknowledgements
The authors would like to thank the following people for their
interest, support and efforts in the IMS messaging work:
Andrew Allen (dynamicsoft), Gabor Bajko (Nokia), Balazs Bertenyi
(Nokia), Keith Drage (Lucent Technologies), Alexandre Harmand
(mmO2), Juha Kalliokulju (Nokia), Krisztian Kiss (Nokia), Duncan
Mills (Vodafone), Milo Orsic (Lucent Technologies), and Milt
Roselinsky (Openwave).
Although not an official communication of the 3GPP, this document has
been discussed and commented by a number of delegates in the relevant
3GPP working groups.
Niemi Expires August 28, 2003 [Page 10]
Internet-Draft 3GPP Reqs for IM February 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Niemi Expires August 28, 2003 [Page 11]
Internet-Draft 3GPP Reqs for IM February 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Niemi Expires August 28, 2003 [Page 12]