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

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 01 Dec 2005 23:10:34 -0500

From a practical perspective, you can indeed get a SUBSCRIBE to tickle 
a NOTIFY with the current state, but that seems far harder to program 
than a synchronous "query" mechanism. Thus, while this does duplicate 
mechanisms in a strict sense, the purpose and application is 
sufficiently different that this seems less harmful than the alternative.

I would also argue that trying to develop an XCON-specific 
publish/subscribe/notify mechanism seems of dubious utility unless 
existing mechanisms are clearly incapable of handling the chore. One of 
the nicer aspects of re-using the event mechanism is that a lot of the 
tools, such as the privacy rules, can probably be drafted into service 
fairly easily. That way, we don't have to develop new XML to restrict 
who can get notified of conference events.

Oscar Novo (JO/LMF) wrote:
> 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
> 

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