XCON

IETF 65March 20th, 2006Dallas, TX, USA

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.

Administrative Tasks

• Minute Taker?

• XMPP Scribe?

• Blue Sheets

Agenda

TimeLength

Discussion Leader

Topic

1740 - 1745

5 min Chairs Agenda Bash

1745 - 1755

10 min

Chairs Status Update

1755 - 1815

20 min

Mary Barnes Framework: Open Issues

1815 - 1820

5 min Oscar NovoConferencing Common Data Model

1820 - 1825

5 min Oscar NovoConference State Change Protocol

1825 - 1935

70 min

Chairs Protocol Decision

1935 - 1950

15 min

Gonzalo Camarillo

BFCP Connection Establishment

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)

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

Protocol Selection

Three Protocols Go In – Only One Leaves Standing

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

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.

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?

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?

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

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.

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.

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?

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?

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

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?

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”

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)

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