Network Working Group Krisztian Kiss (ed.) Internet-Draft Nokia Expires: August 29, 2003 February 28, 2002 Requirements for Presence Service in 3GPP Wireless Systems draft-kiss-simple-presence-wireless-reqs-02 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 (2003). All Rights Reserved. Abstract This Internet-Draft defines requirements for Presence Service in 3GPP wireless systems. Internet-Draft Expires: August 29, 2003 Page 1 Krisztian Kiss 3GPP Presence Requirements February 2003 Table of contents 1. Introduction 2 1.1 Conventions used in this document 3 2. General characteristics of Wireless Systems 3 3. Requirements 3 3.1 Addressing Requirements 4 3.2 Publishing requirements 4 3.3 Subscription and notification requirements 5 3.4 Requirements for the content of the presence document 6 3.5 Authorization requirements 7 3.6 Watcher information requirements 8 3.7 Presencelist requirements 9 4. Security requirements 9 5. Charging Requirements 9 6. Proposal for next steps 9 Normative References 9 Informative References 10 Author's address 12 Appendix A. Contributors 12 Full Copyright Statement 13 1. Introduction This Internet-Draft lists the requirements for Presence Service in 3GPP wireless systems [24][25][26]. The 3GPP Presence Service requirements are defined in [27], the 3GPP Presence Service architecture is defined in [28], presence service information flows and protocol details are defined in [29]. 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 event notification extension for collections [9], the SIP Event Template-Package for Watcher Information documents [11][12], the content indirection mechanism [17] and the SIMPLE Presence Publication Mechanism [15]. 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. Internet-Draft Expires: August 29, 2003 Page 2 Krisztian Kiss 3GPP Presence Requirements February 2003 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. Note that some of the requirements herein may be already addressed in specific requirements documents, i.e. the data manipulation requirements of SIMPLE systems [10], the presence specific event notification filters requirements [14], the rate limiting of event notifications requirements [16], the watcher information filtering requirements [21], the SIMPLE Presence Publication Requirements [23]. 1.1 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. 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 and the size of the messages should be efficiently compact and kept to a minimum. All the mechanisms developed should make an efficient use of the radio interface. There are existing mechanisms to fulfill this requirement, such as signaling compression [31], partial publication, partial notification [20], content indirection [17]. These mechanisms must not be exclusive and must be capable to work together. As terminals could 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 this criteria. 3. Requirements This section lists the requirements for Presence Service in the 3GPP IP Multimedia Subsystem 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 [24]. Internet-Draft Expires: August 29, 2003 Page 3 Krisztian Kiss 3GPP Presence Requirements February 2003 3.1 Addressing Requirements ADDR-REQ1: It must be possible to use a single address to identify the presentity and the watcher. ADDR-REQ2: Use of E.164 numbers [32] in addressing presence service entities must be supported. 3.2 Publishing requirements Generic SIMPLE Presence Publication Requirements are listed in [23]. PUBL-REQ1: Standardized mechanism to publish presence information There must be a standardized mechanism to publish the presence information. PUBL-REQ2: Partial publishing The publish mechanism must allow a PUA to change only part of the presentity's presence information. For example, a PUA must be able to publish one single element of the presentity's PIDF document, while the document contains several elements. PUBL-REQ3: Basic operations of publishing It must be possible for the PUA to add segments to the presence information as well as overwrite, modify or remove existing elements of the presence information. PUBL-REQ4: Mandatory-to-implement MIME type for presence document There must be one mandatory-to-implement MIME type for the publish mechanism. PUBL-REQ5: Inclusion of direct content in the presence document It must be possible for the presentity to include direct content in the presence document. If the direct content is part of the presence document, the signaling compression should be able to maintain the compression efficiency. PUBL-REQ6: Multiple PUAs The publication mechanism must allow simultaneous publishing from multiple distinct PUAs of a single presentity. PUBL-REQ7: Identifiers for PUAs It must be possible to allocate unique identifiers for every distinct PUAs of a particular presentity. PUBL-REQ8: Identification of segments The PUA must be able to publish to a specific segment of the presence document, shared among many PUAs (the number of sources must neither be limited nor pre-defined). This means that the published segments need to be identified across all of the PUAs of a particular presentity. The PUA must be able to generate identifiers for the published segments. Internet-Draft Expires: August 29, 2003 Page 4 Krisztian Kiss 3GPP Presence Requirements February 2003 PUBL-REQ9: Discovering existing segments It must be possible for the PUA to discover existing segment identifiers together with their content published by other PUAs belonging to the same presentity. PUBL-REQ10: Hard-state segments It must be possible to include hard-state segments in the presence documents. This means that in case the PUAs do not refresh presence information, the hard-state segments remain available for the watchers. PUBL-REQ11: 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 Compositor. 3.3 Subscription and notification requirements SUBNOT-REQ1: Presence information 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 notifications for. As an 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 that when determining the elements to be included in the presence document, authorization rules are also needed to be taken into account. Note that there are detailed presence event filtering requirements listed in [14]. SUBNOT-REQ2: Limiting the rate of event notification The watcher must be able to limit the maximum rate at which the notifier can generate notifications in a subscription. Note that there are detailed requirements for the throttle mechanism listed in [16]. SUBNOT-REQ3: 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). The anonymous request may be accepted or rejected, depending on the presentity's authorization rules as described by the AUTH-REQs. Note that this requirement may be met with the overall privacy solution for SIP. Internet-Draft Expires: August 29, 2003 Page 5 Krisztian Kiss 3GPP Presence Requirements February 2003 SUBNOT-REQ4: Gathering information on presence information 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. SUBNOT-REQ5: Direct content inclusion in presence information It must be possible for the watcher to receive notifications including direct contents. The mechanism selected for notifying large size content must make efficient use of the network resources and satisfy generic wireless requirements as described in section 2. SUBNOT-REQ6: Content indirection Generic requirements for content indirection are listed 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. SUBNOT-REQ7: Subscription on behalf of another user It must be possible for a watcher to subscribe to the presentityÆs presence information on behalf of another user. As an example, an Application Server may act as a network-based watcher to provide presence based call control, or a Resource List Server may collect notifications from the individual resources of the presentity collection on behalf of the watcher. 3.4 Requirements for the content of the presence document CONT-REQ1: Unique identifiers for presence segments The presence document contains presence segments. Each presence segment must contain a unique identity which makes it distinguishable from other presence segments inside the presence document. CONT-REQ2: Application specific identifiers It must be possible to include application specific identifiers in a presence tuple. This means that a publishing application running in a PUA is able to address a specific presence tuple to its peer watcher application running in the watcher user agent. CONT-REQ3: Rich content of the presence segments 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. Internet-Draft Expires: August 29, 2003 Page 6 Krisztian Kiss 3GPP Presence Requirements February 2003 As a further requirement for this definition, it must be possible to define rich content for a presence information element (e.g. for the communication means: voice, video, instant messaging, application). One possible solution to fulfill this requirement is defined in [30]. CONT-REQ4: 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. As an 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. CONT-REQ5: Geographic location information There must be a standardized attribute for the geographic location information within the presence document. CONT-REQ6: PresentityÆs status There must be a standardized attribute for the presentityÆs status within the presence document. 3.5 Authorization requirements This section defines the requirements for how presentity is able to authorize the presence subscriptions. Generic SIMPLE data manipulation requirements are listed in [10]. AUTH-REQ1: Standardized setting of authorization policy There must be a standardized mechanism for the presentity 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. AUTH-REQ2: Extensibility of authorization policy 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. AUTH-REQ3: 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. As an example, only watchers belonging to a particular group are allowed to receive information related to presentity's location. Internet-Draft Expires: August 29, 2003 Page 7 Krisztian Kiss 3GPP Presence Requirements February 2003 AUTH-REQ4: Managing the authorization policy from multiple sources 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. AUTH-REQ5: Granularity of access rights 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. AUTH-REQ6: Expiry of access rights It must be possible to grant access rights with an expiry time to a particular watcher or group. AUTH-REQ7: Presence authorization policy manipulation alignment with conferencing The solution for authorization policy manipulation should be aligned with other data manipulation operations used for similar purposes (such as conferencing). AUTH-REQ8: Authorization of subscriptions generated on behalf of another user It must be possible for the Presence Server to authorize subscriptions to presentityÆs presence information which are generated on behalf of another user. It should be possible for the presentity to set authorization rules taking into account both the identity of the watcher and the identity of the user on whose behalf the subscription is made. 3.6 Watcher information requirements WATCHINF-REQ1: 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. WATCHINF-REQ2: Watcher information filtering It must be possible for the presentity to monitor the watcher status of certain watchers. Note that there are detailed watcher information filtering requirements listed in [21]. Internet-Draft Expires: August 29, 2003 Page 8 Krisztian Kiss 3GPP Presence Requirements February 2003 WATCHINF-REQ3: 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). 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. 3.7 Presencelist requirements PRLIST-REQ1: Filtering for presentity collection It must be possible for the Resource List Server [9] to construct and store appropriate filtering rules for every URI in the presencelist based on the watcher's filtering preferences. PRLIST-REQ2: Management of presentity collection data element Requirements for creating a presentity collection, adding new URIs to an existing presentity collection, modifying or removing existing URIs from an existing presentity collection, or deleting a presentity collection are listed in [10]. 4. Security requirements Presence specifications must not preclude authentication on behalf of presence entities by other entities within a trust domain, and communication as defined by RFC 3325 [33]. 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. 5. Charging Requirements This document refers to the charging requirements of [19], and does not list any additional charging requirements at this time. 6. Proposal for next steps It is proposed that 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. Normative References 1. S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Internet-Draft Expires: August 29, 2003 Page 9 Krisztian Kiss 3GPP Presence Requirements February 2003 2. S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Informative References 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-10.txt, January 2003, work in progress 8. H. Sugano, S. Fujimoto, G. Klyne, A. Bateman: "CPIM Presence Information Data Format", draft-ietf-impp-cpim-pidf- 07.txt, December 2002, work in progress 9. A. Roach, J. Rosenberg, B. Campbell, " A Session Initiation Protocol (SIP) Event Notification Extension for Collections", draft-ietf-simple-event-list-00.txt, February 2003, work in progress 10. J. Rosenberg, M. Isomaki, "Requirements for Manipulation of Data Elements in SIMPLE Systems", draft-ietf-simple-data- req-01.txt, February 2003, work in progress 11. J. Rosenberg, "A Session Initiation Protocol (SIP) Event Template-Package for Watcher Information", draft-ietf-simple- winfo-package-05.txt, January 2003, work in progress 12. J. Rosenberg, "An Extensible Markup Language (XML) Based Format for Watcher Information", draft-ietf-simple-winfo- format-04.txt, January 2003, 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 Presence specific Event Notification Filters", draft-moran-simple-pres- filter-reqs-00.txt, January 2003, work in progress 15. B. Campbell, S. Olson, J. Peterson, J. Rosenberg, B. Stucker, "SIMPLE Presence Publication Mechanism", draft-olson- simple-publish-01, October 2003, work in progress Internet-Draft Expires: August 29, 2003 Page 10 Krisztian Kiss 3GPP Presence Requirements February 2003 16. A. Niemi, "Requirements for Limiting the Rate of Event Notifications", draft-niemi-sipping-event-throttle-reqs-00, January 2003, 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", RFC 3329, January 2003 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 20. J. Costa-Requena, E. Leppanen, H. Khartabil, M. Lonnfors, "Partial Notification of Presence Information", draft- lonnofors-simple-partial-notify-00.txt, January 2003, work in progress 21. K. Kiss, E. Leppanen, H. Khartabil, "Requirements for Filtering of Watcher Information", draft-kiss-simple-winfo- filter-reqs-00.txt, February 2003, work in progress 22. J. Costa-Requena, E. Leppanen, H. Khartabil, M. Lonnfors, "Event Notification Filtering for Presence", draft-khartabil- simple-presence-filter-00.txt, January 2003, work in progress 23. B. Campbell, S. Olson, J. Peterson, J. Rosenberg, B. Stucker, "SIMPLE Presence Publication Requirements", draft- ietf-simple-publish-reqs-00, February 2003, work in progress 24. 3GPP TS 23.228 "IP Multimedia Subsystem (IMS) (Stage 2) - Release 5", Version 6.0.1 available at ftp://ftp.3gpp.org/specs/latest/Rel-5/23_series/ 25. 3GPP TS 24.228: "Signaling flows for the IP Multimedia call control based on SIP and SDP", Version 5.3.0 available at ftp://ftp.3gpp.org/specs/archive/24_series/24.228/ 26. 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP, stage 3", Version 5.3.0 available at ftp://ftp.3gpp.org/specs/archive/24_series/24.229/ 27. 3GPP TS 22.141: "Presence Service, Stage 1", Version 5.2.0 available at ftp://ftp.3gpp.org/specs/archive/22_series/22.141/ 28. 3GPP TS 23.141: "Presence Service, Architecture and Functional Description, Stage 2", Version 6.1.0 available at ftp://ftp.3gpp.org/specs/archive/23_series/23.141/ Internet-Draft Expires: August 29, 2003 Page 11 Krisztian Kiss 3GPP Presence Requirements February 2003 29. 3GPP TS 24.841: "Presence service based on Session Initiation Protocol (SIP); Functional models, information flows and protocol details", Version 0.5.0 available at ftp://ftp.3gpp.org/specs/latest-drafts 30. V. Gurbani, K. Kiss, P. Kyzivat, M. Lonnfors, J. Rosenberg, H. Schulzrinne, "RPIDS -- Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP)", draft-schulzrinne-simple-rpids-02.txt, February 2003, work in progress 31. R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003 32. International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, 1991. 33. C. Jennings, J. Peterson, M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002 Author's address Krisztian Kiss Nokia P.O. Box 100 FIN-33721 Tampere, Finland Tel: +358 50 4835363 e-mail: krisztian.kiss@nokia.com Appendix A. Contributors The author would like to thank the following people for their interest, support and efforts when writing this Internet- Draft: Gabor Bajko (Nokia), Markus Isomaki (Nokia), Mikko Lonnfors (Nokia), Juha Kalliokulju (Nokia), Eva-Maria Leppanen (Nokia), Georg Mayer (Nokia), Mark Beckmann (Siemens), Sonia Garapaty (Nortel), Jayshree Bharatia (Nortel), Keith Drage (Lucent), Andrew Allen, Kevan Hobbis (3), Alexandre Harmand (O2), Duncan Mills (Vodafone), Miguel A. Garcia (Ericsson), Milo Orsic (Lucent), Hugh Shieh (AWS), Aki Niemi (Nokia). 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: August 29, 2003 Page 12 Krisztian Kiss 3GPP Presence Requirements February 2003 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 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: August 29, 2003 Page 13