Tuesday, March  8 at 1645-1745
===============================

CHAIRS: Alan Johnston <alan.johnston@mci.com>
        Adam Roach <adam@nostrum.com>

SCRIBE: Spencer Dawkins <spencer@mcsr-labs.org>

AGENDA:

TUESDAY, March 8, 2005
----------------------
1645-1745 Afternoon Sessions III

1645-1650 Agenda Bash

• No agenda bashing took place
  

1650-1700 WG Status various
Chairs 15 min

• Need authors! Not all of our work items have authors.
  
• Need more mailing list discussion
• Do we still care enough about this work to continue?
• Conference Scenarios WGLC starts as soon as document reissued
• Notification Event is deliverable, but not yet started - once framework is reasonable, this work should start - but SIPPING is already working in the area now - we're designing in piecemeal and it's not working, we're going to be stuck with what comes out of SIPPING conference package, and this is an unfortunate fact of life. WG can consider multiple models.
• Floor control requirements document going to IESG with protocol specification. Some authentication concerns about SHA-1.
• Conference state manipulation mechanism still under discussion. CCCP and CSCP are active proposals, will revive and reissue requirements document.
  

1700-1745 Framework draft-barnes-xcon-framework-02.txt
Mary Barnes 45 min

• This is second total rewrite, so if you haven't read this document lately, please do so
• Remains protocol agnostic
  
• Simplified terminology, defined "focus", added new terms and removed unused terms, used Conferencing System instead of XCON server, etc.
• Updated Template terminology - this is getting closer, but might still be an issue. Templates are human-readable, clients can query them
• For each conference type, we might have two types of templates, one semantic and the other syntactic, could we mention this in the framework?
• Simplified data model - policy is part of the Conference Object - Common Conference Information plus Conference Template, supports each instance of a conference
  
• Where are policies for maniputlation? In the document we're manipulating?
• Introduced a "Cloning Tree" as model for system realization
• Introduced use of iCal for scheduling
• Added background to set context - no duplication of SIPPING conferencing framework
• SIP used only as example protocol
• Current version defines baseline terminology
• Model is simplified in 02 version.
  
• Conference Object Type not changed too much from 01 version.
• Cloning Tree - can clone another parent tree, can create children of each parent conference
• Issue 1 - referring to sets of meetings. iCal is required mechanism, used to describe "time". Cloning tree is used to create conference object for reservation.
• Is it necessary to be able to identify "all future occurances" of a conference? Should be supportable if so.
• Conference time is iCal time, all other times are deltas from iCal time? When does dialout happen, when does mixing happen, etc. We've never come up with a conference start time that worked - modern systems make URIs valid immediately and forever.
• "Start time" is the time the user reserved for the conference to start.
• Need to distinguish between conferences that repeat - need to take this into account when we're doing delta times. Time for series, time for conference, then delta times. Many delta times may be set at the root of the tree anyway (mixing always starts 10 minutes early).
• One time that has a timezone, for any occurance of a conference.
• What will iCal actually send us as a time? Will it be useable without modifications?
• We cycled CPL for two years trying to use a subset of iCal - is this a bad idea? iCal has more interoperability than anything we'll design here.
• iCal will give us user-visible time - T0 needs to be the most natural thing a user will refer to.
• Issue 2 - Groups of RTP streams for floor control - do we need this? Stream name specific to a role? Mailing list indicates that we don't;.
• Issue 3 - Querying templates - discussed getting template descriptions without coming to consensus or closure. Will clients be able to interact with templates they don't understand based on variable descriptions? This is our server, not IANA's server.
• Will this be an XML schema or a "blueprint" per current framework? One is a schema, the other is an object. Have to get values from a blueprint, not from a schema.
• What about the non-constant portion? Difficult to add values to a schema.
• We like blueprints, but schemas would also be useful - not sufficient
• Needs to be some mechanism for communication between frameworks and schemas
• Can we punt on these details pending other discussions on actual data representations?
• If you don't have a schema, you need it when you join the conference.
• We agreed on this in the room
• Clients will query any templates they don't understand and then make a decision on compatibility? We agreed on this, too.
• Should we include User Interface "hints"? We proposed "yes", but don't even know if the device has a screen, a display, etc... Not display description language, not postscript ... how you choose to represent this based on hints is up to you. We'll do this until we have more experience working through examples.
• Issue 4 - XML Schema Structure - Is template at the top level? Common conference information? Template and common conference information as two separate objects? Editors prefer Common conference information at top level.
  
• What does "navigate" mean? Do all templates contain common conference information? How do you find the common state?
• XML extension is always ugly - prefer two separate objects.
• Need more research and discussion on the list - we could revisit at Thursday meeting if we talk fast.
• Issue 5 - State and Policy Manipulation Protocols - Syntactic? Semantic with explicit operations? Both?
• We wanted a single protocol, but might be able to combine both approaches.
• Proposal is for Semantic operations - protocols proposed include CPCP, CCCP, CSCP, Netconf.
• It's a little early to analyze pros and cons - can we declare this as something we'll revisit when we're smarter?
• Why do we need a single protocol if we have two separate things we want to do? This can be nice, but is a second priority.
• Issues from WG Review:
• Section 4.1 is confusing - reword to point to section 5 (which helps the reader understand).
• Some text is definitely wrong (cardinalities don't match)
• Include floors in Figure 2.
• Section 4.5 - data access rights seems very much like common conference rules - didn't rules go away? Terms are causing more confusion than we're curing. Just be clearer and more explicit. General rules still FFS/out of scope
• Bootstrapping problem with data access rights? No, these are separated out now.
• Document is still inconsistent about whether CPCP is really gone, etc. This will be carried as an open issue - need further discussion, still unclear.
• Section 6.4 - needs additional work - what's in there now is trying to align with BFCP and this isn't helping.
• Section 6.4.1 and Section 7.1 are also issues.
• Adopt this draft as WG item? humming was unanimously "yes"