Last Modified: 2004-09-22
| Oct 03 | Submit Requirements for Membership Manipulation for publication as Informational | |
| Oct 03 | Submit Requirements for Basic Floor Control for publication as Informational | |
| Nov 03 | Submit Conferencing Scenarios document for publication as Informational | |
| Nov 03 | Submit Use Cases for Media Topology Control for publication as Informational | |
| Dec 03 | Submit Requirements for Media Topology Control for publication as Informational | |
| Feb 04 | Submit Basic Floor Control Protocol for publication as PS | |
| Mar 04 | Submit Notification Event package extension for conference related events for publication as PS | |
| May 04 | Submit Membership Manipulation Protocol for publication as PS | |
| Jul 04 | Submit Protocol for Media Topology Control for publication |
|
XCON Day 1 11/8/04 1930 Lincoln East
Eric Burger, Scribe Chairs ====== Will WGLC Conference Scenarios Framework Document: First Draft Media Policy underway Conference Policy WGLC closed; ready for IESG Notification Event Package: not started yet Floor Control WGLC closed; ready for IESG CCCP document Need call flows Sidebars will end up incorporated in various documents Conferencing Framework Document (Mary Barnes) ============================================= Should it reference SDP-NEW? Cullen: Confused SDPng with SDP-NEW (RFC2327bis). Recognized the error of his ways. SDP-NEW is OK. Would it be helpful to talk about the insides of the bridge (physical implementations)? Maybe. Referencing Data Model Slide: Roni: Is this the real data model? Having trouble understanding whether data lives in Focus, Conference Policy, or Conference State elements. Clients only see view from Focus. Thought is that only conference-aware participants care about distributed data elements, and they are aware of the different data elements, thus it might work as is. More discussion when we get to CCCP (or, "Back to the USSR"). Hisham: Are we defining red data interfaces (on Basic Data model slide)? A: No. Only shown on slide to show relationships. Will not be doing protocols for exchange here. JDR: Does this deprecate SIPPING Conferencing Framework? A: Not intent JDR: But this does everything the SIPPING Conferencing Framework document does, including the stuff taken out to defer to XCON. Compares the concept to ICE: when we say X, which is Y in SIP. However, cannot see difference between SIPPING and XCON Conferencing Framework. Even the titles are confusing. Rohan: no problem having two WGs doing similar documents; different communities of interest Keith: not waiting on this document in 3GPP Mary: Goal is to have document that developers don't need to read SIPPING document JDR: vehemently disagrees Keith: sees split in the other direction: SIPPING document should reference XCON document Keith: charter isn't all conferencing; framework is only to develop those protocols that are necessary Orit: framework does not define protocols; SIPPING Conference Framework works for SIPPING conferencing framework Chairs: Do we need an XCON Framework Document? Consensus is we do. Resistance left room, so everything is OK :) Conferencing Data Model (Orit Levin) ==================================== Entertaining animations of data flow :) Separating Policy from Actions Markus, Hisham, Aki, Henning: looks like good separation; better model: more control, better semantics Henning: 2 problems to address: description of a conference (may be partially filled-in) and templates; thinks of it as a master document that gets modified JDR: State gets manipulated via SIP, et al. However, Policy can also manipulate state. Moreover, changing Policy can trigger changes in state. JDR: Policy is something independent of State. E.g., Membership is state: if you apply Membership to a new clone, members are not members. E.g., Dial-out list is Policy; if you apply list to a new clone, need to dial-out. "Only Henning completely understands what he means by Policy" -- Orit Aki: likes to use terminology from virtual machines & operating systems. Adam says, "Send text to Orit." Things like Booting a member from a conference becomes easier. Right now, all we get is "Boot Member"; Cullen points out that could be "Boot Temporarily", "Boot from this conference", "Boot from all conferences", "Keep out forever". Current documents don't help here. This is a good approach. Henning: Concepts are good, but need better words to describe them. Chairs Discussion on Framework Changes ====================================== 1. Conference Policy has Two Parts: Split (Templates & Rules? Whatever we want to call them) Cullen: are we talking something new, or just "getting our act together"? JDR: This is the kind of stuff we need in framework document. How to carve up policy in a sane way. What gets modified by CPCP, mumble, and fratz. That belongs there. Orit: Chair slide looks a bit misleading (Change #1); concepts good. Hisham: Not really splitting Policy, but splitting stuff inside into two groups. A: Correct; just working on terminology. A: Do we agree on terminology? No real consensus yes or no. Cullen: Does this mean we would have to change all the existing documents? A: Yes Henning can take the terminology to the list. Aki, too. 2. Media isn't a separate thing from State and Policy. Conference Policy is not separate from Media Policy. Weak consensus taken 3. Conference State Manipulated Directly, not via Policy JDR: We should figure out what we want to accomplish before working on the solution. Markus: OK, so it is all document manipulation. Are we doing anything worthwhile, or are we just creating yet another way of doing state manipulation? A: Some semantics associated with states. Hisham & JDR: Need use cases. E.g., how do I get Focus to INVITE me, instead of me INVITING the conference? Take out "by manipulating Conference Package stuff" from proposal JDR: don't want to confuse commands with document editing. E.g., "Kick everyone out" is when executed. Document editing (kick out current participants) enables new participants to join, still. Orit: agrees Aki: Really want protocol with explicit actions. Henning: Need to be able to monitor entire state of conference. Every command has to make a visible change into the conference state representation. Consensus to go into this direction. Conference Policy (Hisham Khartabil) ==================================== Postponed because out of time. ************************************************ FRIDAY, November 12, 2004, 0900-1130 0900 - 0940 Floor Control - Gonzalo Camarillo (40 minutes) draft-ietf-xcon-bfcp-02.txt * Need to review and make sure section 3 is consistent with the conferencing framework - Alan will, others are welcome to comment * Open issues o How to perform authentication - Digest and TLS - what's mandatory? If you do basic, this is MUST use TLS, not may. Adding nonce to SDP is only to save one RTT. This affects IANA and security considerations. Current text is servers MUST implement TLS, clients SHOULD (or something equivalent). This should make the security types happy. Wouldn't the signaling protocol mechanisms suffice? What's the difference between authentication and conference admission? Can't use a shared secret for both, so need two mechanisms. o Clients initiate transactions, with no timeouts defined now. Define an application-level error recovery mechanism? Need to make sure we don't cause problems when trying to do more than TCP does - we won't define these mechanisms o Clients with several ongoing floor requests at once? We get this for free in the protocol, servers can reject them now if desired. What about requests based on media types? * To be done -IANA considerations, security considerations, SDP format for BFCP (in MMUSIC) * Need volunteers to review this draft - actually, the next version of the draft o Ben Cambell, Dave Morgan, Bob Hughes, Christer, ? * What about multiple floors with one media stream (sidebars, etc). draft-ekim-spping-conf-floor-package-00 * From SIPPING, needs to be discussed here. o Requirement for "richer information than BFCP" - we need to see use cases o Support UAs that don't implement BFCP - will all floor control protocols allow requests for information? o Information about the status of a floor - up to the server to decide when to send notifications, decide what information to include, etc. - event package would allow throttling if needed * Are these reasons compelling? o We just need to see use cases before barreling off. o Two mechanisms doesn't simplify things, because you have to implement both o Throttling is important - can we do this with floor control policy? Out of band? o I already have a SIP UA and know how to do SUBSCRIBE/NOTIFY - this draft adds like, one XML body for these UAs o Could probably implement a reference implementation today that meets these requirements using BFCP * Conclusion - we just need to see use cases, and will discuss in XCON, not SIPPING * We may end up with a parallel SIP-based mechanism anyway - TLS is not a SHOULD for SIP clients, but is for BFCP, and that's a big deal 0940 - 1040 Media Policy - Alan Johnston (60 minutes) draft-jennings-xcon-media-control-01.txt draft-boulton-xcon-media-template-00.txt draft-rosen-xcon-conf-sidebars-01.txt * Core draft has not been updated * Design team has been working on templates, not yet complete (4 of 10 are started) * Want to disband design team and continue discussion on the list * Need a good framework and terminology * Have a preliminary division of work, but won't make decisions until we look at framework and decide on terminology * XCON will likely have an Interim Meeting in January (watch the list for info on this, expect East Coast, 1.5 or 2 days) o Don't have AD approval to do a lot of work in an ad hoc and have work go forward without list discussion - process point o Not a proposal yet (either the design team proposal or the interim meeting proposal!) o Please discuss this on the list, that's the way we do things on the list o Allison would prefer that we work out document structure before working on terminology o Need a heads-up on the list that this is coming, people are commenting on the current drafts and we're thinking about big changes o This doesn't look like huge changes to the existing charter - no change at all, we're changing how we do the work * 3GPP is expecting floor control out of us o Could we get an e-mail on the list about exactly what they expect from us? o Floor control is at least one of the deliverables they need from us o Probably send to IESG after volunteer review o 3GPP likely to give us a list of document names, we need a list of document contents! o We also need to finalize conference event package - not in this working group - what does floor control without an event package mean? At least the event package is in WGLC in SIPPING now, so this should be OK. o Can we formulate conference rules quickly and not wait for terminology? o 3GPP also needs templates, etc. o We'll get clarifications and post them as quickly as possible o 3GPP will eventually need everything in the XCON charter, but probably don't need it all now - if we do this in usable stages, that should be good enough for them. Probably can't wait for everything to finish in order to finalize the rules. o We've had good experience with 3GPP use of our technology so far, and what they're asking for isn't unreasonable o Allison thinks they can give us functionalities again, since we're restructuring all our drafts. Keith and Stephen should be able to discuss this with us. We can have a teleconference (if you want to participate, please contact us and let us know). o Believe 3GPP will be flexible - give them the basics, chat and messaging applications would matter. Basic rules would be enough. |