idnits 2.17.1 draft-holmberg-dispatch-cbus-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 27, 2009) is 5419 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3023' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC3265' is defined on line 314, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DISPATCH Working Group C. Holmberg 3 Internet-Draft Ericsson 4 Expires: November 28, 2009 May 27, 2009 6 Requirements for a Condition-based URI Selection (CBUS) using the 7 Session Initiation Protocol (SIP) 8 draft-holmberg-dispatch-cbus-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 28, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This specification defines CBUS requirements for the SIP interface 47 between the CBUS Client and the CBUS server, based on the 48 requirements in OMA. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. URI selection examples . . . . . . . . . . . . . . . . . . . . 4 56 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. URI selection based on simple conditions . . . . . . . . . 5 58 4.3. URI selection based on combined conditions . . . . . . . . 5 59 4.4. URI selection using candidate URIs . . . . . . . . . . . . 5 60 4.5. URI selection using search . . . . . . . . . . . . . . . . 5 61 4.6. URI selection using reference URI . . . . . . . . . . . . . 5 62 5. Use-case examples . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.2. CBUS Client Requirements . . . . . . . . . . . . . . . . . 6 66 6.3. CBUS Server Requirements . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Various OMA service enablers need to be able to retrieve a list of 74 addresses (URIs), where the users associated with the URIs fulfil 75 certain conditions. User information is evaluated against the 76 conditions, and the matches form a URI list. 78 The need for the functionality originates from the OMA PoC service. 79 However, there is ongoing work in OMA to define a common mechanism, 80 called CBUS enabler [OMA-RD-CBUS-V1_0-20090203-C], to provide the 81 functionality, so that it can be used for various types of services 82 (e.g. messaging, gaming, conferencing and advertisement). 84 The CBUS enabler provides the following functions: 86 - Support for requestor initiated condition-based URIs selection 87 requests. 89 - Administration of conditions for URI selection. 91 - Interaction with other enablers for retrieval of individual user's 92 information (e.g. presence information, location information). 94 - Evaluation of conditions and selection of matching individual users 95 based on one time evaluation. 97 - Re-evaluation of conditions and re-selection of matching individual 98 users based on monitoring. 100 - Aggregation of one-time evaluation results and monitoring results 101 from different information sources. 103 - Notification of evaluation results to requestor. 105 The conditions may be based on user information which changes over 106 time (e.g. presence information or geographical location), but they 107 can also be based on more static user information (e.g. hobbies or 108 personal interests). 110 The entity which acts as requester, and provides the conditions to be 111 used for the user information evaluation, is called CBUS client. The 112 CBUS client usually resides on the user equipment, or an application 113 server, which supports the CBUS enabler. 115 The selection of URIs, based on the provided conditions, may be 116 performed by taking a snapshot, i.e. by making a one-time evaluation 117 of the user information to find out whether the conditions are 118 fulfilled or not. The URI selection may also be performed by 119 continous monitoring of the user information. 121 This specification defines CBUS requirements for the SIP interface 122 between the CBUS Client and the CBUS Server, based on the 123 requirements in "Condition Based URIs Selection Requirements" [OMA- 124 RD-CBUS-V1_0-20090203-C]. 126 The CBUS client actions triggered by the received URI list, and the 127 interactions between the CBUS server and other enablers, are outside 128 the scope of this specification. 130 2. Conventions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in BCP 14, RFC 2119 135 [RFC2119]. 137 3. Terminology 139 Candidate URI: An identifiable entity that is an input URI to the 140 CBUS Server for URIs selection (e.g. group identity or individual 141 user address). 143 Condition: One of a set of expressions that must be matched in order 144 for a URI to be selected. 146 Evaluation information: The set of user information relevant for the 147 evaluation of CBUS Conditions (e.g. presence information, location 148 information). 150 Evaluation parameter: A setting that controls the evaluation of 151 conditions by the CBUS Server (e.g. one-time evaluation, periodical 152 evaluation, the interval between re-evaluation). 154 Reference URI: An identifiable entity that is designated as a 155 reference for comparing the corresponding evaluation information with 156 all candidate URIs during the evaluation. 158 Selected URI = An identifiable entity that matches the conditions and 159 is an output URI from the CBUS server. 161 4. URI selection examples 162 4.1. General 164 This chapter shows different types of URI selections supported by 165 CBUS. 167 4.2. URI selection based on simple conditions 169 The provided conditions require evaluation of users based on user 170 information from a single information source. 172 4.3. URI selection based on combined conditions 174 The provided conditions require evaluation of users based on user 175 information from multiple information sources. 177 4.4. URI selection using candidate URIs 179 The requestor provides, in addition to the conditions, a list of 180 candidate URIs. Evaluation will be done only against the users 181 represented by the candidate URIs. 183 4.5. URI selection using search 185 The requestor does not provide a list of candidate URIs. 187 4.6. URI selection using reference URI 189 The requestor provides conditions and a reference URI. The 190 evaluation will be done against the reference URI. 192 5. Use-case examples 194 Alice has a number of friends. Each friend has an address 195 represented by a URI. Alice is walking in the city, and figures out 196 that there is an interesting exhibition at the city art museum. 197 Alice wants to know if any of her friends are also in the city, and 198 would like to join her to the museum, and uses the CBUS service to 199 retrieve a list of URIs representing friends that may want to join 200 her. 202 Alice triggers a CBUS subscription. The subscription contains 203 candidate URIs, representing her friends, and two conditions: a 204 geographical condition that the friend has to be in the city, and a 205 hobby condition that the friend has to be interested in art. 207 The CBUS server contacts a location enabler, and an enabler which 208 contains hobbies and interests of persons, using the received 209 geographical condition as input to location enabler and the received 210 hobby condition as input to the enabler containing hobbies. By 211 evaluating the information received from the enablers the CBUS server 212 detects a match for Bob: Bob is in the city, and he is interested in 213 art. The CBUS server sends a notification to Alice, which contains 214 Bob's URI. Alice then contacts Bob and asks whether he wants to join 215 her to the museum. 217 6. Requirements 219 6.1. General 221 6.2. CBUS Client Requirements 223 REQ C.1: The CBUS Client SHALL be able to subscribe to a list of 224 matching URIs based on conditions, a list of candidate URIs and a set 225 of evaluation parameters provided by the CBUS client. 227 REQ C.2: The CBUS Client SHALL be able to subscribe to and receive 228 notifications about changes to the list of matching URIs. 230 REQ C.3: The CBUS Client SHALL be able to provide stand-alone 231 condition or a combination of conditions. 233 NOTE: A combination can be based on a combination of e.g. presence 234 information, location information and user profile information. 236 REQ C.4: The CBUS Client SHALL be able to provide a list of candidate 237 URIs, from which the matching URIs are to be selected. 239 REQ C.5: The CBUS Client SHALL be able to specify the following types 240 of evaluation, which indicate when the CBUS server shall notify the 241 requestor about evaluation results: one-time evaluation result, 242 periodic evaluation result and evaluation result due to change of 243 evaluation information. 245 REQ C.6: The CBUS Client SHALL be able to specify the duration of the 246 subscription. 248 REQ C.7: The CBUS Client SHALL be able to specify the time interval 249 between evaluations of conditions, if periodic re-evaluation is 250 requested. 252 REQ C.8: The CBUS Client SHALL be able to specify the minimum and 253 maximum number of matching URIs to be included in a notification. 255 REQ C.9: The CBUS Client SHALL be able to specify a reference URI in 256 the selection request. 258 NOTE: A reference URI can be used to select URIs that compared to the 259 reference URI match certain conditions, e.g. are located within a 260 radius of 500 m from the location of a user identified by the 261 reference URI. 263 REQ C.10: The CBUS Client SHALL be able to request the CBUS related 264 capabilities of the CBUS server, e.g. the types of evaluation 265 information supported and type of evaluations supported. 267 REQ C.11: The CBUS Client SHALL be able to request to add or remove 268 candidate URIs to an ongoing subscription to evaluation results. 270 6.3. CBUS Server Requirements 272 REQ S.1: The CBUS server SHALL be able to notify the requestor with a 273 list of matching URIs based on input provided by the CBUS client. 275 NOTE: See the CBUS client requirements for the type of information 276 which can be provided by the CBUS client. 278 REQ S.2: The CBUS server SHALL be able to perform the following types 279 of evaluation of candidate URIs: one-time evaluation, periodic re- 280 evaluation and re-evaluation at change of evaluation information. 282 REQ S.3: The CBUS server SHALL be able to limit a list of matching 283 URIs where the requested maximum number of URIs have been exceeded. 285 NOTE: How the CBUS server determines which URIs to include when the 286 number of matching URIs is larger than requested is out of scope of 287 this specification. 289 REQ S.4: The CBUS server SHALL be able to suppress notifications of 290 matching URIs, if the number of matching URIs is less than the 291 minimum number of matching URIs requested. 293 REQ S.5: The CBUS server SHALL be able to add and remove candidate 294 URIs to an ongoing subscription. 296 7. Acknowledgements 298 Thanks to Bert Skedinger for his help on the initial version of the 299 draft. 301 8. Normative References 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, March 1997. 306 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 307 Types", RFC 3023, January 2001. 309 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 310 A., Peterson, J., Sparks, R., Handley, M., and E. 311 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 312 June 2002. 314 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 315 Event Notification", RFC 3265, June 2002. 317 Author's Address 319 Christer Holmberg 320 Ericsson 321 Hirsalantie 11 322 Jorvas 02420 323 Finland 325 Email: christer.holmberg@ericsson.com