Conference Control Manipulation Protocol (CCMP) draft-ietf-xcon-ccmp-01.txt Authors: Mary Barnes ([email protected]) Chris Boulton (cboulton@a vaya.com ) Simon Pietro Romano ([email protected]) Henning Schulzrinne ( [email protected]) XCON WG IETF-73 Meeting Minneapolis, Minnesota, Thursday November 20, 200
27
Embed
Conference Control Manipulation Protocol (CCMP) draft-ietf-xcon-ccmp-01.txt
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
– for a “non-independent” child, changes to the parent impact the child
– ‘ConfObjId’ element in a ‘create’ request signifies a parental conference object
Proposal: Update data model for this element(s) Clarify text in document
22 XCON Protocol: CCMP November 20, 2008
Open issues as per IETF 72 (2/5)
Currently, only discrete element within <conference-info> element for which we’ve defined a request/response type is the <users> element— Should we define additional methods/messages such as allowed-users-
list, deny-users-list, join-handling, etc.?
— If so, which (or all)?
Proposal: — add those that facilitate use cases/call
flows
23 XCON Protocol: CCMP November 20, 2008
Open issues as per IETF 72 (3/5)
The (new version of the) protocol works fine..
..but work is still needed in order to:—complete its specification;
—add table to show which headers apply to which messages, in terms of mandatory versus optional, etc.;
—work call flows in parallel to validate protocol and to provide input to prototype.
24 XCON Protocol: CCMP November 20, 2008
Open issues as per IETF 72 (4/5)
Define a Role Based Access Control (RBAC) system to manage access policies to the system:
—Which users can access/modify/create objects in the system?
—Which fields of a conferencing object should be made available to which users?
Can XACML do the job?
Can the RBAC system be realized as a 100% independent component of the overall framework?
Proposal:—work on RBAC system in parallel with prototype bring details
back to XCON
—Define policies and roles in a companion document
25 XCON Protocol: CCMP November 20, 2008
Open issues as per IETF 72 (5/5)
We need to manage notifications!
Options:— stick to SIP notification— HTTP "call back”
– the CCMP client provides the conference server with an HTTP URL which is invoked when a change occurs
— both of the above models appropriately combined?– PC-based clients behind NATs provide a SIP event URI– web servers would probably find the HTTP model much easier to program with
— BOSH (http://xmpp.org/extensions/xep-0124.html)?– "...a transport protocol that emulates a bidirectional stream between two entities
(such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of polling or asynchronous chunking.“
– Also discussed at the BLISS meeting…— XMPP (à la CONFIANCE in its distributed version)— Plain sockets (with asynchronous notifications...)— …more?
26 XCON Protocol: CCMP November 20, 2008
Way Forward
Move forward based on Issue resolution
Continue evolving protocol and prototype
Solicit additional feedback from WG and potential developer community