Slide #1 Minneapolis, March 10, 2005XCON WG, IETF62 draft-levin-xcon-cccp-02.txt Orit Levin Roni Even Pierre Hagendorf

Slide #2 Minneapolis, March 10, 2005XCON WG, IETF62 Overview Content Operations (“Primitives”) RPC Application Protocol Layer Configuration Data BEEP, SSH, SSL, console NETCONF Conference Object,,, …, HTTP, HTTPS, MSRP, … CCCP

Slide #3 Minneapolis, March 10, 2005XCON 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)

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

Slide #5 Minneapolis, March 10, 2005XCON WG, IETF62 Backup Slides

Slide #6 Minneapolis, March 10, 2005XCON 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”

Slide #7 Minneapolis, March 10, 2005XCON 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

Slide #8 Minneapolis, March 10, 2005XCON WG, IETF62 Transaction Model

Slide #9 Minneapolis, March 10, 2005XCON 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"

Slide #10 Minneapolis, March 10, 2005XCON 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

Slide #11 Minneapolis, March 10, 2005XCON 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.

Slide #12 Minneapolis, March 10, 2005XCON WG, IETF62 Thanks…