1. August 2005IETF63 - XCON1 Some XCON ideas Henning Schulzrinne Dept. of Computer Science Columbia University hgs@cs.columbia.edu

2. August 2005IETF63 - XCON2 Assumptions Avoid transactions and similar constructions –difficult to implement –  request is atomic Map closely to existing conference data structures –avoids having to maintain two similar, but different structures –use superset of existing structure Avoid two-level mechanism Re-use well-known RPC mechanism Use inheritance (no templates) –closely related concepts – confusing to have both Affinity to CCCP, but further simplified

3. August 2005IETF63 - XCON3 Avoid two-level design “dial-out user” get/set/delete something adds little abstraction depth

4. August 2005IETF63 - XCON4 Re-use RPC No need to design yet another remote procedure call (RPC) mechanism Use SOAP – not prettiest, but by far the most popular –clients, servers, tools available in just about any language and OS don’t know about Fortran and COBOL –well-understood by developer community –no need for protocol-level testing

5. August 2005IETF63 - XCON5 Example Does not include standard SOAP header e.g., addConference XCON http://example.com/ web-page

6. August 2005IETF63 - XCON6 Operations (~CCCP) add/change/get/deleteX –Conference –User –Endpoint –Media (for all users)

7. August 2005IETF63 - XCON7 Open issues For adding users, can request fail partially –may want to add lots of users at once –add some users, but not others –generally want to proceed even if one user fails –can find out who got added by description returned

8. August 2005IETF63 - XCON8 What’s missing? Simple start/end time property for conference –no repeats or the like Conference media mixing –add floor control property to media –add moderator(s) to user property –define some standard algorithms for now tiled: ““video follows audio” no video mixing: “individual” extend later –define video matrix (label, width, height)