Internet DRAFT - draft-holmberg-dispatch-cbus
draft-holmberg-dispatch-cbus
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]
