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"
|