1. draft-levin-xcon-cccp-02.txt Orit Levin oritl@microsoft.com
Roni Even
Pierre Hagendorf
Minneapolis, March 10, 2005
XCON WG, IETF62

2. 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

3. 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

4. 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

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

6. 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

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

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

9. 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

10. 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

11. 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

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