1. XCON IETF 65 March 20 th, 2006 Dallas, TX, USA

2. Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an “IETF Contribution”. Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: –the IETF plenary session, –any IETF working group or portion thereof, –the IESG, or any member thereof on behalf of the IESG, –the IAB or any member thereof on behalf of the IAB, –any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, –the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3978 and RFC 3979. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3978 for details.

3. Administrative Tasks Minute Taker? XMPP Scribe? Blue Sheets

4. Agenda TimeLength Discussion Leader Topic 1740 - 17455 minChairsAgenda Bash 1745 - 175510 minChairsStatus Update 1755 - 181520 minMary BarnesFramework: Open Issues 1815 - 18205 minOscar NovoConferencing Common Data Model 1820 - 18255 minOscar NovoConference State Change Protocol 1825 - 193570 minChairsProtocol Decision 1935 - 195015 minGonzalo CamarilloBFCP Connection Establishment

5. Status Floor Control Requirements Published as RFC 4376 Conferencing Scenarios still in RFC Editor’s Queue BFCP in RFC Editor’s Queue Framework document has very few open issues remaining (primarily around whispering, data model, and control protocol)

6. Status (Continued) Still need to finalize framework and data model Need to complete work around media manipulation (including quite probably media sent to a subset of participants) Must identify (and maybe define) protocol for conference state manipulation

7. Protocol Selection Three Protocols Go In – Only One Leaves Standing

8. U.S. President Dwight D. Eisenhower Born right here in Texas (a short 3-hour drive from this very room) President of Columbia University 1948-1953, a scant 44 years before SIP emerged from it Known for easing Cold War tensions Will make decisions here today if you can’t

9. More Than One Way To Do It? Been proposed on the list, and has received support from more than one party. Can we declare consensus around this proposal? If we do this, we need to select from one of four models: 1.The focus must implement all protocols; the endpoints may choose one. 2.The endpoints must implement all protocols; the focus may choose one. 3.Both endpoints and focuses must implement a specified protocol, and may implement others. 4.Endpoints and focuses implement whichever of the protocols they want; arbitrary combinations of implementations simply don’t work together.

10. Evaluation Criteria Do we have a requirement to support high-end, very rich endpoints? Do we have a requirement to support wireless mobile terminals? XML Versus Binary (readability versus size) Number of Protocol Stacks in Client Means of Access to Conference State Is Atomicity of Operations Required? What is the must-support set of operations? How is modification of the Template part handled? How much implementation experience can we leverage?

11. Targeted Endpoints Issue has been raised on the list: “Is this just for mobile devices or are we truly building an intelligent endpoint capable protocol?” Are there things that one protocol can do that the others can’t?

12. XML Versus Binary Complexity of implementing the parser is likely a wash, since both XML and the proposed binary protocol are likely to be required in XCON endpoints for other purposes already XML is easier to read without the assistance of tools Proposed binary encoding is comparatively compact

13. Number of Protocol Stacks Most XCON clients and servers can be assumed to already contain SIP, BFCP, XCAP, and arguably HTTP stacks, as well as XML parsers. CCCP arguably adds a new “stack” for (e.g.) message correlation, error codes, error handling, etc. SOAP approaches arguably add a new requirement for a SOAP “stack” (if SOAP is not already in use) meeting W3C specifications CSCP requires new operations in an existing stack.

14. In-Band Access to Conference State Synchronous: Can we retrieve specific state using the protocol, or do we need to use the SIP event package? Asynchronous: How are we notified of updates to the state? –SIP Events prompt us to synchronously retrieve state? –SIP Events deliver state? –CCP async events notify us to synchronously retreive state? –CCP async events deliver state? Does this really impact protocol decision? It seems that all four proposal can be trivially adapted to meet any of the four models.

15. Atomicity of Operations Do we need all-or-nothing change sets of multiple operations? Do we need this in a general sense (i.e., the ability to change two arbitrary bits of data), or can we identify atomic blocks of data that need to be changed?

16. Minimal Set of Operations What are these? Do all proposals support them (or, at least, is it obvious how to modify all proposals to support them)? –Create/Destroy Conference –Create/Destroy Sidebar –Add/Remove User (Conference) –Add/Remove User (Sidebar) Do we need all of these, or can they be expressed adequately using more primitive primitives? (i.e. do we need “addSidebar()”, or will “add(sidebar)” get the idea across?) Is it okay to have just these basic operations plus get/set/add/remove?

17. Template Part Modification Does it matter whether the Template part is handled using significantly different modality than Common Conference Information part? E.g.: –addUser(), and –modifySidebar() for common part, but –add(videoStream), and –modify(volume) for template part, and

18. Implementation Experience Should not be discounted – “running code” is typically given preference in IETF standardization CCCP has been prototyped for half of the problem space and is well understood. Basic SOAP mechanisms are well exercised; their use in conference control has not. CSCP implementation experience: anyone have news to report?

19. CCCP Selling Points Non-trivial implementation experience of Common Conference information part Makes compound operations and conference specific operations explicit and thus easier to implement on a conference server Can be extended to support straight data manipulation for Template information Response model custom tailored for conferencing (instead of generic lock-step request/response model) Transport Independent Extensibility: not constrained to data model Simple event notification mechanism (easy to correlate to CCCP protocol operations) Comparable size to SOAP approaches for common operations such as “mute”

20. CSCP Selling Points Based on BFCP, reducing the number of protocols required to be supported by clients Uses the same operations and model to modify the Template part of conference and the Common Conference Information part of the conference Easy to implement Extremely space efficient (lower latency, e.g., when adjusting volume levels, will create superior user experience)

21. SOAP (CCMP/COMP) Selling Points Based on existing protocols (HTTP and XML) likely to already be in endpoints Automated code generation from WSDL speeds implementation Can be bound to varying transports if necessary Makes compound operations and conference specific operations explicit and thus easier to implement on a conference server Uses the same operations and model to modify the Template part of conference and the Common Conference Information part of the conference