TUESDAY, November 8th, 2005, 0900-1130
======================================
Agenda Bash
Chairs (5 minutes)
* No changes to the agenda for today
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)
XCON (Wednesday 15:10 - 16:10)
==============================
Agenda bash
-----------
1510 - 1520 Protocol Selection Discussion
------------------------------------------
Chairs (10 minutes)
Adam: WG chair introduction to issue. Setting deadlines to the
discussion. Any proposals not covered in terms in protocol need
to be produced by the end of the year. At beginning of next year
volunteers to author a document that does an evaluation of the different
solutions. Goal is to have protocol solution by end of 2006.
Cullen. Like the idea of setting dates. Not keen on an evaluation
yet. Only proposal on table that can manipulate the templates (the
variable part). Other IETF group that did this evaluation went and
selected the worst one. We need to evolve all the solutions to meet the
requirements and then choose the best.
Mary: Need to sort out the most important requirements. Do not think we
will make progress with a protocol evaluation phase.
Rohan: Echo. We do not need to decide to do this. Idea of closing input
is excellent.
Mary: May be best just to pick one solution. Does not matter which.
Jon: This is valid in document by Ted Hardie. If don't know how to make
a decision, then this is as good as anything.
Conclusion: Have discussion on list in January opn best way of moving
forward.
Henning: Be good to have an excutive summary of the particular
approach. Supportors bring this forward.
Rohan: If no conclusion to January discussion, chairs should choose the
approach, and this should be done well berfore Dallas.
All agreed.
1520 - 1530 CCCP
-----------------
Orit Levin (10 minutes)
draft-levin-xcon-cccp-03.txt
Orit presenting: Heavily revised as a result of implementation
experience. A new protocol, as existing protocols do not meet the
requirements. Not data manipulation (like XCAP or WebDav) but rather
object manipulation. Runs on any reliable protocol, but does not rely
on underlying transaction model (unlike SOAP/HTTP).
Henning: Please clarify on request response association.
Orit: In SOAP over HTTP cannot send multiple requests and responses.
Henning: Partially true.
Orit presenting: Transaction client-server protocol. Final response x2
and provisional pending response. Request and response attributes (like
SIP headers). Multiple primitives in a single operation - can signal an
atomic operation. However have decided at the moment not to use this,
instead define a single primitive which combines the meaning of multiple
primitives. Object manipulation approach - object identified by keys
without navigating through the entire XML document. Response codes carry
application semantics. Example of object manipulation primitive. Define
dedicated primitives for operations where at least one of the following
properties are desirable - atomic, applied to set of objects, efficiency.
Example of operation. CCCP and events - does not appear in draft, but
is something from the framework so added to presentation. Notifications
can be sent using operation in CCCP as transport for these rather than
SIP. Next steps: CCCP is open to modification - !
can be taken as basis. If not planning to publish as informational.
Henning: What is motivation to have two event notification mechanisms
(SIP and CCCP) that have to be implemented.
Orit: SUBSCRIBE/NOTIFY not best choice because cannot reuse the transport.
Keith: In follow that argument, then will also add floor control to this,
as that does not reuse same transport.
Cullen: Nothing in framework to need this. Sidebars within main
object. How will do this. How do templates relate to this protocol.
Orit: This protocol can manipulate anything that is defined in
XML. Templates are XML. What is missing from data manipulation protocols
is primitives with semantic content.
Cullen: Understand simplicity, but need extensible way of adding to
"move sidebar" to an existing client.
Orit: Different clients with different requirements. Sidebars in
templates draft are met by placeholders. A single CCCP operation can
modify this value.
Henning: One of differentiating feature mentioned is ability to have
provisional responses. What in current set of operations has this been
found to be useful? Also atomicity feature where it is not used. Should
not design protocols with unused features.
Discussion Henning / Orit seemed to agree on removing features that were
not used.
Orit: Provision responses. Establish call to third party that takes time.
Henning: Preference for fewest number of mechanisms. In SIP would get
rid of provisional responses and have event notification. Likewise here.
Adam: Agree with Cullen that it makes more sense now. If someone were
to design a template variable to change the pitch of a speakers voice
how would one use CCCP to do it?
Orit: Depends on how template defined, but Modify template element
(element name, element new value).
Cullen: Are we going down parth of two protocols, One part to manipulate
the dynamic part and one the static part?
Orit: Not two protocols.
1530 - 1545 Media Templates
----------------------------
Chris Boulton (15 minutes)
draft-boulton-xcon-media-template-02.txt
Chris presenting: XCON framework defines conference object which is
common conference information and template. Subject of draft is the
template. Described what a template is. Described blueprint is an XML
file based on .xsd.
Brian: Thought we all agreed that blueprint was object with the initial
set of values in it.
Mary: In current version of framework, blueprint is common conference
information along with the template.
Brian: But the initial values come from the blueprint. Clone values from
the blueprint.
Adam: talking past each other?
Henning: If do Brian's approach have overlap with the cloning
operation. This is a framework issue. Unless we get this straight will
have way too much complexity.
Cullen: All know what we want but get confused on terminology. Should
delegate to Mary to enforce a common terminology on all participants.
All agreed.
Chris presenting: Document overview. Open issues. Functionality boundaries
of templates. Single namespace versus namespace per template - discussed
yesterday but no conclusion.
Cullen: Should pick same solution as chosen for SIMPLE.
Chris presenting: Open issues. Also need to align with Cullen's
draft. Need to cover wider range of templates. Input required from
WG. Is this a working group item.
Adam (chair): More input from group before we make that decision.
Cullen: All issues that are open are issues that can be solved in a
WG document.
Adam (chair): not yet sufficent discussion on the list.
1545 - 1610 Protocol Selection Open Discussion
-----------------------------------------------
Chairs (25 minutes)
None.
|