RE: [XCON] Call for Consensus and Discussion: Data Model

["Brian Rosen" <[e-mail]>]

As one who frequently opposes more than one way to do the same thing, I'd
like to explore this subject a little.

I hope we indeed do have consensus that there is an object, and the object
represents the state of the conference.  I don't hear anyone disputing that.

We are discussing a protocol that directly manipulates this object.  I hope
that doing something like altering the mixing policy is done by the
protocol, and that's the only way to do it.

I do think we all agree that we need mechanisms for asynchronous
notification of various kinds of conference events, and an event package is
the way to do that if SIP is the protocol you are using to contact the
conference server.  I would not want our new conference control protocol to
have its own asynchronous event notification mechanism.

That leaves a gray area.  The current conference package provides a way to
"read" the current conference state.  Another way to do that is to use the
conference control package to read the object.  This leads to the design
decision of what is the way to determine the state of the conference: tickle
the asynchronous event package to send you the conference object and look at
it, or read it using the conference control package?

After giving this some thought, my conclusion is that the conference package
as it is presently constituted should just remain as it is.  Any actual new
asynchronous events we need should be defined in a new package that would
only be implemented by endpoints that needed it and reading the conference
object should be accomplished with the protocol.

Let's take a specific example: what is the current state of my master volume
control?  Since I set it with the conference control protocol, if I want to
get its current value, I think I should use the protocol to get it.

On the other hand, if I want to know when Mary is in a sidebar (so that I
could, for example, make the fact that she is probably not paying attention
to the main conference visible by some kind of indicator on my screen), then
I probably want an event package that gives me a way to find that out.  It
may well be that the event notification includes all or part of the
conference object, so I do get some state with the event.  That's okay, and
I think it's a "part of the object", not the whole thing.  

I think that event is part of a new package, and is not part of, or an
extension to, the current package.  I think the entire object is too big to
be sent on every event, and I don't want a simple endpoint to have to deal
with all manner of new events we may decide we need.  The way I see it, if
you implement the control protocol, you probably will implement the event
package that goes with it.  Templates may define new state, and thus
possibly new events.  It's another design decision on how to implement a new
event: define a new package with just the new events, define a new package
which includes the events associated with the "common" part, or have an
extension mechanism for an event package.  I think the latter is a bad idea.
As one who sees the template as including the common part, I'd probably be
consistent and have a template defined package include any common events.

Brian



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Even, Roni
Sent: Tuesday, November 29, 2005 1:54 AM
To: XCON-IETF
Subject: RE: [XCON] Call for Consensus and Discussion: Data Model


As the one who made comments about the usage of the
sipping-conferencing-package, I would like to clarify my comments.

The XCON conferencing framework draft in section 5 "In a system based on
this conferencing framework, the same conference object type is used for
representation of a conference during different stages of a conference,
such as expressing conferencing system capabilities, reserving
conferencing resources or reflecting the state of ongoing conferences.".


On the other hand the event package represents just the state of on
going conference. The event package does not address the conference
capabilities for example can the conference be extended, what is the
mixing policy, can non specified users join the conference or is the
conference access allowed only to users pre-defined by the creator. 
This is why I am not sure that the conference-info by itself or the
extension suggested by Orit will be enough since the event package
should just conveying the current state.

Roni Even

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Adam Roach
Sent: Thursday, November 17, 2005 2:32 AM
To: XCON-IETF
Subject: [XCON] Call for Consensus and Discussion: Data Model

[as chair]

In Vancouver, there was considerable discussion around the XCON data
model. There seemed to be considerable consensus around the position
that we would use the XML schema defined in
draft-ietf-sipping-conference-package-12 as the basis for the data model
used in XCON.

There was also a sentiment expressed that this schema needs additional
elements added so that it can express all the information relevant to
the data model we are defining in XCON. 
draft-novo-xcon-common-data-model-00 purports to be a starting point for
defining such additional elements.

This message is intended to (a) verify the consensus to use the
conference event package as a starting point, and (b) spur discussion
around what additional data items are necessary to make it complete for
XCON's purposes.

/a

_______________________________________________
XCON mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/xcon



_______________________________________________
XCON mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/xcon