Internet Engineering Task Force Krisztian Kiss
Gabor Bajko
Internet_Draft Nokia
SIMPLE Working Group
draft-kiss-simple-presence-wireless-reqs-00.txt June 21, 2002
Expires: December 2002
Requirements for Presence Service based on 3GPP specifications and
wireless environment characteristics
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.
1. Abstract
This Internet-Draft defines requirements for Presence Service based
on 3GPP specifications and wireless environment characteristics. The
requirements presented in this document are proposed to be evaluated
by the SIMPLE Working Group. The result of this evaluation process
could help to determine the work expected to be done in IETF and
identify the work which might be done in other standardization
Internet-Draft Expires: December 11, 2002 Page 1
Krisztian Kiss 3GPP Presence Requirements June 2002
bodies, such as 3GPP. Thus, a more precise work-share between
standardization bodies could be worked out.
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.
3. Table of contents
Status of this Memo...............................................1
1. Abstract.......................................................1
2. Conventions used in this document..............................2
3. Table of contents..............................................2
4. Introduction...................................................2
5. General wireless requirements..................................3
6. Publishing requirements........................................3
6.1 Standardized mechanism to update (publish) presence information3
6.2 Publishing efficiency.........................................4
7. Subscription and notification requirements.....................4
7.1 Filtering.....................................................4
7.2 Anonymous subscription........................................4
7.3 Efficient subscription and notification.......................4
7.4 Content indirection...........................................5
8. Requirements for the content of the Presence Document..........5
8.1 Presence attributes...........................................5
8.2 Location information..........................................5
9. Authorization requirements.....................................6
9.1 Standardized setting of authorization policy..................6
9.2 Expressiveness of authorization rules.........................6
10. Watcher information requirements..............................6
10.1 Watcher information filtering................................6
10.2 Watcher history..............................................7
11. Evaluation against the SIMPLE charter items...................7
11.1 Publishing requirements......................................7
11.2 Subscription and notification requirements...................7
11.3 Presence Document requirements...............................7
11.4 Authorization requirements...................................7
11.5 Watcher information requirements.............................8
12. Proposed next steps...........................................8
13. Author's addresses............................................8
14. Contributors..................................................8
15. References....................................................8
Full Copyright Statement.........................................10
4. Introduction
Internet-Draft Expires: December 6, 2002 Page 2
Krisztian Kiss 3GPP Presence Requirements June 2002
This Internet-Draft defines requirements for Presence Service based
on 3GPP specifications [6][7] and other needs rising from
mobile/wireless environment characteristics. Presence Service is
referenced as defined in IMPP Working Group in documents [10] and
[11].
The document assumes the usage of Session Initiation Protocol (SIP)
[8] for subscriptions and notifications of user presence [12] as
defined in the SIMPLE Working Group. Additionally, some other
existing Working Group and/or individual drafts are used as a
baseline. These include the SIP Event Template-Package for Watcher
Information documents [16][17], the SIMPLE components draft [15],
the SIP buddylist event package [14] and the content indirection
requirements draft [18].
The document also assumes the usage of the Common Presence and
Instant Messaging (CPIM) Presence Information Data Format (PIDF)
defined in [13] 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.
5. 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 requirement.
6. Publishing requirements
6.1 Standardized mechanism to update (publish) presence information
Internet-Draft Expires: December 6, 2002 Page 3
Krisztian Kiss 3GPP Presence Requirements June 2002
There must be a standardized mechanism to update (publish) the
presence information. The mechanism must allow publishing from
multiple Presence User Agents (PUAs) of a single presentity.
There must be rules and mechanisms to merge the information from
multiple sources and resolve possible conflicts, and to keep all the
publishing PUAs aware of each other's published information.
6.2 Publishing efficiency
The preferred mechanism for updating the presence information would
allow the Presence User Agent to update only parts of the presence
information. For example if a piece of presence information changes,
only that part needs to be updated, as opposed to always sending the
full state within each publish transaction. This would allow more
efficient utilization of the network resources.
See also the related requirements in section 5.
7. Subscription and notification requirements
7.1 Filtering
It must be possible for a subscriber to request what presence
information he wants to receive in future notifications.
EXAMPLE: the subscriber may only want to be notified when the
presentity becomes available for conferencing.
The Presence Agent must be able to construct presence information
that is delivered to subscriber according to authorization rules and
subscriberÆs filtering request.
7.2 Anonymous subscription
It must be possible for the subscriber to request an anonymous
subscription (i.e. the subscriberÆs identifier will not be revealed
to the presentity).
This anonymous request may be accepted or rejected, depending on the
presentityÆs access control settings, as described in Chapter 9.
NOTE: This requirement may be met with the overall privacy solution
for SIP.
7.3 Efficient subscription and notification
The preferred mechanism would allow the Presence Agent to generate
partial notifications containing only those attributes, which have
changed value compared to the previous notification.
Internet-Draft Expires: December 6, 2002 Page 4
Krisztian Kiss 3GPP Presence Requirements June 2002
The mechanism would also allow the subscriber to indicate support
for partial notification when subscribing to the presentityÆs
presence information.
Another identified way to decrease the number of SUBSCRIBE and
NOTIFY messages is to use a solution similar to the SIP event
package for buddylist subscriptions described in [19].
A third identified solution is to use some dynamic compression
mechanisms to compress the presence information.
See the related requirements in section 5.
7.4 Content indirection
Content indirection is described in [18]. In connection to presence
the following requirements have been identified:
The Presence Agent must be able to perform content indirection.
Subscribers must have the capability to indicate the support of
content indirection. The Presence Agent must honor subscriberÆs
preferences whether to perform content indirection or not when it
detects a situation where content indirection should be performed.
8. Requirements for the content of the Presence Document
It must be possible for the Presence Document to contain multiple
types of presence attributes. As an example, one type could be user
specific attribute, another type device specific attribute and a
third type network specific attribute.
8.1 Presence attributes
It must be possible for the Presence Document to identify the type
of presence attribute and must provide unique identity for all
presence attributes.
It must be possible to have multiple instances of the semantically
same attributes for different purposes/subscribers.
EXAMPLE: One group of subscribers is shown a different value for the
status of presentity than the other.
8.2 Location information
There must be a standardized mechanism to express location
information and related privacy restrictions within the Presence
Document. This location information may be transported either in a
standardized way or by a 3GPP specific extension to the standardized
Presence Document.
Internet-Draft Expires: December 6, 2002 Page 5
Krisztian Kiss 3GPP Presence Requirements June 2002
9. Authorization requirements
This chapter defines the requirements for how presentity is able to
authorize the presence subscriptions.
9.1 Standardized setting of authorization policy
There must be a standardized mechanism for the presentity (Presence
User Agent) to set 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.
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.
9.2 Expressiveness of authorization rules
It must be possible to define different "access rights" or "views"
for different subscribers or groups of subscribers. The access
rights determine what parts of the presence information are provided
to a particular subscriber.
EXAMPLE: Only subscribers belonging to a particular group are
allowed to receive information related to presentity's location.
It must be possible for the presentity to grant access rights
separately for all elements of the presence information.
It must be possible for the presentity to grant access rights
separately on the level of detail of the presence information.
It must be possible to grant access rights with an expiry time to a
particular subscriber or group.
As groups are seen as an important concept in the authorization
policy definition, it is expected that the standardized mechanisms
related to authorization policy management include operations for
management of groups. The solution should be aligned with the group
management operations used for other purposes.
10. Watcher information requirements
10.1 Watcher information filtering
Internet-Draft Expires: December 6, 2002 Page 6
Krisztian Kiss 3GPP Presence Requirements June 2002
It should be possible for the presentity to monitor the watcher
status of certain subscribers.
This requirement may be fulfilled if the watcher information
subpackage defined in [16] could be extended with filtering
mechanisms.
10.2 Watcher history
It must be possible for the presentity to fetch the list of the
subscribers who have accessed (by subscription or fetch) his
presence information during a well-defined time-period (e.g. last 7
days).
Additionally to the list of subscribers, the details of the presence
information provided to different subscribers should be available
for the presentity when fetching the watcher history.
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 requirements
New SIMPLE charter has a work item for userÆs buddylist management
and authorization operations. This work item could be used to define
generic approach how userÆs presence service related information
could be managed.
11.2 Subscription and notification requirements
The most appropriate place to implement all subscription and
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.3 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.4 Authorization requirements
New SIPMLE charter has a work item for userÆs buddylist management
and authorization operations. This work item could be used to
implement authorization requirements presented in this document.
Internet-Draft Expires: December 6, 2002 Page 7
Krisztian Kiss 3GPP Presence Requirements June 2002
11.5 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.
13. Author's addresses
Krisztian Kiss
Nokia Research Center
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
14. Contributors
The following people contributed to this draft:
Markus Isomki(Nokia), Mikko L÷nnfors (Nokia), Georg Mayer
(Siemens), Mark Beckmann (Siemens), Sonia Garapaty (Nortel),
Jayshree Bharatia (Nortel), Keith Drage (Lucent), Andrew Allen
(DynamicSoft), Kevan Hobbis (H3G), Sunil Chotai (mmO2), Duncan
Mills (Vodafone), Miguel A. Garcia (Ericsson).
15. References
Internet-Draft Expires: December 6, 2002 Page 8
Krisztian Kiss 3GPP Presence Requirements June 2002
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. 3GPP TS 23.228 "IP Multimedia Subsystem (IMS) (Stage 2) - Release
5", Version 5.5.0 available at
ftp://ftp.3gpp.org/specs/latest/Rel-5/23_series/
4. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call
control based on SIP and SDP", Version 5.1.0 available at
ftp://ftp.3gpp.org/specs/archive/24_series/24.228/
5. 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP
and SDP, stage 3", Version 5.1.0 available at
ftp://ftp.3gpp.org/specs/archive/24_series/24.229/
6. 3GPP TS 22.141: "Presence Service, Stage 1", Version 5.2.0
available at ftp://ftp.3gpp.org/specs/archive/22_series/22.141/
7. 3GPP TR 23.841: "Presence Service, Architectural and Functional
Description, Stage 2", Version 1.0.0 available at
ftp://ftp.3gpp.org/specs/archive/23_series/23.841/
8. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, E. Schooler: "SIP, Session
Initiation Protocol", draft-ietf-sip-rfc2543bis-09.txt, February
2002, work in progress.
9. A. Roach, "SIP-Specific Event Notification", draft-ietf-sip-
events-05.txt, February 2002, work in progress
10. M. Day, S. Aggarwal, G. Mohr, J. Vincent "Instant Messaging /
Presence Protocol Requirements", RFC 2779
11. M. Day, J. Rosenberg, H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778
12. J. Rosenberg et al., "SIP Extensions for Presence", draft-ietf-
simple-presence-07.txt, May 2002, work in progress
13. 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
14. J. Rosenberg, B. Campbell, "SIP Event Package for Buddy List
Presence", draft-rosenberg-simple-buddylist-package-00.txt,
November 2001, work in progress
15. J. Rosenberg, "A Component Model for SIMPLE", draft-rosenberg-
simple-components-00.txt, February 2002, work in progress
Internet-Draft Expires: December 6, 2002 Page 9
Krisztian Kiss 3GPP Presence Requirements June 2002
16. 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
17. J. Rosenberg, "An Extensible Markup Language (XML) Based Format
for Watcher Information", draft-ietf-simple-winfo-format-02.txt,
May 2002, work in progress
18. S. Olson, "Requirements for Content Indirection in SIP
Messages", draft-olson-sipping-content-indirect-00.txt, March
2002, work in progress
19. J. Rosemberg, "A SIP Event Package for Buddylist Presence",
draft-rosenberg-simple-buddylist-package-00.txt, November 2001,
work in progress (expired)
Full Copyright Statement
"Copyright (C) The Internet Society (2000). 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."
Internet-Draft Expires: December 6, 2002 Page 10