100 likes | 104 Views
This document discusses the protocol development process for the XCON Control Protocol (CCMP) and outlines the way forward for implementation. It covers the background, changes since the previous version, and ongoing discussions and issues. The document seeks comments and questions for further improvement.
E N D
XCON WGIETF-70 Meeting Centralized Conferencing (XCON) Control Protocol (CCMP)draft-barnes-xcon-ccmp-03 Authors: Mary Barnes (mary.barnes@nortel.com) Chris Boulton (cboulton@avaya.com) Henning Schulzrinne (hgs+xcon@cs.columbia.edu)
Contents • Introduction • Background • Changes • Issue Discussion • Way Forward • Comments/Questions
Introduction - General • XCON Conference Framework completed as an XCON WG item • XCON Data model almost done • Foundation for protocol development is now solid
Document Background • Henning presented a strawman proposal using a simple RPC mechanism (SOAP) for the XCON protocol at IETF-63. • WG chair put forth a challenge to produce protocol proposals by year-end 2005: in parallel Henning and Mary/Chris produced XML based protocol proposals • Attempt to gather input for protocol semantics (“verbs/nouns” adhoc at IETF-65) was not successful • WG re-vectored a few months later (mid-2006) to complete current chartered items, specifically focusing on data model and completing framework. • Early 2007 (IETF-68 timeframe), Mary/Chris protocol document combined with Henning’s.
Major changes since -02 version • Removed details about policy. Added a general statement. • Removed section on media control. Added a reference to relevant chartered work in MEDIACTRL. • Renamed "get" operation to "retrieve" to avoid confusion with HTTP GET. • Removed section on "roles". That should be covered in data-model document. • Moved discussion of Conference objectsand identifiers before the protocol operation section, since there were lots of comments/questions about the identifiers from folks in the protocol section. Significantly rewrote the section: • Material was really out of context and confusing (either that or I totally missed what we had intended with that section). • Also, much of it was no longer necessary given the maturity of he XCON data model document has matured (i.e., some of this material was no longer correct and/or redundant).
Document Issues/discussion • Document proposes the use of WSDL. Suggestions to use OASIS WSRF and CAMEL (for policy/permissions): • Discussion and feedback from APPS AD in another WG (GEOPRIV) indicates that WSDL has fallen out of favor • Should we remove the WSDL from this document?
Document Issues/discussion • Schema is lacking in detail • Is there general support for this approach? • Would folks consider reviewing for consideration as WG document once additional schema detail is added?
Document Issues/discussion • Error codes • Current approach follows the SIP/HTTP model of numeric error code and string • Should we follow that approach or define XML tokens for errors? Something like: <xs:simpleType name="response-code-type"> <xs:restriction base="xs:string"> <xs:enumeration value="success"/> <xs:enumeration value="pending"/> <xs:enumeration value=“modified"/> <xs:enumeration value=“badRequest"/> <xs:enumeration value=“unauthorized"/> <xs:enumeration value=“forbidden"/> <xs:enumeration value=“objectNotFound"/> <xs:enumeration value=“methodNotAllowed"/> <xs:enumeration value=“deleteFailedParent"/> <xs:enumeration value=“modifyFailedProtected"/> <xs:enumeration value=“requestTimeout"/> <xs:enumeration value=“serverInternalError"/> <xs:enumeration value=“notImplemented"/> </xs:restriction> </xs:simpleType>
Way Forward • Update document: • Tidy up front sections (some stale and missing references and stale information) • Continue to add protocol detail • Solicit additional feedback from WG and potential developer community • Propose to add to XCON charter once other WG deliverables are completed