Subject: [dispatch] Charter proposed: CBUS

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 21 Sep 2009 13:24:43 +0200

Hi,

Below is the proposed charter for CBUS.

Regards,

Christer

-----------------------------------------

CBUS Charter.
=============

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 can 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 continous monitoring of
the user information.

Work and deliverables:
----------------------

The purpose of the work is to, based on the OMA CBUS requirements (OMA-
RD-CBUS-V1_0-20090203-C), procude the SIP protocol information elements
which are needed to implement the interface between the CBUS client and
CBUS server, using the SIP SUBSCRIBE/NOTIFY framework (RFC 3265).

The primary task for the work is to:

1. Procude a mechanism for a subscriber (CBUS client) to, when
subscribing to an event package which contains a list of URI, provide
conditions, candidate URIs and evaluation parameters to the notifier
(CBUS server). 
The mechanism may be used on defining an XML based message body type,
and SIP header field parameters.

2. Produce an event package, or possible re-use an existing event
package, used to the notifier (CBUS server) to send URI lists (based on
the conditions and candidate URIs) to the subscriber (CBUS client).

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 the work.

The work is planned to take place in, or in co-operaton with, the
SIPCORE WG.

Goals and milestones:
---------------------

Jan 2010	Working Group Last Call for the document which contains
the mechanism for a
            subscriber to provide the needed CBUS information to the
notifier, and
            contains the event package (if a new package is needed) for
the 
            notifier to provide the URI list to the subscriber.

Mar 2010    Submit document to IESG as Proposed Standard

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 22 Sep 2009 16:38:22 +0200

Christer, I see value in a general mechanism for selectively retrieve
lists of URIs, but am wondering whether this is actually a charter
proposal (in such case I guess the text requires heavy rewording,
defining acronyms as a start) or just an event package registration
request according to rfc3427bis, S.4.1?

Enrico

Christer Holmberg wrote:
> - Support for requestor initiated condition-based URIs selection requests.
> 
>             contains the event package (if a new package is needed) for the

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 22 Sep 2009 21:39:50 +0200

Hi Enrico,
 
If an even package registration, in addition to the body used in the NOTIFY request, also allows the definition of the XML body (and possilbe event header parameters) which is needed in the SUBSCRIBE request (in order to provide the conditions etc), then I agree that it may be enough.
 
Regards,
 
Christer

________________________________

From: Enrico Marocco [mailto:[email-masked]]
Sent: Tue 22/09/2009 16:38
To: Christer Holmberg
Cc: [email-masked]; Gonzalo Camarillo
Subject: Re: [dispatch] Charter proposed: CBUS

Enrico

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 23 Sep 2009 09:13:15 +0200

Well, I'm probably not the right person to answer this, but as I
understand the new RAI process, a non-template even package (that as per
3265 includes definitions of NOTIFY and SUBSCRIBE bodies as well as
Event header parameters) that falls outside the scope of any existing WG
may (should?) be submitted to dispatch as an individual contribution.

However, since this would be the first time S.4.1 is run, I'd suggest to
do that under the guidance of RAI management since the very beginning.

Enrico

Christer Holmberg wrote:
> Hi Enrico,
> 
> If an even package registration, in addition to the body used in the
> NOTIFY request, also allows the definition of the XML body (and
> possilbe event header parameters) which is needed in the SUBSCRIBE
> request (in order to provide the conditions etc), then I agree that
> it may be enough.
> 
> Regards,
> 
> Christer
> 
> From: Enrico Marocco [mailto:[email-masked]] Sent:
> Tue 22/09/2009 16:38 To: Christer Holmberg Cc: [email-masked];
> Gonzalo Camarillo Subject: Re: [dispatch] Charter proposed: CBUS
> 
> 
> 
>> CBUS Charter. =============
>> 
>> Introduction: -------------
>> 
>>  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).
>> 
>> - 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.
>> 
>> The conditions can 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.
>> 
>> 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 continous monitoring of the user information.
>> 
>> 
>> Work and deliverables: ----------------------
>> 
>> The purpose of the work is to, based on the OMA CBUS requirements
>> (OMA- RD-CBUS-V1_0-20090203-C), procude the SIP protocol
>> information elements which are needed to implement the interface
>> between the CBUS client and CBUS server, using the SIP
>> SUBSCRIBE/NOTIFY framework (RFC 3265).
>> 
>> 
>> subscribing to an event package which contains a list of URI,
>> provide conditions, candidate URIs and evaluation parameters to the
>> notifier (CBUS server).
>> 
>> The mechanism may be used on defining an XML based message body
>> type, and SIP header field parameters.
>> 
>> package, used to the notifier (CBUS server) to send URI lists
>> (based on the conditions and candidate URIs) to the subscriber
>> (CBUS client).
>> 
>>  interactions between the CBUS server and other enablers, are
>> outside the scope of the work.
>> 
>> 
>> Goals and milestones: ---------------------
>> 
>> Jan 2010        Working Group Last Call for the document which
>> contains the mechanism for a subscriber to provide the needed CBUS
>> information to the notifier, and contains the event package (if a
>> new package is needed) for the notifier to provide the URI list to
>> the subscriber.
>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 23 Sep 2009 09:17:50 +0200

Hi,

I guess the chairs can give us guidance on this. 

I don't expect a new WG to be formed for this, but we were asked to provide
a charter, so that's what I did :)

Regards,

Christer 

> -----Original Message-----
> Sent: 23. syyskuuta 2009 10:13
> To: Christer Holmberg
> Well, I'm probably not the right person to answer this, but 
> as I understand the new RAI process, a non-template even 
> package (that as per
> 3265 includes definitions of NOTIFY and SUBSCRIBE bodies as 
> well as Event header parameters) that falls outside the scope 
> of any existing WG may (should?) be submitted to dispatch as 
> an individual contribution.
> 
> However, since this would be the first time S.4.1 is run, I'd 
> suggest to do that under the guidance of RAI management since 
> the very beginning.
> 
> Enrico
> 
> Christer Holmberg wrote:
> > Hi Enrico,
> > 
> > request (in order to provide the conditions etc), then I 
> agree that it 
> > may be enough.
> > 
> > Regards,
> > 
> > Christer
> > 
> mechanism, 
> >> used for the user information evaluation, is called CBUS client.
> evaluation 
> >> of the user information to find out whether the conditions are 
> >> fulfilled or not.  The URI selection may also be performed by 
> >> continous monitoring of the user information.
> >> 
> >> 
> information 
> >> elements which are needed to implement the interface 
> between the CBUS 
> >> client and CBUS server, using the SIP SUBSCRIBE/NOTIFY 
> framework (RFC 
> >> 3265).
> >> 
> >> 
> >> package, used to the notifier (CBUS server) to send URI 
> lists (based 
> >> on the conditions and candidate URIs) to the subscriber (CBUS 
> >> client).
> >> 
> >> interactions between the CBUS server and other enablers, 
> are outside 
> >> the scope of the work.
> >> 
> >> 
> >> information to the notifier, and contains the event 
> package (if a new 
> >> package is needed) for the notifier to provide the URI list to the 
> >> subscriber.
> >>