DISPATCH Working Group C. Holmberg Internet-Draft Ericsson Expires: November 28, 2009 May 27, 2009 Requirements for a Condition-based URI Selection (CBUS) using the Session Initiation Protocol (SIP) draft-holmberg-dispatch-cbus-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 28, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This specification defines CBUS requirements for the SIP interface between the CBUS Client and the CBUS server, based on the requirements in OMA. Holmberg Expires November 28, 2009 [Page 1] Internet-Draft EPDG May 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. URI selection examples . . . . . . . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. URI selection based on simple conditions . . . . . . . . . 5 4.3. URI selection based on combined conditions . . . . . . . . 5 4.4. URI selection using candidate URIs . . . . . . . . . . . . 5 4.5. URI selection using search . . . . . . . . . . . . . . . . 5 4.6. URI selection using reference URI . . . . . . . . . . . . . 5 5. Use-case examples . . . . . . . . . . . . . . . . . . . . . . . 5 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2. CBUS Client Requirements . . . . . . . . . . . . . . . . . 6 6.3. CBUS Server Requirements . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Holmberg Expires November 28, 2009 [Page 2] Internet-Draft EPDG May 2009 1. Introduction Various OMA service enablers need to be able to retrieve a list of addresses (URIs), where the users associated with the URIs fulfil certain conditions. User information is evaluated against the conditions, and the matches form a URI list. The need for the functionality originates from the OMA PoC service. However, there is ongoing work in OMA to define a common mechanism, called CBUS enabler [OMA-RD-CBUS-V1_0-20090203-C], to provide the functionality, so that it can be used for various types of services (e.g. messaging, gaming, conferencing and advertisement). The CBUS enabler provides the following functions: - Support for requestor initiated condition-based URIs selection requests. - Administration of conditions for URI selection. - Interaction with other enablers for retrieval of individual user's information (e.g. presence information, location information). - Evaluation of conditions and selection of matching individual users based on one time evaluation. - Re-evaluation of conditions and re-selection of matching individual users based on monitoring. - Aggregation of one-time evaluation results and monitoring results from different information sources. - Notification of evaluation results to requestor. The conditions may be based on user information which changes over time (e.g. presence information or geographical location), but they can also be based on more static user information (e.g. hobbies or personal interests). The entity which acts as requester, and provides the conditions to be used for the user information evaluation, is called CBUS client. The CBUS client usually resides on the user equipment, or an application server, which supports the CBUS enabler. The selection of URIs, based on the provided conditions, may be performed by taking a snapshot, i.e. by making a one-time evaluation of the user information to find out whether the conditions are fulfilled or not. The URI selection may also be performed by Holmberg Expires November 28, 2009 [Page 3] Internet-Draft EPDG May 2009 continous monitoring of the user information. This specification defines CBUS requirements for the SIP interface between the CBUS Client and the CBUS Server, based on the requirements in "Condition Based URIs Selection Requirements" [OMA- RD-CBUS-V1_0-20090203-C]. The CBUS client actions triggered by the received URI list, and the interactions between the CBUS server and other enablers, are outside the scope of this specification. 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 [RFC2119]. 3. Terminology Candidate URI: An identifiable entity that is an input URI to the CBUS Server for URIs selection (e.g. group identity or individual user address). Condition: One of a set of expressions that must be matched in order for a URI to be selected. Evaluation information: The set of user information relevant for the evaluation of CBUS Conditions (e.g. presence information, location information). Evaluation parameter: A setting that controls the evaluation of conditions by the CBUS Server (e.g. one-time evaluation, periodical evaluation, the interval between re-evaluation). Reference URI: An identifiable entity that is designated as a reference for comparing the corresponding evaluation information with all candidate URIs during the evaluation. Selected URI = An identifiable entity that matches the conditions and is an output URI from the CBUS server. 4. URI selection examples Holmberg Expires November 28, 2009 [Page 4] Internet-Draft EPDG May 2009 4.1. General This chapter shows different types of URI selections supported by CBUS. 4.2. URI selection based on simple conditions The provided conditions require evaluation of users based on user information from a single information source. 4.3. URI selection based on combined conditions The provided conditions require evaluation of users based on user information from multiple information sources. 4.4. URI selection using candidate URIs The requestor provides, in addition to the conditions, a list of candidate URIs. Evaluation will be done only against the users represented by the candidate URIs. 4.5. URI selection using search The requestor does not provide a list of candidate URIs. 4.6. URI selection using reference URI The requestor provides conditions and a reference URI. The evaluation will be done against the reference URI. 5. Use-case examples Alice has a number of friends. Each friend has an address represented by a URI. Alice is walking in the city, and figures out that there is an interesting exhibition at the city art museum. Alice wants to know if any of her friends are also in the city, and would like to join her to the museum, and uses the CBUS service to retrieve a list of URIs representing friends that may want to join her. Alice triggers a CBUS subscription. The subscription contains candidate URIs, representing her friends, and two conditions: a geographical condition that the friend has to be in the city, and a hobby condition that the friend has to be interested in art. The CBUS server contacts a location enabler, and an enabler which contains hobbies and interests of persons, using the received Holmberg Expires November 28, 2009 [Page 5] Internet-Draft EPDG May 2009 geographical condition as input to location enabler and the received hobby condition as input to the enabler containing hobbies. By evaluating the information received from the enablers the CBUS server detects a match for Bob: Bob is in the city, and he is interested in art. The CBUS server sends a notification to Alice, which contains Bob's URI. Alice then contacts Bob and asks whether he wants to join her to the museum. 6. Requirements 6.1. General 6.2. CBUS Client Requirements REQ C.1: The CBUS Client SHALL be able to subscribe to a list of matching URIs based on conditions, a list of candidate URIs and a set of evaluation parameters provided by the CBUS client. REQ C.2: The CBUS Client SHALL be able to subscribe to and receive notifications about changes to the list of matching URIs. REQ C.3: The CBUS Client SHALL be able to provide stand-alone condition or a combination of conditions. NOTE: A combination can be based on a combination of e.g. presence information, location information and user profile information. REQ C.4: The CBUS Client SHALL be able to provide a list of candidate URIs, from which the matching URIs are to be selected. REQ C.5: The CBUS Client SHALL be able to specify the following types of evaluation, which indicate when the CBUS server shall notify the requestor about evaluation results: one-time evaluation result, periodic evaluation result and evaluation result due to change of evaluation information. REQ C.6: The CBUS Client SHALL be able to specify the duration of the subscription. REQ C.7: The CBUS Client SHALL be able to specify the time interval between evaluations of conditions, if periodic re-evaluation is requested. REQ C.8: The CBUS Client SHALL be able to specify the minimum and maximum number of matching URIs to be included in a notification. REQ C.9: The CBUS Client SHALL be able to specify a reference URI in Holmberg Expires November 28, 2009 [Page 6] Internet-Draft EPDG May 2009 the selection request. NOTE: A reference URI can be used to select URIs that compared to the reference URI match certain conditions, e.g. are located within a radius of 500 m from the location of a user identified by the reference URI. REQ C.10: The CBUS Client SHALL be able to request the CBUS related capabilities of the CBUS server, e.g. the types of evaluation information supported and type of evaluations supported. REQ C.11: The CBUS Client SHALL be able to request to add or remove candidate URIs to an ongoing subscription to evaluation results. 6.3. CBUS Server Requirements REQ S.1: The CBUS server SHALL be able to notify the requestor with a list of matching URIs based on input provided by the CBUS client. NOTE: See the CBUS client requirements for the type of information which can be provided by the CBUS client. REQ S.2: The CBUS server SHALL be able to perform the following types of evaluation of candidate URIs: one-time evaluation, periodic re- evaluation and re-evaluation at change of evaluation information. REQ S.3: The CBUS server SHALL be able to limit a list of matching URIs where the requested maximum number of URIs have been exceeded. NOTE: How the CBUS server determines which URIs to include when the number of matching URIs is larger than requested is out of scope of this specification. REQ S.4: The CBUS server SHALL be able to suppress notifications of matching URIs, if the number of matching URIs is less than the minimum number of matching URIs requested. REQ S.5: The CBUS server SHALL be able to add and remove candidate URIs to an ongoing subscription. 7. Acknowledgements Thanks to Bert Skedinger for his help on the initial version of the draft. Holmberg Expires November 28, 2009 [Page 7] Internet-Draft EPDG May 2009 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3261] 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. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Author's Address Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Holmberg Expires November 28, 2009 [Page 8]