Dispatch K. Li
Internet-Draft Huawei Technologies
Intended status: Standards Track March 1, 2010
Expires: September 2, 2010
Condition-based URI Selection (CBUS) using the Session Initiation
Protocol (SIP)
draft-li-dispatch-cbus-00
Abstract
This specification defines CBUS requirements for the SIP interface
between the CBUS Client and the CBUS server, based on the
requirements in OMA.
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 September 2, 2010.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Li Expires September 2, 2010 [Page 1]
Internet-Draft Condition Based URIs Selection March 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Li Expires September 2, 2010 [Page 2]
Internet-Draft Condition Based URIs Selection March 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. URI selection examples . . . . . . . . . . . . . . . . . . . . 5
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. URI selection based on simple conditions . . . . . . . . . 5
4.3. URI selection based on combined conditions . . . . . . . . 6
4.4. URI selection using candidate URIs . . . . . . . . . . . . 6
4.5. URI selection using reference URI . . . . . . . . . . . . 6
5. Use-case examples . . . . . . . . . . . . . . . . . . . . . . 6
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. CBUS Client Requirements . . . . . . . . . . . . . . . . . 7
6.2. CBUS Server Requirements . . . . . . . . . . . . . . . . . 7
7. Package Details: Event cbus-uri-list . . . . . . . . . . . . . 7
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.2. Event Name . . . . . . . . . . . . . . . . . . . . . . . . 7
7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 8
7.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8
7.5. State Agents . . . . . . . . . . . . . . . . . . . . . . . 8
8. XML Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.2. CBUS Condition Data Format . . . . . . . . . . . . . . . . 9
8.2.1. <condition-set> element . . . . . . . . . . . . . . . 9
8.2.2. The <candidate-list> element . . . . . . . . . . . . . 9
8.2.3. The <entry> element . . . . . . . . . . . . . . . . . 9
8.2.4. The 'information-type' attribute . . . . . . . . . . . 10
8.2.5. The <condition-list> element . . . . . . . . . . . . . 10
8.2.6. The <condition> element . . . . . . . . . . . . . . . 11
8.2.7. The <ns-bindings> element . . . . . . . . . . . . . . 11
8.2.8. The <trigger> element . . . . . . . . . . . . . . . . 11
8.2.9. The <equals> element . . . . . . . . . . . . . . . . . 11
8.2.10. Namespace . . . . . . . . . . . . . . . . . . . . . . 12
8.2.11. Extensibility . . . . . . . . . . . . . . . . . . . . 12
8.2.12. XML Schema . . . . . . . . . . . . . . . . . . . . . . 12
8.3. CBUS URI List Data Format . . . . . . . . . . . . . . . . 14
8.3.1. The <uri> element . . . . . . . . . . . . . . . . . . 14
8.3.2. The 'match' attribute . . . . . . . . . . . . . . . . 15
8.3.3. Namespace . . . . . . . . . . . . . . . . . . . . . . 15
8.3.4. Extensibility . . . . . . . . . . . . . . . . . . . . 15
8.3.5. XML Schema . . . . . . . . . . . . . . . . . . . . . . 15
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Li Expires September 2, 2010 [Page 3]
Internet-Draft Condition Based URIs Selection March 2010
1. Introduction
Various OMA (Open Mobile Alliance) 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 (Push to
talk Over Cellular) service. However, there is ongoing work in OMA
to define a common mechanism, called CBUS (Condition Based URIs
Selection) enabler [OMA-RD-CBUS-V1_0-20090710-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 the evaluation.
- 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 requestor, 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 entity which receives
the selection request, performs the condition evaluation and returns
the evaluation result to the requestor, is called CBUS Server. The
CBUS server usually resides on the application server, which supports
the CBUS enabler.
The selection of URIs, based on the provided conditions, may be
performed by making evaluation of the user information to find out
whether the conditions are fulfilled or not.
This specification defines CBUS requirements for the SIP interface
between the CBUS Client and the CBUS Server, based on the
requirements defined in "Condition Based URIs Selection Requirements"
[OMA-RD-CBUS-V1_0-20090710-C].
Li Expires September 2, 2010 [Page 4]
Internet-Draft Condition Based URIs Selection March 2010
This specification also defines an event package, which can be used
to return the URI list, and a mechanism for the CBUS client to
provide the requests to the CBUS server.
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 [RFC2119].
3. Terminology
Candidate URI: An identifiable entity that is an input URI to the
CBUS Server for URIs selection.
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).
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
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.
Li Expires September 2, 2010 [Page 5]
Internet-Draft Condition Based URIs Selection March 2010
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 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
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
Li Expires September 2, 2010 [Page 6]
Internet-Draft Condition Based URIs Selection March 2010
6.1. CBUS Client Requirements
REQ C.1: The CBUS Client SHALL be able to provide evaluation
parameters.
REQ C.2: The CBUS Client SHALL be able to subscribe to and receive
notifications about the list of matching URIs and the 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 of conditions 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 a reference URI in
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.
6.2. 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.
7. Package Details: Event cbus-uri-list
7.1. General
This document defines an event package.
7.2. Event Name
The name of this event package is "cbus-uri-list". This package name
is carried in the Event and Allow-Events header fields, as defined in
[RFC3261].
Li Expires September 2, 2010 [Page 7]
Internet-Draft Condition Based URIs Selection March 2010
7.3. SUBSCRIBE Bodies
A SUBSCRIBE request for a cbus-uri-list package SHALL contain a body.
This body can include conditions to be used by the CBUS server for
evaluation, and URI candidates to indcate which URIs upon which the
evaluation is to be performed.
All subscribers and notifiers MUST support the "application/ cbus-
condition+xml" data format for the conditions.
7.4. NOTIFY Bodies
The body of NOTIFY requests for event cbus-uri-list is discussed in
Section [8.3].
In this event package, the body of the notification contains a
document with listed URIs. The listed URIs have been selected based
on the conditions and candidate URIs associated with SUBSCRIBE
request.
All subscribers and notifiers MUST support the "application/ cbus-
uri-list+xml" data format for the URI list.
The associated SUBSCRIBE request SHALL contain an Accept header
field, with a value of "application/cbus-uri-list+xml". Otherwise
the notification server MUST NOT generate notifications containing
the data format describe in Section [8.3].
7.5. State Agents
Separate state agents are not defined for event cbus-uri-list.
8. XML Encoding
8.1. General
This section defines an XML encoded CBUS Condition data format and
the CBUS URI List data format for use with CBUS compliant systems.
The CBUS Condition data payload is expected to be produced by a CBUS
Client, while a CBUS URI List data payload is expected to be produced
by a CBUS Server.
The data formats MUST have the XML declaration and it SHOULD contain
an encoding declaration in the XML declaration. If the charset
parameter of the MIME content type declaration is present and it is
different from the encoding declaration, the charset parameter takes
precedence.
Li Expires September 2, 2010 [Page 8]
Internet-Draft Condition Based URIs Selection March 2010
Every application conformant to this specification MUST accept the
UTF-8 character encoding to ensure the minimal interoperability.
8.2. CBUS Condition Data Format
8.2.1. <condition-set> element
The <condition-set> element contains the set of conditions that apply
to the list of candidate URIs. A request for URI selection based on
simple conditions (see Section 4.2) MUST contain only one <condition-
set> element. A request for URI selection based on combined
conditions (see Section 4.3) MUST contain more than one <condition-
set> element.
The <condition-set> element MAY be omitted when the <candidate-list>
element is included and only contains a <group> element that
identifies a group for which conditions have been pre-defined. In
all other cases the <condition-set> element MUST be included. How to
determine whether there are pre-defined conditions for a group is out
of scope of this specification.
The <condition-set> element MUST contain a <condition-list> element
and an 'information-type' attribute.
8.2.2. The <candidate-list> element
The <candidate-list> element contains the list of URIs that
represents the users to which the conditions apply and among which
the matching URIs are selected.
The <candidate-list> element MAY be omitted. When omitted it means
that the conditions apply to any user and the selection of URIs is
performed by search. The procedure to find the users that fulfill
the conditions is out of scope of this specification.
The <candidate-list> element contains one or more <entry> elements.
8.2.3. The <entry> element
The <entry> element contains a resource list or a reference to a
list.
The <entry> element MUST contain either a <uri>, or <uri-ref>
element.
Li Expires September 2, 2010 [Page 9]
Internet-Draft Condition Based URIs Selection March 2010
8.2.3.1. The <uri> element
The <uri> element is used to specify a single user address.
The <uri> element is an extension to the <entry> element defined for
a resource list document as specified in [RFC4826].
8.2.3.2. The <uri-ref> element
The <uri-ref> element is used to specify the identity of a referenced
resource list, e.g. a shared URI-list stored in a shared database.
How to resolve the identity to a list of URIs that represents the
users in the list is out of scope of this specification.
The <uri-ref> element re-uses the <entry-ref> element defined for a
resource list document as specified in [RFC4826].
8.2.4. The 'information-type' attribute
The 'information-type' attribute is used to specify the type of
evaluation information the conditions are to be evaluated against.
The value of the 'information-type' attribute is of type "string".
Following values are pre-defined: "presence", "location", and "user-
profile".
The "presence" value indicates that the conditions relates to
presence information. The "location" value indicates that the
conditions relates to location information. The "user-profile" value
indicates that the conditions relates to user profile information.
The <condition-set> element is extendable to contain any type of
evaluation information.
8.2.5. The <condition-list> element
The <condition-list> element is used to specify the conditions that
require evaluation from one and the same information source, i.e. of
the same type of evaluation information.
The <condition-list> element MUST contain one or more <condition>
elements.
The <condition-list> element MAY contain one or more <ns-bindings>
elements.
Li Expires September 2, 2010 [Page 10]
Internet-Draft Condition Based URIs Selection March 2010
8.2.6. The <condition> element
The <condition> element is used to specify a condition that applies
to the list of candidate URIs.
The <condition> element MUST contain one or more <trigger> elements.
Multiple appearances of this element denote the "OR" operation. This
means that updates to a resource that satisfy any of the <trigger>
elements criteria constitute that the condition is fulfilled.
The <condition> element MUST contain an 'id' attribute. The value of
the 'id' attribute MUST be unique within the <condition-list>
element.
8.2.7. The <ns-bindings> element
The <ns-bindings> element is used to bind namespaces to local
prefixes used in expressions that select elements or attributes using
the syntax in Section 5 in [RFC4661]. Those prefixes apply to the
<changed> element.
The <ns-bindings> element contains one or more <ns-binding> elements.
Each <ns-binding> element has a 'prefix' attribute. The value of the
'prefix' attribute is a prefix used to qualify the elements pointed
to by the expression. The <ns-binding> element also has a 'urn'
attribute that identifies the namespace that the prefix represents.
8.2.8. The <trigger> element
The <trigger> element is used to specify the information element or
attribute values by which the condition is fulfilled.
The <trigger> element MUST contain one of the <equals>, <equals-dec>,
or <changed> elements.
8.2.8.1. The 'id' attribute
The 'id' attribute is used to specify a unique identity of the
condition within a list of conditions.
8.2.9. The <equals> element
The <equals> element is used to specify a value of an XML element or
attribute that must be fulfilled.
Li Expires September 2, 2010 [Page 11]
Internet-Draft Condition Based URIs Selection March 2010
The namespace identifier for elements defined by this section is a
URN [RFC2141], which uses the namespace identifier 'ietf' defined by
[RFC2648] and extended by [RFC3688]. This urn is:
urn:ietf:params:xml:ns:cbus-conditions.
This namespace declaration indicates the namespace on which the
conditions and candidates are based.
8.2.11. Extensibility
XML Schema Implementation (Normative)
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:cbus-conditions"
xmlns="urn:ietf:params:xml:ns:cbus-conditions"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
xmlns:sf="urn:ietf:params:xml:ns:simple-filter"
elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!--This import brings in IETF 4826 resource-lists namespace-->
<rl:import namespace="urn:ietf:params:xml:ns:resource-lists"/>
<!-- This import brings in the IETF 4661 simple-filter namespace
-->
<sf:import namespace="urn:ietf:params:xml:ns:simple-filter"/>
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition for CBUS Candidates and Conditions.
</xs:documentation>
</xs:annotation>
<xs:element name="candidate-list" type="CandidateListType"
minOccurs="0"/>
<xs:element name="condition-set" type="ConditionSetType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:complexType name="CandidateListType">
Li Expires September 2, 2010 [Page 12]
Internet-Draft Condition Based URIs Selection March 2010
<xs:sequence>
<xs:element name="entry" type="EntryType" minOccurs="1"
maxOccurs="unbounded"/>
<xs:attribute name="added" type="xs:boolean"
use="optional" default="false"/>
<xs:attribute name="removed" type="xs:boolean"
use="optional" default="false"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="EntryType">
<xs:sequence>
<xs:choice>
<xs:element name="uri" type="xs:string"/>
<xs:element name="uri-ref" type="xs:string"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ConditionSetType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:choice>
<xs:attribute name="information-type"
type="xs:string" fixed="presence"/>
<xs:attribute name="information-type"
type="xs:string" fixed="location"/>
<xs:attribute name="information-type"
type="xs:string" fixed="user-profile"/>
<xs:anyAttribute namespace="##other"
processContents="lax"/>
</xs:choice>
</xs:extension>
</xs:simpleContent>
<xs:element name="condition-list" type="ConditionListType"/>
</xs:complexType>
<xs:complexType name="ConditionListType">
<xs:sequence>
<xs:element name="ns-bindings" type="NSBindings"
minOccurs="0" maxOccurs="1"/>
<xs:element name="condition" type="ConditionType"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
Li Expires September 2, 2010 [Page 13]
Internet-Draft Condition Based URIs Selection March 2010
<xs:complexType name="NSBindings">
<xs:sequence>
<xs:element name="ns-binding" type="NSBinding"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="NSBinding">
<xs:attribute name="prefix" type="xs:string" use="required"/>
<xs:attribute name="urn" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="ConditionType">
<xs:sequence>
<xs:element name="trigger" type="InternalTriggerType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="InternalTriggerType">
<!--This is a partly re-use of "TriggerType" from 4661-->
<xs:sequence>
<xs:element name="equals" type="xs:anySimpleType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
8.3. CBUS URI List Data Format
8.3.1. The <uri> element
The <uri> element is used to specify a single user address.
The <uri> element is an extension to the <entry> element defined for
a resource list document as specified in [RFC4826].
The <uri> element MAY contain a 'match' attribute.
Li Expires September 2, 2010 [Page 14]
Internet-Draft Condition Based URIs Selection March 2010
8.3.2. The 'match' attribute
The 'match' attribute is used to specify whether the <uri> element
represents a user that matches the conditions or not. The attribute
is only included if explicitly requested by the CBUS client. The
attribute can be useful for example when the client does not hold an
updated list of selected URIs between the notifications. The value
of the 'match' attribute is of the type "Boolean". The default
value, if omitted, is "true".
8.3.3. Namespace
The namespace identifier for elements defined by this section is a
URN [RFC2141], which uses the namespace identifier 'ietf' defined by
[RFC2648] and extended by [RFC3688]. This urn
is:urn:ietf:params:xml:ns:cbus-uri-list.
This namespace declaration indicates the namespace on which the
conditions and candidates are based.
8.3.4. Extensibility
8.3.5. XML Schema
XML Schema Implementation (Normative)
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:cbus-uri-list"
xmlns="urn:ietf:params:xml:ns:cbus-list"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- This import brings in the IETF 4826 resource-lists -->
<rl:import namespace="urn:ietf:params:xml:ns:resource-lists"/>
Li Expires September 2, 2010 [Page 15]
Internet-Draft Condition Based URIs Selection March 2010
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition for CBUS uri list.
</xs:documentation>
</xs:annotation>
<xs:complexType name="uri-list">
<xs:sequence>
<xs:element name="uri" type="rl:entryType"
minOccurs="1" maxOccurs="unbounded"/>
<xs:attribute name="match" type="xs:boolean"
use="optional" default="true"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
9. Examples
10. Security Considerations
The CBUS Enabler permits mutual authentication, confidentiality and
integrity protection as deployed by the service provider for message
exchanges between CBUS Client and CBUS Server.
11. Acknowledgements
Thanks to Bert Skedinger, Christer Holmberg, Robins GEORGE for their help on the
initial version of the draft.
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Li Expires September 2, 2010 [Page 16]
Internet-Draft Condition Based URIs Selection March 2010
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML)-Based Format
for Event Notification Filtering", RFC 4661,
September 2006.
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.
Author's Address
Kepeng Li
Huawei Technologies
Huawei Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
P. R. China
Phone: +86-755-28787563
Email: likepeng@huawei.com
Li Expires September 2, 2010 [Page 17]