Centralized Conferencing (XCON) - IETF 64 Agenda CHAIRS: Alan Johnston Adam Roach TUESDAY, November 8th, 2005, 0900-1130 ====================================== Notes : Spencer Dawkins Agenda Bash Chairs (5 minutes) * No changes to the agenda for today Status Update Chairs (10 minutes) Charter: Updating Milestones Chairs (10 minutes) * Floor control requirements is in RFC Editor's queue, BFCP is back with IESG security comments * Still need to finalize framework * Need to reset milestones, reflecting changes on WG view for media control and membership (now want one protocol) * Framework and Data Model next summer, event notification a little later, CCID in October, Template and Control protocol before 2007 * Pushing IM-related work until Conference Control Protocol goes to IESG Floor Control: Epilogue Gonzalo Camarillo (15 minutes) draft-ietf-xcon-bfcp-05.txt draft-ietf-mmusic-sdp-bfcp-02.txt draft-ietf-xcon-floor-control-req-03.txt * Have comments from IESG, most significant are on security * TLS will be mandatory, use comedia to do fingerprint exchange of self-signed certs * Removing digest mechanism from XCON draft * Anyone have a problem with this plan? * MMUSIC draft also has point-to-point scenario - if I have connection with only digest, how do I continue? Actually, Digest is completely removed from XCON - but not from SIP. TLS is for BFCP, not for SIP. * Do you have to use TLS whether you want security or not? No, but TLS will be mandatory - but no one will use it, so the spec is fine... * Need a new document on BFCP connection without offer/answer, would allow digest over TLS, define digest mechanism - any interest? * Adam - we need a use case before we start doing this work? Brian - the use case is that someone calls you on a telephone... Cullen - yeah, we have a use case now * Is this document in the timeframe of the XCON protocol? No, not very long, matter of months - this document is completely independent, can have first draft before Dallas * Allison - other draft is critical for people who don't have this use case, OK to split it out.. All of these documents have a dependency on a TLS draft, Allison will shepherd these. XCON Framework Mary Barnes (45 minutes) draft-ietf-xcon-framework-02.txt * Quite a few updates since IETF 63, lots of constructive feedback * Most changes refine and clarify terminology - slight modifications of definitions, added a few new ones, replaced "XCON" with "Centralized Conferencing" * This is a really good time to read the document if you haven't read it yet * Expanded detail on identifiers in an appendix, will probably be separate document * Did changes/clarifications for Cloning Tree, and removed some terms that aren't needed now * Floor control section is simplified, details are removed, added example on conference creation and reworked security section * Conference policies are not addressed in this document. If we need a policy infrastructure, it will be FFS * Looking at two XML schema structure proposals - new namespace, or reuse namespace * Down to four candidate protocols, netconf is off the table * Don't have explicit requirements for the protocol (they are in SIPPING document) * Some potential derived requirements - could we make progress by abandoning or enforcing them? Will discuss on Wednesday meeting. * Still need to define sidebar, whisper, complete detailed examples in section 7 * Need URI schema for conference object and conference user identifiers * Alternatives proposals for floor control based on templates (based on previous WG discussions) * Who has read most recent version? A fair number of people, silence means something. * Brian - probably more than one version remaining, but this document is "getting there" - if you have input, send text! * Brian - still inconsistent about how many sidebars go with a conference, and whether they are associated by reference or by value - Mary has a diagram, just needs to produce ASCII art... - Brian doesn't care what we do, we just need to pick something and move on XCON Common Data Model Oscar Novo (10 minutes) draft-novo-xcon-common-data-model-00.txt * Have a conference object and a conference template type * XML schema can be extended with templates or future extensions * Brian - how many times have we talked about this? If you want to add new functionality, you'll do a new software release anyway - defining it as "an extension mechanism" is a waste of bits * Henning - how to deal with the other reality? - vendors that have information we want to convey but don't understand ourselves, we will be matching with legacy systems that don't have an RFC, etc. We won't have a self-programming conference server, at least this isn't likely * Orit - Henning's question is about next presentation, so let's defer that. Issue about where to put the templates inside the schema is that we can't distribute information to conference participants until we revise the conference package * Brian - but if an RFC defines a template, it defines a package, which can be a superset * Orit - if we have templates outside, everyone will have a different mechanism to extend them * Henning - having undefined attributes is complexity we don't need today - ditch it, please * Orit - suggestion is to take templates outside? * Henning - yes * Cullen - issue is whether there's an extension in the description, or after the closing angle bracket - that's it, right? "there is an attribute called 'extension', which is extended by RFCs"... * Henning - adding "color of tie you have to wear to a conference" - how does this work? I'm lost * Orit - this schema will use the type from Brian's RFC * Roni - schema is based on event package definition - this isn't state of conference, it's policy for the conference - can't refer to other document because this isn't defined there - how does the conference server decide what to do? Could use any of five codecs based on policy, how does the server pick one? What do you do when the server picks one and a new participant joins and doesn't support that codec? * Dave - but isn't this negotiated by the endpoints anyway? * Roni - but have to know whether to admit endpoint to conference * Dave - wouldn't this be in the template? * Roni - even without a mixer, there are two ways to solve problem of incompatible codecs * Mary - this is multi-step, right? * Roni - looks like you are going the wrong direction because you are using the current state to define the conference, should be deriving the conference state from the conference * Adam - is this a codec problem or a general problem? * Roni - it's a general problem - PIN codes aren't in the event package, for instance * Orit - XCON has moved away from having the conference object contain the state of the conference (for simplicity). This also overlaps with conference reservations - only part of the schema is relavant, only part is being filled with data. * Roni - document doesn't actually say this * Adam - would adding elements to this schema address the concern? * Roni - yes - document doesn't say this is a superset, and it needs to * Orit - published document is preliminary, needs to reflect our discussion * Roni - this schema is the one that will be used by conference control protocol, needs all the information needed to create a conference, but that's not what you need when the conference is running * Orit - will send only information which is relevant * Adam - sounds like people think things are missing - please iron this out on the list rapidly * Extensibility of common conference information data - new namespace or schema extension? Planning to use schema extension - does anyone have opinions? * Mary - schema extension is a better option * Roni - package in SIPPING doesn't have all the required information * Mary - that's why we need to define a new superset that DOES have all the required information * Cullen - Jonathan had some problems when we discussed this - need to look at old draft and remember what these problems were * Does everyone agree on second option? We will go this way (no objections in the room, please tell us if you DO object) * Cullen - need to make sure this will work - if a specification requires a SIP URI, and not any URI, this won't work - the spec says "this is a SIP URI", it's a little more complicated than you're making this * Henning - root of discussion is that we have two models of inheritance, one being the schema, the other being a conference definition - as long as the schema isn't restrictive, this should be OK. If we inherit the whole document, we probably need to update the corresponding specification * Adam - we will reuse and extend as necessary, modulo technical showstoppers why this won't work Conference Package Entensions Orit Levin (20 minutes) draft-levin-xcon-conference-package-ext-00.txt * "This is the discussion starter" * Objectives - "how?", "what info?", and exposing the main objects to external schemas * Expect at the end of the day we will merge this draft with Oscar's draft * The draft is about the XML issues when we extend packages * Schemas leave room for extensions using namespaces * Extensibility requirements: IETF can extend any schema, vendors can extend, multiple namespaces in one XML document, resultant document must adhere to valid schema, must be backward-compatible * Brian - why do we want to extend an existing object in our fundamental specification? What do we gain? Why are we starting here? Everyone who implements this object will write new code anyway * Orit - if we do this, rest of presentation and discussion will still be valid, but - we would like to support clients that have already been deployed * Adam - is Brian suggesting everything is new schemas? * Brian - issue of namespace vs. format used in that namespace. If a client implements a multiple packages, they can all be in one namespace (as long as we agree on naming conventions). Nobody has used our extension mechanism in the objects we've defined. XML has recently solved the versioning problem - this argument doesn't hold. * Naive approach results in invalid XML - example shows what happens when you insert another optional element. XML has a known extensibility issue. Different applications solve the problem in different ways. * Jari - Nobody should use this tool - it produces non-deterministic schemas. This is about stupid tools, not XML. * Cullen - other working groups have had this debate, and absorbed 12 months - can we take their direction and short-circuit this? * Orit - solutions are specific to payloads. Would like to find something we can reuse. * Cullen - how about just using whatever answer the rest of the SIP working groups used? * Henning - experience on design team was that only viable way is to avoid anything fancy - have new namespaces for new things, everything else was complicated. Most of us are not XML experts. Anything that requires XML expertise isn't going to work in the real world * Orit - do you get a new namespace for every extension? * Henning - a new "sub-namespace", and this is based on a label convention, not on XML, which doesn't support "sub-namespaces". * Orit - how does this work with vendor extensions? Is this a different namespace, too? * Henning - if I extend an RFC, I have a namespace and a schema for the extension. You subscribe to event packages, not namespaces. * Solution is to include extensions outside of sequences. This gives us valid schemas. It works for both standard and vendor extensions, even in the same schema * Limitation is that extensions order must be known and predefined in the .xsd. All proprietary extensions must follow all standardized extensions. Vendor extensions must have an agreed-upon order if they are supported in a single product * Henning - this is creative. I'm completely lost as to what this adds beyond having namespaces - gives you the same advantages and none of the limitations. What is the justification for this? I missed it. * Orit - cannot compare the two approaches at this time * Henning - can we have the conversation offline? * What to add to the basic package - and why... * Conference state that will be destributed to subscribers * Using the conference package for more than events only... * Want to expose the main objects without prefixing each internal element * Add state, media, endpoint, user-roles, user to schema and make them easily accessible without prefixes in XML documents - justification is saving bits on the wire for every element of the document? * Cullen - kind of like this, but could we solve the problem another way - do we have to add user? (<<<<<<< sorry, I didn't get this part >>>>>) * Orit - there are issues to take into consideration, but you could do this as an option Role Definitions for Common Conferencing Dave Morgan (15 minutes) draft-morgan-xcon-roles-00.txt * Lots of people are defining roles as part of something else - want to factor this out * Adminstrator, creator, moderator, participant, observer * Separate document or part of another draft? * Should "presenter" be a role or a state? * Brian - worry about interaction with policy if roles and state of a participant are kind of fuzzy - need to have participant policy separate from roles and states of roles * Dave - have given this thought, don't have an answer * Cullen - (at least we don't have TWO answers) - can you hold more than one role at a time? * Dave - yes, but probably goes in a separate document * Cullen - what about Administrator and Participant (for example)? Roles can change? * Dave - that's fine, we have this today and want to accommodate this * Cullen - policy for both roles and individual users? I like this * Henning - there are several ways to look at this. Assign policy to roles? This would simplify things (atomic operations, etc.). Hybrid creates opportunities for confusion. Actually think hierarchy does matter. Need to know how changes happen (participant to observer OK, reverse is not) Administrator can create conferences - need to define what operations go with what roles, and how transitions happen * Keith - is there potential for interactions when you have multiple roles? * Dave - we can handle the administrator issue, but need to think more about details * Roni - not sure I agree with Cullen about inheritance - may have overlay of featuree. Administrator is a global role, not per-conference role * Andrew - do administrators need to join conferences? Dave thinks so. * Andrew - Is a presenter a state? * Dave - depends on the template. * Cullen - open issues are hierarchical/independent, using roles for group permissions. If we go down that path, we probably need to be able to create new roles easily. * Henning - New roles doesn't require new permissions unless permissions are really fine-grained. To the extent possible - it's confusing to have too many bits to set, please limit complexity by limiting number of roles. Do see division between creator and observer, for example - this is about who can inject media, etc. Moderator question - can I become a moderator, and am I a moderator now - these are two different things (if you have two moderators, for example). Same question about presentors. * Dave - this is about passing tokens, or the mixing algorithm (can both speak, but not at the same time) * Orit - want to support Henning's approach and we should define privileges per role. * Dave - needed to define roles before we could define privileges (chicken, egg) MSRP Centralized Conferencing Chris Boulton (10 minutes) draft-boulton-xcon-msrp-conferencing-02.txt * Draft written to prove a point ... * Most current discussion on voice and video, but framework has generic topics - need to prove that this works. MSRP has matured as a standard, IM matters, and MSRP isn't voice or video, so they went crazy * MSRP is peer-to-peer, so XCON server acts as endpoint * MSRP Send goes to XCON server, which then distributes it to all MSRP sessions * Covers Conference and Conference User (with MSRP), text sidebars, private messages * Doesn't touch MSRP protocol, only applies framework principles * Not a priority for the working group, but the authors will keep working on the draft People and Content Video Streams Roni Even (10 minutes) draft-even-xcon-pnc-00.txt * Providing H.239 principles to SIP with multiple video streams. Draft defines conference server behavior * Stream semantics based on content attribute from MMUSIC-SDP-MEDIA-CONTENT draft * Floor control based on BFCP * Want to advance this as a BCP, so it can be referenced in H.239 * Orit - if someone uses MMUSIC definitions for point-to-point... * Roni - this is included in the draft * Orit - if this is about SIP, shouldn't it go to the SIP working group? Why do we need to replicate this work in IETF? * Roni - Allison said to bring the draft here, since it includes multipoint (and also based on workload in SIP working group)