Krisztian Kiss
Internet-Draft Gabor Bajko
Network Working Group Nokia
Expires: April 25, 2003 October 25, 2002
Requirements for Presence Service based on 3GPP specifications and
wireless environment characteristics
draft-kiss-simple-presence-wireless-reqs-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
The distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This Internet-Draft defines requirements for Presence Service based
on 3GPP specifications and wireless environment characteristics.
Internet-Draft Expires: April 25, 2002 Page 1
Krisztian Kiss 3GPP Presence Requirements October 2002
Table of contents
1. Introduction.................................................3
2. Conventions used in this document............................3
3. General wireless requirements................................3
4. Publishing requirements......................................4
4.1 Standardized mechanism to publish presence information.......4
4.2 Requirements to support multiple PUAs........................4
4.3 Feedback on publishing.......................................4
4.4 Publishing efficiency........................................5
5. Subscription and notification requirements...................5
5.1 Filtering....................................................5
5.2 Anonymous subscription.......................................5
5.3 Notification efficiency......................................6
5.4 Content indirection..........................................6
6. Requirements for the content of the Presence Document........6
6.1 Presence information elements................................6
6.2 Multivalue concept...........................................7
6.3 Location information.........................................7
7. Authorization requirements...................................7
7.1 Standardized setting of authorization policy.................7
7.2 Expressiveness of authorization rules........................7
8. Watcher information requirements.............................8
8.1 Pending watcher notification.................................8
8.2 Watcher information filtering................................8
8.3 Watcher history..............................................8
9. Presencelist requirements....................................9
10. Security requirements........................................9
11. Evaluation against the SIMPLE charter items..................9
11.1 Publishing and Subscription/Notification requirements........9
11.2 Presence Document requirements...............................9
11.3 Authorization and Management requirements....................9
11.4 Watcher information requirements............................10
12. Proposed next steps.........................................10
Normative References...³³...................................10 ³
Informative References......................................11
Author's addresses..........................................12
A. Acknowledgements............................................12
Full Copyright Statement....................................13
Internet-Draft Expires: April 25, 2002 Page 2
Krisztian Kiss 3GPP Presence Requirements October 2002
1. Introduction
This Internet-Draft defines requirements for Presence Service based
on 3GPP specifications [23][24] and other needs rising from
mobile/wireless environment characteristics. The requirements on the
Session Initiation Protocol (SIP) for the Release 5 of the 3GPP IP
Multimedia Subsystem are described in [19]. Presence Service is
referenced as defined in IMPP Working Group in documents [5] and
[6].
This document does not document requirements that have led to the
creation and work in progress on a number of SIMPLE WG specifications,
i.e. subscriptions and notifications of user presence [7], the SIP
presencelist event package [9], the SIP Event Template-Package for
Watcher Information documents [11][12], the content indirection
mechanism [17] and the SIMPLE Presence Publication Mechanism [15][16].
Rather this document lists only requirements that are additional to
those that have led to the mechanisms proposed in these documents.
The document also assumes the usage of the Common Presence and
Instant Messaging (CPIM) Presence Information Data Format (PIDF)
defined in [8] as the default presence document data format,
however some of the requirements presented here might require
extensions to PIDF.
The requirements presented in this document are proposed to be
evaluated by the SIMPLE Working Group. The result of this evaluation
process would help to determine the work expected to be done in IETF
and identify the work which might be done in other standardization
bodies, such as 3GPP. Thus, a more precise work-share between
standardization bodies could be worked out. The overall goal of
these requirements is to allow the development of a fully
standardized presence application for wireless terminals, utilizing
existing IETF and 3GPP specifications.
2. Conventions used in this document
This document does not specify any protocol of any kind. Therefore,
the use of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document, as described in RFC 2119 [2], does not
apply.
Internet-Draft Expires: April 25, 2002 Page 3
Krisztian Kiss 3GPP Presence Requirements October 2002
3. General wireless requirements
The radio interface is a scarce resource. As such, the number and
size of the messages exchanged over the radio interface between the
UA and the network should be minimized. All the mechanisms developed
should make an efficient use of the radio interface.
As terminals could be rather small devices, memory requirements,
power consumption, processing power, etc. should be kept to a
minimum. Mandating support for additional protocols and mechanisms
in the terminal must meet this condition.
4. Publishing requirements
4.1 Standardized mechanism to publish presence information
There must be a standardized mechanism to manage (publish) the
presence information. The standardized publication mechanism must
allow publishing from multiple Presence User Agents (PUAs) of a
single presentity. It must be possible for the PUAs of the same
presentity to add elements to the presence information as well
as remove or modify existing elements of the presence information.
4.2 Requirements to support multiple PUAs
The Presence Server must be able to merge the information from
multiple sources and resolve possible conflicts in the resulting
presence document.
It must be possible for the PUA to discover the current content
and status of the presence document including presence information
published by other PUAs belonging to the same presentity.
Requirements in section 3 must be also taken into account When
fulfiling this requirement.
The PUA must be able to manipulate already existing elements of the
presence information published by another PUAs.
4.3 Feedback on publishing
The PUA must be able to receive feedback about the result of a
publishing transaction, the feedback must contain enough
information for the principal controlling the presentity to know
that the published presence information was successfully composed
into the presence document by the Presence Server.
Internet-Draft Expires: April 25, 2002 Page 4
Krisztian Kiss 3GPP Presence Requirements October 2002
4.4 Publishing efficiency
It must be possible for the presentity to publish multimedia
contents along with their communication means when publishing
presence information. The mechanism selected for publishing large
size content must make efficient use of the network resources and
satisfy related requirements in section 3.
One identified mechanism to fulfil this requirement is to allow the
PUA to update only those parts of the presence information that have
changed since the last publication.
For example if only some elements of the presence information
changes, then only those elements need to be updated as opposed to
always sending all the presence information elements within each
publish transaction.
5. Subscription and notification requirements
5.1 Filtering
It must be possible for a watcher to select certain elements from
the presence information that he wants (or does not want) to receive
in notifications for.
EXAMPLE: the watcher may only want to be notified when the
presentity becomes available for conferencing.
The Presence Server must be able to construct the presence document
to be delivered to the watcher according to the watcher's
filtering preferences.
NOTE: When determining the elements to be included in the presence
document, authorization rules are also needed to be taken into
account.
It must be possible for the Presence List Server [9] to construct
and store appropriate filtering rules for every URI in the
presencelist based on the watcher's filtering preferences.
[14] describes more detailed filtering requirements.
5.2 Anonymous subscription
It must be possible for the watcher to request an anonymous
subscription (i.e. the watcher's identifier will not be revealed
to the presentity).
This anonymous request may be accepted or rejected, depending on the
presentity's authorization rules as described in clause 7.
NOTE: This requirement may be met with the overall privacy solution
for SIP.
Internet-Draft Expires: April 25, 2002 Page 5
Krisztian Kiss 3GPP Presence Requirements October 2002
5.3 Notification efficiency
It must be possible for the watcher to determine what presence
information is available for a particular presentity before
fetching or subscribing to the presence information elements with
actual values.
It must be possible for the watcher to receive notification of
multimedia contents along with the presentityÆs communication means.
The mechanism selected for notifying large size content must make
efficient use of the network resources and satisfy related
requirements in section 3.
One identified mechanism to fulfil this requirement is to allow the
Presence Server to generate partial notifications to the watcher
containing only those elements of the presence information, which
have changed value compared to the previous notification to the
watcher.
NOTE: When using this mechanism the watcher must be able to indicate
its support for partial notification when subscribing to the
presentity's presence information.
5.4 Content indirection
Requirements for content indirection are described in [13]. In
connection to presence the following requirements have been
identified:
The Presence Server should be able to perform content indirection.
Watchers should have the capability to indicate the support of
content indirection. The Presence Server must honor watcher's
preferences whether to perform content indirection or not when it
detects a situation where content indirection should be performed.
6. Requirements for the content of the presence document
6.1 Presence information elements
The presence document must contain presence information elements.
Each presence information element must contain a unique identity
which makes the presence information element distinguishable from
other presence information elements inside the presence document.
RFC 2778 [6] defines the presence information element to consist
of a STATUS marker, an optional COMMUNICATION ADDRESS, and optional
OTHER PRESENCE MARKUP. A COMMUNICATION ADDRESS includes a
COMMUNICATION MEANS and a CONTACT ADDRESS.
As a further requirement for this definition, it must be possible
to define semantics to the content of an element (e.g. for the
communication means: voice, video, instant messaging, application).
The presence document must be able to contain multiple types of
presence information elements. As an example, a presence information
element could be user specific, device specific or network specific.
Internet-Draft Expires: April 25, 2002 Page 6
Krisztian Kiss 3GPP Presence Requirements October 2002
6.2 Multivalue concept
It must be possible to include multiple instances of the semantically
same presence information in the presence document. The different
instances should contain different values of the same presence
information and used to be shown for different watchers. The
different watchers must only receive those instances of the
presence information they are authorized to by the presentity.
EXAMPLE: One group of watchers is shown a different value for the
status of presentity than the other.
The Presence Server must be able to distinguish whether two presence
information elements contain semantically different presence
information or they are different instances of the semantically same
presence information.
6.3 Geographic location information
There must be a standardized mechanism to express geographic location
information within the presence document.
7. Authorization requirements
This chapter defines the requirements for how presentity is able to
authorize the presence subscriptions.
7.1 Standardized setting of authorization policy
There must be a standardized mechanism for the presentity (Presence
User Agent) to control the authorization policy related to his own
presence information.
This means that the authorization policy document format and a set
of manipulation operations upon that format must be standardized.
Such manipulation operations should be aligned with the ones used
for other similar purposes (such as conferencing).
It should be possible for network operators to extend the format of
the authorization policy document and the operations upon that
format based on local policy.
7.2 Expressiveness of authorization rules
It must be possible for the presentity to set separate authorization
rules for different watchers and groups of watchers. With these rules
the presentity must be able to override the default behaviour of the
presence server for the generation of notifications and content of
the notifications.
EXAMPLE: Only watchers belonging to a particular group are
allowed to receive information related to presentity's location.
Internet-Draft Expires: April 25, 2002 Page 7
Krisztian Kiss 3GPP Presence Requirements October 2002
It must be possible for the presentity to manage the authorization
rules from multiple sources (e.g. from different terminals of the
presentity or by the service provider on behalf of the presentity.)
It must be possible for the presentity from one source to learn the
changes in the authorization rules changed by other sources belonging
to the same presentity.
It must be possible for the presentity to grant access rights
separately for all elements of the presence information.
RFC 2778 [6] defines a model for presence information. Based on this
model more specific requirements can be stated:
It must be possible for the Presence Server to decide based on
authorization rules whether to include a certain tuple in the
notification. It must be possible to base that decision on any
element in the tuple. In the default case these must include at least
TUPLE ID, CONTACT ADDRESS, COMMUNICATION MEANS and STATUS attributes.
As a special case, it must be possible for the Presence Server to
provide different status values for same COMMUNICATION ADDRESS or
combination of COMMUNICATION ADDRESS and OTHER PRESENCE MARKUPs.
It must be possible to grant access rights with an expiry time to a
particular watcher or group.
As groups are seen as an important concept in the authorization
policy definition, the solution should be aligned with the
operations used for similar purposes (such as conferencing).
8. Watcher information requirements
8.1 Pending watcher notification
It must be possible for a presentity to be informed of a pending
watcher subscription from a currently unauthorized and/or unknown
watcher.
8.2 Watcher information filtering
It should be possible for the presentity to monitor the watcher
status of certain watchers.
NOTE: This requirement may be fulfilled if the watcher information
subpackage defined in [11] could be extended with filtering
mechanisms.
8.3 Watcher history
It must be possible for the presentity to fetch the list of the
watchers who have accessed (by subscription or fetch) his
presence information during a well-defined time-period (e.g. last 7
days).
Internet-Draft Expires: April 25, 2002 Page 8
Krisztian Kiss 3GPP Presence Requirements October 2002
Additionally to the list of watchers, the details of the presence
information provided to different watchers should be available
for the presentity when fetching the watcher history.
9. Presencelist requirements
Requirements for creating a presencelist, adding new URIs to an
existing presencelist, modifying or removing existing URIs from an
existing presencelist, or deleting a presencelist are described
in [10].
10. Security requirements
Security requirements assume requirements that have led to existing
security mechanism described in [18]. Further security requirements
over and above this have not yet been identified.
11. Evaluation against the SIMPLE charter items
SIMPLE Working Group charter may contain solution space for some of
the requirements presented in this document. This chapter will
present a proposal how these requirements could be mapped into
SIMPLE Working Group work items.
11.1 Publishing and Subscription/Notification requirements
The most appropriate place to implement all publishing and
subscription/notification related requirements is the SIMPLE Working
Group, as SIP based presence extensions have been specified in this
Working Group. At the moment there is no appropriate work item for
these requirements.
11.2 Presence Document requirements
New SIMPLE charter has a work item for SIMPLE PIDF profile. Scope of
this work item could be defined to include presence document
requirements presented in this document.
11.3 Authorization and Management requirements
New SIMPLE charter has a work item for user's presencelist management
and authorization operations. This work item could be used to define
generic approach how user's presence service related information
could be managed and how to implement authorization requirements
presented in this document.
Internet-Draft Expires: April 25, 2002 Page 9
Krisztian Kiss 3GPP Presence Requirements October 2002
11.4 Watcher information requirements
Watcher information format and event-template has been specified in
SIMPLE Working Group. It would be beneficial if this group's
expertise could be utilized to generate required extensions to
support watcher information filtering and history information.
12. Proposed next steps
It is proposed that SIMPLE Working Group should evaluate these
requirements. The requirements for which a consensus is found within
the Working Group should be incorporated into the presence
requirements Working Group draft. It is also expected for the
Working Group to point out any requirements that fall out of its
scope, so that other standardization bodies, such as 3GPP are able
to start working on those without the risk of overlapping work. The
results of such work can be brought back to IETF as Informational
documents.
Normative References
1. S. Bradner, "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2. S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
3. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, E. Schooler: "SIP, Session
Initiation Protocol", RFC 3261, June 2002
4. A. Roach, "ession Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002
5. M. Day, S. Aggarwal, G. Mohr, J. Vincent "Instant Messaging /
Presence Protocol Requirements", RFC 2779
6. M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778
7. J. Rosenberg et al., "SIP Extensions for Presence", draft-ietf-
simple-presence-07.txt, May 2002, work in progress
8. H. Sugano, S. Fujimoto, G. Klyne, A. Bateman: "CPIM Presence
Information Data Format", draft-ietf-impp-cpim-pidf-05.txt, May
2002, work in progress
9. J. Rosenberg, B. Campbell, "SIP Event Package for List Presence",
draft-ietf-simple-presencelist-package-00.txt, June 2002, work in
progress
Internet-Draft Expires: April 25, 2002 Page 10
Krisztian Kiss 3GPP Presence Requirements October 2002
10. J. Rosenberg, M. Isomaki, "Requirements for Manipulation of
Data Elements in SIMPLE Systems",
draft-ietf-simple-data-req-00.txt, October 2002, work in progress
11. J. Rosenberg, "A Session Initiation Protocol (SIP) Event
Template-Package for Watcher Information", draft-ietf-simple-
winfo-package-02.txt, May 2002, work in progress
12. J. Rosenberg, "An Extensible Markup Language (XML) Based Format
for Watcher Information", draft-ietf-simple-winfo-format-02.txt,
May 2002, work in progress
13. S. Olson, "Requirements for Content Indirection in SIP
Messages", draft-ietf-sipping-content-indirect-02.txt, September
2002, work in progress
14. T. Moran, S. Addagatla, "Requirements for Event Notification
Filters", draft-moran-sipping-filter-reqs-00.txt, October 2002,
work in progress
15. B. Campbell, S. Olson, J. Peterson, J. Rosenberg, B. Stucker,
"SIMPLE Presence Publication Mechanism",
draft-olson-simple-publish-00, June 2002, work in progress
16. A. Niemi, "SIP Specific Data Publication Framework",
draft-niemi-simple-publish-framework-00, September2002, work in
progress
17. S. Olson, "A Mechanism for Content Indirection in SIP Messages",
draft-olson-sip-content-indirect-mech-01, August 2002, work in
progress
18. J. Arkko, V. Torvinen, G. Camarillo, T. Haukka, S. Sen, "Security
Mechanism Agreement for SIP Sessions",
draft-ietf-sip-sec-agree-04.txt, June 2002, work in progress
19. M. Garcia-Martin, "3rd-Generation Partnership Project (3GPP)
Release 5 requirements on the Session Initiation Protocol (SIP),
draft-ietf-sipping-3gpp-r5-requirements-00.txt, October 2002, work
in progress
Informative References
20. 3GPP TS 23.228 "IP Multimedia Subsystem (IMS) (Stage 2) - Release
5", Version 5.6.0 available at
ftp://ftp.3gpp.org/specs/latest/Rel-5/23_series/
21. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call
control based on SIP and SDP", Version 5.2.0 available at
ftp://ftp.3gpp.org/specs/archive/24_series/24.228/
Internet-Draft Expires: April 25, 2002 Page 11
Krisztian Kiss 3GPP Presence Requirements October 2002
22. 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP
and SDP, stage 3", Version 5.2.0 available at
ftp://ftp.3gpp.org/specs/archive/24_series/24.229/
23. 3GPP TS 22.141: "Presence Service, Stage 1", Version 5.2.0
available at ftp://ftp.3gpp.org/specs/archive/22_series/22.141/
24. 3GPP TS 23.141: "Presence Service, Architecture and Functional
Description, Stage 2", Version 0.2.1 available at
ftp://ftp.3gpp.org/specs/archive/23_series/23.141/
Authors' addresses
Krisztian Kiss
Nokia
P.O. Box 100
FIN-33721 Tampere, Finland
Tel: +358 50 4835363
e-mail: krisztian.kiss@nokia.com
Gabor Bajko
Nokia
HU-1092 Budapest, Koztelek 6
Hungary
Tel: +36 20 9849259
e-mail: gabor.bajko@nokia.com
Appendix A. Acknowledgements
The authors would like to thank the following people for their interest,
support and efforts when writing this Internet-Draft:
Markus Isomaki (Nokia), Mikko Lonnfors (Nokia), Juha Kalliokulju
(Nokia), Eva-Maria Leppanen (Nokia), Georg Mayer (Siemens),
Mark Beckmann (Siemens), Sonia Garapaty (Nortel), Jayshree
Bharatia (Nortel), Keith Drage (Lucent), Andrew Allen
(DynamicSoft), Kevan Hobbis (H3G), Harmand Alexandre (mmO2), Duncan
Mills (Vodafone), Miguel A. Garcia (Ericsson), Milo Orsic (Lucent).
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.
Internet-Draft Expires: April 25, 2002 Page 12
Krisztian Kiss 3GPP Presence Requirements October 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 assigns.
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
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.
Internet-Draft Expires: April 25, 2002 Page 13