70 likes | 73 Views
Addressing the need for common state manipulation in diverse conference systems, emphasizing semantic operations, and efficient syntax choices.
E N D
Conference State Control Protocol(CSCP) IETF 62 - XCON WG Cullen Jennings
The problem • Checking we agree on: • There is a bunch of state that has to do with how things get mixed • For different conference system this is different • We need a common way to change it • New systems will define new state, and old clients need to be able to manipulate that state too
The Semantics We Need • Read/Write/Add/Delete • Add/Delete require some understanding of what the objects are • Read/Write will have better GUI if one understands but usable with no understanding • Assumption: • The Data Schemas will be defined to conceptually represent the data with the flavor du jour, which is XML
Transactions • 2-phase commits are hard • We don’t need them • Let’s not add them • There are places where many changes need to be made. • The Pipeline approach significantly speeds up these bulk changes without adding much to complexity
The Syntax • Could be EBCDIC over CORBA (not my first choice). Could be SOAP over BEEP, SNMP, Netconf, XCAP, ACAP, WebDAV, HTML Forms, COPS-PR, SOAP, XML-RPC, SIP-T, ONC-RPC, RMI, .NET bindings or the ever popular INFO method • For different environments, different solutions have advantages, and I would somewhat expect to see us end more than one way to manipulate the state
So Why BFCP? • For devices that use BFCP, it turns out doing this with something similar to BFCP works fairly well for more or less the same reasons • If we disagree with these reasons, we should reconsider BFCP • under 100ms round trip response - change volume hear it change • Small footprint • Small messages • We already have to do BFCP
Summary • The Data model is important • The semantics of manipulating it are important • how to name what is being manipulated • what manipulations are possible • the transaction model • error reporting and recovery • how a server can extend the data and still be used by a client that was not “extended” • This work about the syntax is far less important