Wednesday, January 5th, 1300 - 1515 Current status of the framework doc: - Total rewrite from -00 version based on IETF 61 discussion. - Terminology and descriptions remain call signaling protocol agnostic. SIP is used only as an example protocol. - Centers on data model (types and objects). - No duplication of content from SIPPING Conferencing Framework. - Current version intended to provide the baseline terminology, model and high level interfaces (including protocols). More work required to describe detailed functionality once basics are agreed. Block diagram available in Mary's Powerpoint slides (http://ee.wustl.edu/~alan/xcon/XCON-FW-Update-Issues-Jan2005-Interim-v3.ppt). Much debate about various arrows, to be resolved "offline". On the topic of templates: Orit summarized the position taken in the framework draft, where a template an object -- one that can be "copied" (instantiated) but not modified. That is, the templates themselves are created at system boot time and subsequently used to instantiate conferences, which may be subsequently modified. Issue: What do we call a conference-specific instance? "State" can be confusing because each of the conference objects has its own "state". A variety of suggestions were lofted -- including "occurrence" -- all with implications that would be incompatible with various resolutions of the ongoing Thing A/B/C debate. Correspondingly, Keith L., et al. opined that we need to resolve the data/object model before deciding on specific labels. This suggestion was more or less accepted, however grudgingly, and much of the remaining discussion focused on the much loved topic of recurring meetings. Cullen, et al.: One of the key "realities" we need to deal with is being able to distinguish between two concurrent/overlapping instances of the same recurring meeting -- e.g. when one occurrence scheduled from 10-11 runs over into a second occurrence scheduled from 11-12. If you want to disallow the 11-12 participants from joining the late running 10-11 occurrence, you can't use the same URI for the second occurrence. But, is this a real concern? If these are really just two occurrences of the same recurring meeting, do we really need to worry about it? It's not the same as allowing two people to assign the same PIN to two entirely different meetings -- one from 10-11 and one from 11-12 -- then allowing participants in one meeting to enter the other. That should not be allowed. This led to a discussion of how to name individual instances (specifically the "current" instance) of a recurring conference and all instances (the series) ... which in turn led (somehow ;-) ) to the hypothesis that we will probably end up with multiple namespaces -- e.g. xcon: or cpcp:, in addition to sip: for foci). At least one consensus emerged from this discussion (!): We need to be able to identify (a) a single occurrence/instance of a recurring meeting and (b) all instances of a recurring meeting. N.B. This is a necessary, but may not be sufficient. That is, it may also be necessary to be able to easily identify (e.g. via a URI) the "next" occurrence or "all FUTURE occurrences" or even "all occurrences between date X and date Y". Providing a URI for the last is particularly problematic, however. Correspondingly, resolution on those extensions to the consensus is TBD. Henning then reintroduced the notion of separating time completely from the conference service. This begs the perennial question, however, as to how one can deliver a usable XCON-enabled conferencing service -- that is, one that supports resource reservation -- if (a) XCON itself doesn't produce anything that deals with time and (b) existing calendaring vendors (e.g. Microsoft and Lotus) don't extend their systems to understand conferencing resources. vCal was offered as one possible way to fill this gap, but there was nothing approximating a consensus answer to the question. --------------------------------------------------------------------------- Wednesday, January 5th, 1530 - 1800 Floor Control -------------- Alan: Requirements & BFCP docs have been revised. WGLC real soon now. Henning: Is BFCP the ONLY solution, or is it one of many possible protocols for the floor control problem? Adam: We probably will not pursue alternatives. Cullen: Gonzalo posted set of open issues on BFCP, around SDP. Those are in a separate MMUSIC document. Alan: Floor control is a separable problem, and users other than XCON can use it. Back to the Framework --------------------- Do we need a different definition of Focus, given the SIPPING definition is a sip: URI? Not really, since SIPPING says *usually* a sip: URI, but actually a "conference" URI. We will look into this tomorrow 1/6. Multimedia Stream definition has not changed. However, everything seems to be in the context of RTP streams, so we don't see multimedia streams, only individual sets of RTP streams. Consensus achieved on removing the term "multimedia stream". However, Roni points out that we do need to address aggregates of streams. Eric calls them "bundles". XCON Server, Systems, or ???: Henning points out that WG names aren't meaningful. Will address and name appropriately later. Schemas & Templates: Can you have limits in the template thing? People think so, but Orit points out that one cannot express that in XML Schema. Roni points out that we're looking at something that looks like H.248 packages... Cullen: just wants to make sure you can easily fill in parameters when it is time to instantiate conference. Is this a hierarchy of types or a collection? What is the document? Brian: it is something you read, like a RFC. It might contain an XML schema, but the important stuff will probably be in English text. What do you get back when you ask the server, "What do you support?" You get back the name of the document (template you registered). Then you can instantiate objects. Henning: why does the client ever need to see XML? Henning: why not just use XForms? Gives us everything we need, like things to fill in, ranges, default values, etc. XCAP model is exactly wrong: everything is a part of an XML document. Henning would rather have each template thing as a protocol element. If you want to change something, you send a new, complete document. Admin Interrupt: let's defer to when we agree on Agree: RFC (document) with text description, with XML Schema. Get a thing that has things to fill in. Client can query for list of templates. IANA registry is a triplet {name, RFC, XML Schema} Figure out later if lots of XML gets transmitted. Disagree: is this something like a user interface or a data interchange format. How is XML extended and nested? Brian: extensions in XML are ugly and hard to do. Therefore, have variable stuff in top-level description. Orit: extensions are easy. Therefore, have template in top-level; simple clients can ignore stuff it does not understand. For extensions: Is it better to have one object inherit from another, or have separate objects? No conclusion - will be taken to the list. Recurring Conferences --------------------- Cullen: Time is this opaque thing the XCON client sends around, like, "I want a recurring conference on Tuesdays at 8am PST." It is up to the calendaring system to figure out time zones, etc. General consensus on the concept of shipping opaque iCal stuff. Roni: Who guarantees resources are reserved? Eric: that's an implementation / business issue. Henning: Make reservation, passing iCal object (with time range), which may be a series. Get back a "handle" (GRUU) that identifies series. Then one can query system to get a URI for referencing a specific instance. With that URI, one then can do conference-specific manipulation, like number of ports, etc. Will not extend, modify, fold, spindle, or mutilate iCal. Allison: be careful not to overstep bounds into iCal or ACAP territory. Discussion on "When the state (or the instance) begins - with the focus creation" statement. Agree, as on the mailing list, that if you can address it with a URI, and someone responds, it "exists". The converse is really a philosophical thing: if you cannot reference conference state (i.e., with a URI), then the state does not exist from a protocol point of view, even if the implementation does allocate resources, create state, etc. Implementers are free to do what they want, but we do not care from a protocol perspective. Cullen will become iCal expert (RFC2445 for those that care) and will tell us how to specify a particular instance / set of selected instances. Policy Rules ------------ Should be able to easily go through CPCP and pull out policy rules. Not really clear, but not good to do without Hisham's and Aki's input. How is a Conference Created? Lost idea of Conference Factory URI. Need it back, i.e., the place to send the conference creation / reservation request. Floor control: Template/document defines what a floor is, what it means to hold it, and what it does, especially with respect to media streams. --------------------------------------------------------------------------- Wednesday, January 5th, 1930 - 2230 Mary presents on .... Discussion about if we do sipping event package work in xcon or not. Moved to framework document. Should there be one document that provides an overall view of what is going on in conferencing. Move so that we have to read two documents. One document that talks about the signaling framework and another (the xcon one) that talks about the xcon part of it. Keith: The sipping and xcon framework documents are peers AD: The sipping framework is not going to have anything about xcon in it. There are a few definitions of things like focus in sipping that are sip specific. xcon might define focus a little differently. XCON might want things like a loosely coupled vs. tightly coupled conference. XCON can say there is notification - but not get into detail about it because XCON is agnostic about signaling. Don't get into details of signaling protocols - assume they have reasonable things. Switch to Henning presenting .... - see his slides - add that a conference state but this can be active or latent - reservation has the connotation that something was reserved - looked at tree model What is the advantage of hierarchy. Provides more inheritance model: such as corporate policy, restrictions provided by device, and time. Question is if this needs to be exposes in the model. Answer is that if you edit an intermediate it has an effect on the children. Q. how do sidebars work? Henning: working on inheritance based idea - still needs work Introduce idea of BUS for a mixer .... Some discussion. Brian things this is probably not going to help too much. seemed to have agreement that .... When a conference is finished, it may go back to latent state before being purged at some later state. Back to Orit.... - see her slides This is about changing the value of things in some object that has a name. Proposal would allow creation of new types of keys. Keith asked about why not xpath? Orit: Implantation complexity 2) can't pre validate the document 3) this one allows keys that logically identify something but not necessarily a xpath expression Henning: 80% of reinventing soap but with not of the benefits of something that exists. Henning example if you are editing "joining behavior" what would happen. Infinite number of error conditions. Can combine multiple requests and can they are atomic. Back to Henning ..... - see his slide on Control Protocol - have get/set/add Brian - need to add list manipulation too Keith ask clarification on "transaction semantics". Henning: want each command to be a single change. Orit want to make the server not the client smart. Orit wants a full RPC approach. Issues is semantic vs syntactic (ie. addUser vs. get/set) not SOAP vs something else Henning, Brian, I, agree - doing the semantic approach breaks any chance of doing user interfaces that client did not know about --------------------------------------------------------------------------- Thursday, January 6th, 0800 - 1000 STATE - Orit presenting 1 slide on CCCP Scope -- highlighting that CCCP works on all levels of conf life-cycle (Occurrence/Reservation/Template) - EB: raises concerns on mapping of CCCP to Henning's model - CJ: also concerned that the slide is going back on yesterday's discussion regarding new approach. - HS: Asked -- what are we going to model for a conference (at what level) - OL: re-iterate that she is presenting how CCCP maps to Henning's model. - AJ: Can CCCP manipulate conference state? - BR: do you need to map a rule to an object? - HS: in his model it inherits it -- unless there is a forced override at a higher level. - BR: Brian states that 'Rules limit exactly what can be done to the object' -- only permitted action is 'Allow'. - HS: reluctant if you need ACL for every variable -- seems excessive - CJ: thought there was one ACL that allowed a user to modify rules. - BR: Agrees with Henning. - HS: ACL to object controls privilege access to whole object hierarchy. Forced global would then control the hierarchy manipulation at the lower levels. - BR: Does not agree -- thinks it is simpler. RULES - AJ: shows the room a slide on 'Rules' -- see separate slide. Emphasizes that we should not invent general rule syntax BUT should reuse common policy. Rule support in XCON will be optional. - BR: does not think that it fits. - CJ: Simple system that does not support rules -- would I be able to limit 'who is allowed to join?' - AJ: No -- simple conf system will not have identity based admissions (apart from at pass code level). - RE: Is policy a rule or a variable? - HS: use variable control through hierarchy and force global inheritance of change unless not required -- - OL: and... if you would then like to allow some people to change it you add a complimentary rule. - BR: Asked question: How to you increase for a particular conference instance e.g. 50 to 100 ports in this model. - HS: You would create another upper layer branch and hook the conference instance to that leaf. - BR: so you would have to create that blob for every participant - HS: add more leaves to the tree to represent the change - BR: Does not agree and believes it should be rule based on the conference object - Various: It's an implementation choice rule based/inheritance based - BR: Advocating rule based mechanism - CJ: Wants clarification on ACL based model. - **CONCENSUS** The room agreed that an ACL per object (not on a per field basis) is required for the ability for manipulation. - OL: Question to Brian -- why are you against having both methods? - BR: Believes that every system implements rules -- not just advanced system. - EB: Loathed to defined the conference service (rules etc) - the IETF does not define service. Just provide the ability/tools to create/provide services. - BR: Implement any kind of limits of what users are allowed to do but the created object reflects the ability of the ranges. Ranges reflect what that user can do and should be accurate -- e.g. number of ports 0-100 for a conference BUT if for one user, the range is 0-50 ports (has been altered from the base) and to the object MUST reflect. - Do we need to standardize ACL? - CJ: Yes BUT the thought is that we do not necessarily need protocol definition. - OL: We need to consolidate data in a single schema -- Asks that if we have everything in an object (no syntax for rules), what would be the format for expressing it as a data object and not a rule? - EB: Confusion -- clarification of difference between policy and state is important (is Cullen in the conference (state) as apposed to is Cullen allowed in the conference (rule)). - **CONSENSUS** -- vote in the room on Henning's Hierarchical inheritance model to see if it is acceptable for progression. It was decided that it was not a sufficient time and not sufficient detail for such a vote at this time. - KD: Before we decide if rules are needed -- we need to define exactly what rules are -- then we can decide if a protocol is needed. - OL: we should not define the syntax for the rules - AR: why is this not just a pivot of common policy - OL: thinks it's different -- can be implemented in many different ways in different implementations. - HS: only one part of common policy as time/location based do not make sense. So it is just a subset. So if we are only using 10%, a simple list model would be easy to explain. E.g. how would sphere make sense? - CJ: This is simply a bunch of lists rather than a table. The properties are not variable and are fixed but they can be extended. Adding a new property is equivalent to setting up a new conference. --------------------------------------------------------------------------- Thursday, January 6th, 1030 - 1200 10:30 - 12:00 XCON framework document Mary presented the XCON framework continuationfrom where we left on wed jan 5) - The slides were modified (XCON framework slides) - Cullen - didnt we remove the Rules ?? - can CPCP manipulate the state? - What are CPCP and CCCP functioanlity ? (Keith D) - CPCP is document editing system and CCCP is semantic based (Alan) - Rules and conference-info needs to be collapsed into one (merge). - We still have 2 protocols - CPCP and CCCP (Alan) - - Do we need 2 protocols CPCP and CCCP - Cullen? - Hening - we need to come with new names for these 2 protocols - we need to agree on what we call this protocols - Mary - Open issue is do we need a data manipulation protocol and semantic protocol - can we elimate CPCP (Cullen) ? - CPCP box has been changed to Data Manipulation in the slides - no consensus yet - Henning proposal - Conference Info is called conference object and a protocol to manipulate conference Object. - There was agreement on what we call the whole conference components - conference objects. Hennings tree nodes will be called conference object. - The type definition of the variable part of the conferece object is conference template. - The type defintion of the fixed part of the conference object is common conference information. - Registered conference Document is the schema which is registered with the IANA. - A new definition of focus - The focus is a call signaling endpoint that is addressed by a unique conference identifier. The focus maintains a call signaling relationship - XCON client will be just called client - Cullens proposal is client. - We dont want to define new data structures for time in XCON. We should use the iCal object to define the notion of time. - XCON wont define any ical extension - ical proposed as the required mechanism - The action point is we have to look more in detail how ical works. - For Policy - use ranges to control limit on values. Use list formats (described in previous minutes) to control membership and permissions. - Add text (in the framework document) in the framework document to discuss how is a conference created. - For floor control the text (in the framework document) should be consistent with the BFCP doc and security mechanism need to be addressed. - Way forward Next revision needs to be out before adopting as working group item.