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


8.2.10.  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-conditions.

   This namespace declaration indicates the namespace on which the
   conditions and candidates are based.

8.2.11.  Extensibility

8.2.12.  XML Schema

        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]