6 – 11 Nov, 2005 XCON WG, IETF64 Slide #1

draft-levin-xcon-cccp-03.txt

Orit Levin oritl@microsoft.com

Roni Even roni.even@polycom.co.il

Pierre Hagendorf pierre@radvision.com

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #2

Introduction

• An updated and extended version since -02 – a result of an implementation experience

• A new protocol– Not data manipulation (vs. XCAP, WEBDAV),

rather object manipulation– Runs on an arbitrary reliable transport but

does NOT rely on the underlying transport transaction model (vs. SOAP/HTTP)

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #3

Transaction Model• A transaction client-server protocol

• Two types of operations: “request” and “response”

• Two final responses ("failure" and "success“) and a provisional (“pending”)a provisional (“pending”) response are defined

• A client issues requests to a server. A server MAY reply with multiple provisional responses before replying with the final response

• The server MUST reply with a single final response

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #4

Request Attributes

• requestId: A unique string generated by the CCCP client across all its requests

• from: A transport URI of the the CCCP client

• to: A transport URI which of the CCCP server

• originator: A trusted ID of the originator of the request

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #5

Response Attributes• requestId: The original request ID generated by the client and

echoed as is by the server• from: A transport URI of the CCCP server• to: A transport URI of the CCCP client• code: The general response code: success, pending, or failure• reason: The general CCCP failure reason

– serverBusy– unauthorized– requestMalformed– requestTooLarge– requestCancelled– notSupported– otherFailure

• timeout: The updated timeout used with pending responses• retryAfter: The suggested delay used with serverBusy responses

In addition, each primitive response defines a dedicated optional set of response codes

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #6

Multiple Primitives ina Single Operation

• A single CCCP operation MAY include multiple primitives

• Multiple primitives within the same request MUST be executed as an atomic operation.

• The primitives within the request operation MUST be performed by the CCCP server one-by-one in the order they appear in the request body.

• The corresponding response operation MUST include the response primitive for each of the issued primitives in the exact same order. Note, that the primitives inside the operation bodies are not numbered.

• We don’t make usage of this feature in our current implementation

• Instead we defined a dedicated primitive each time an atomic property is desirable

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #7

The Object Manipulation Approach

• The object is identified by keys and accessed directly without navigating through the whole XML document tree

• The sub-elements are accessed, set and modified through the parent object

• The currently identified objects are <conference>, <user>, <endpoint>, <media>, <sidebar>

• The response codes carry application semantics and can be defined per object per primitive

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #8

A Typical Object Manipulation Primitive

<addUser> <conferenceKeys

confEntity="sip:conf233@example.com"/> <user entity="sip:bob@example.com“ xmlns="urn:ietf:params:xml:ns:conference-info"> <display-text>Bob Hoskins</display-text> <roles> <entry>presenter</entry> </roles>

</user></addUser>

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #9

Not Object Manipulation Primitives

• Define dedicated primitives for operations where at least one the following properties are desirable

– Atomic execution (moveUserToSidebar)

– Applied to a set of objects (getBlueprints)

– Efficiency (modifyUserRoles)

• A CCCP server can choose to provide multiple ways (i.e. different primitives) to achieve the same result

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #10

Example

<moveUserToSidebar>

<userKeys confEntity="sip:conf233@example.com" userEntity="sip:bob@example.com"/>

<from>sip:conf233.3@example.com</from>

<to>sip:conf233.7@example.com</to>

</moveUserToSidebar>

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #11

CCCP and Events• For CCCP clients that don’t natively run

SIP, the SIP Events Mechanism can be run using the CCCP additional operation “notify”.

• The events logic mechanism uses the SIP Events framework and the SIPPING Conference Package semantics and format

• The effect of the SIP re-SUBSCRIBE operation is achieved by CCCP getConference() primitive

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #12

The CCCP Notification Mechanism Logically Runs in Parallel to its Control

Client

Control

Mechanism

CCCP Request

Notifications

Mechanism

Server

Control

Mechanism

Notifications

Mechanism

CCCP Response

SIP Client

Control

Mechanism

Notifications

Mechanism

CCCP Request

CCCP Response

SUBSCRIBE

CCCP Notify NOTIFY

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #13

Next Steps

• If XCON WG decides to build on this direction, CCCP is open to modifications

• If XCON WG takes a different CCP approach, we are planning to publish this draft as an Informational

6 – 11 Nov, 2005 XCON WG, IETF64 Slide #14

Thanks…