draft-levin-xcon-cccp-02.txt Orit Levin oritl@microsoft.com Roni Even roni.even@polycom.co.il Pierre Hagendorf  pierre@radvision.com Minneapolis, March 10, 2005 XCON WG, IETF62

Overview Layer NETCONF CCCP Content Configuration Data Conference Object Operations (“Primitives”) <get-config> <edit-config> <create-xxx>, <move-xxx>, <mute-xxx>, … <get-xml-node>, <set-xml-node> RPC <rpc> <rpc-reply> <request> <response> Application Protocol BEEP, SSH, SSL, console HTTP, HTTPS, MSRP, … Minneapolis, March 10, 2005 XCON WG, IETF62

A “Simple Primitive” Definition Dilemma Example: “Mute a particular media stream” Option 1 muteVoice (conf-id, user-id, media-id) Option 2 modifyMediaStatus (conf-id, user-id, media-id, media-status) Option 3 modifyMedia(conf, user, media-id, media-info) Option 4 setXMLNode(XPATH, value) Minneapolis, March 10, 2005 XCON WG, IETF62

Template Handling Option 1 Option 2 Use data manipulation primitives setXMLNode(XPATH, value) Option 2 Define a Template “Form” Conventions setTemplate (template-id, field-category, field-id, field-value) Minneapolis, March 10, 2005 XCON WG, IETF62

Backup Slides Minneapolis, March 10, 2005 XCON WG, IETF62

Working Assumptions Must run over reliable transport, but transport agnostic “Controlling a conference” (i.e. creating and managing it) means “changing the state of the conference object” Minneapolis, March 10, 2005 XCON WG, IETF62

Advantages of syntax as in CCCP-02 Not a Data Manipulation protocol. Any explicit requests can be added and their semantics well-defined Strong type keys allow for automatic syntax validity check of a primitive No XPATH processing is required Conference-info-type and its subtypes can be used as is Additional types (from multiple .xsd) can be used Minneapolis, March 10, 2005 XCON WG, IETF62

Transaction Model Minneapolis, March 10, 2005 XCON WG, IETF62

Proposed Transaction Model CCCP is a transaction client-server protocol Two types of operations: request and response 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 Two final responses are defined: "failure" and "success" Minneapolis, March 10, 2005 XCON WG, IETF62

Proposed Transaction Model (Cont.) Transaction ID requestId: A string generated by the CCCP client and unique for each CCCP request generated by the client from:a URI which identifies the CCCP client to: a URI which identifies the CCCP server Minneapolis, March 10, 2005 XCON WG, IETF62

Proposed Transaction Model (Cont.) 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 for this reason, the primitives inside the operation bodies are not numbered. Minneapolis, March 10, 2005 XCON WG, IETF62

Thanks… Minneapolis, March 10, 2005 XCON WG, IETF62