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

From: Adam Roach <[email-masked]>
Date: Wed, 16 Nov 2005 18:32:28 -0600

[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
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: "Oscar Novo (JO/LMF)" <[email-masked]>
Date: Thu, 17 Nov 2005 10:29:31 +0100

Thanks Adam for your help. 
I think it's good idea to start discussing in the mailing list the
elements we need to define in the Data Model. I agree the Data Model
draft is too SIP-dependent and should have additional items but, as is
written in the document, this first version only try based on the SIP
event package to collect the data model information introduce for other
draft (it does NOT define new elements) that's why is too SIP-dependent.
This is one thing we should change in the next version of the draft.
There are more open issues that we should discuss as well. All your
comments are welcome.

Oscar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Adam Roach
Sent: 17. marraskuuta 2005 2:32
To: XCON-IETF
Subject: [XCON] Call for Consensus and Discussion: Data Model

[as chair]

/a

---

From: "Oscar Novo (JO/LMF)" <[email-masked]>
Date: Tue, 29 Nov 2005 16:10:32 +0100

Completely Agree with Brian.

The current conference event package represents just the state of the
conference. So, the system notify me the state of the conference using
the event notification package every time there is an important change
in the state of the conference (new user join the system...). 
Note that the "SIP Event Package for Conference State" already includes
the posibility to send a "part of the conference object" state (Section
4.4 Partial Notifications Mechanism). 

The conference control protocol we choose should have a mechanism to
query the capabilities of the system (mixing policy, can non specified
users join the conference or is the conference access allowed only to
users pre-defined by the creator and so on).

Oscar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Rosen
Sent: 29. marraskuuta 2005 15:09
To: 'Even, Roni'; 'XCON-IETF'
Subject: RE: [XCON] Call for Consensus and Discussion: Data Model

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: [email-masked] [mailto:[email-masked]] 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: [email-masked] [mailto:[email-masked]] 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]

/a