Subject: [XCON] Control protocol: synchronous "query" mechanism vs asynchronous "query" mechanism

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Thu, 29 Dec 2005 14:31:50 +0100

Some weeks ago we submit the CSCP proposal draft. This proposal has a mechanism to query the capabilities of the system using a synchronous "query" mechanism.  
Some time ago we discussed if developing a synchronous "query" mechanism to query the capabilities of the system is a dubious utility or we should use insteed an asynchronous "query" mechanism, the SIPPING notification package (see message below). Still, we haven´t reached a conclusion in this thread and it is still open. If we can agree the way forward, the authors of CSCP can changes the text in the next version to accomodate what we agree. 

Still, I think we need a "asynchronous query" mechanism to query the state of the conference and a "synchronous query" mechanism to query the capabilities of the system. I don´t mean we should develop a completely new XCON-specific mechanism for the "asynchronous query". We can use the SIPPING notification package. With the implementation of an "asynchronous query" mechanism in the conference control protocol, the administrator can query the capabilities of the system when s/he wants and the system doesn´t need to send periodically this information to this users, saving bandwith and avoiding a bottleneck at signalling level since the capabilities of the system usually change quickly.

And being truth that asynchronous query mechanism is harder to implement than the synchronous one (thank you Henning to clarify me this question), I think the difference implementing one mechanism or other is very small, for instance, in both mechanisms you have to deal with any errors. 

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: 2. joulukuuta 2005 6:11
To: Oscar Novo (JO/LMF)
Cc: [email-masked]; Even, Roni; XCON-IETF
Subject: Re: [XCON] Call for Consensus and Discussion: Data Model

 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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 29 Dec 2005 09:22:35 -0500

Oscar

I am confused.

If you explicitly send a query, and get a response relatively immediately,
then that is synchronous.  To explicitly query the state of the conference,
you use a synchronous query.

An asynchronous mechanism is used when you don't know when something
"interesting" happens.  In this context, "interesting" is some kind of
change of state of the conference.  You use an asynchronous query to find
out that some state changed shortly after it changes, without an explicit
query.

We don't need to use SIPPING events to tell us the state of the conference.
We need it to tell us when some kinds of state change.  

To find out the state, I would want to just read some or all of the object.
CSCP would have to provide a way to do that.  You send some kind of request,
and you get some kind of response relatively immediately.  I imagine the
request identifies what part of the object you want returned, and the
response has that part of the object.

I believe the issue is: how do you specify what "part of the object" means?
You could make it simple: you have one query == return the entire object.
I suspect you want something more complex that that, so you can ask "who are
the holders of all of the floors right now?"

Brian

-----Original Message-----
From: Oscar Novo (JO/LMF) [mailto:[email-masked]] 
Sent: Thursday, December 29, 2005 8:32 AM
To: Henning Schulzrinne
Cc: [email-masked]; XCON-IETF
Subject: Control protocol: synchronous "query" mechanism vs asynchronous
"query" mechanism

Some weeks ago we submit the CSCP proposal draft. This proposal has a
mechanism to query the capabilities of the system using a synchronous
"query" mechanism.  
Some time ago we discussed if developing a synchronous "query" mechanism to
query the capabilities of the system is a dubious utility or we should use
insteed an asynchronous "query" mechanism, the SIPPING notification package
(see message below). Still, we haven´t reached a conclusion in this thread
and it is still open. If we can agree the way forward, the authors of CSCP
can changes the text in the next version to accomodate what we agree. 

Still, I think we need a "asynchronous query" mechanism to query the state
of the conference and a "synchronous query" mechanism to query the
capabilities of the system. I don´t mean we should develop a completely new
XCON-specific mechanism for the "asynchronous query". We can use the SIPPING
notification package. With the implementation of an "asynchronous query"
mechanism in the conference control protocol, the administrator can query
the capabilities of the system when s/he wants and the system doesn´t need
to send periodically this information to this users, saving bandwith and
avoiding a bottleneck at signalling level since the capabilities of the
system usually change quickly.

And being truth that asynchronous query mechanism is harder to implement
than the synchronous one (thank you Henning to clarify me this question), I
think the difference implementing one mechanism or other is very small, for
instance, in both mechanisms you have to deal with any errors. 

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: 2. joulukuuta 2005 6:11
To: Oscar Novo (JO/LMF)
Cc: [email-masked]; Even, Roni; XCON-IETF
Subject: Re: [XCON] Call for Consensus and Discussion: Data Model

 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.