Subject: RE: [Sipping] Conferencing Framework open issue: scope of data wh ich is manipulated by CPCP

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 1 May 2003 09:33:04 -0400

Generally I agree that state and policy are separate.
OTOH, I think the vast majority of implementations will have
them in the same implementation.  I think the design should
allow the possibility of the functions being split, but
be optimized when they are the same entity.  That means they
should have nearly 100% overlap on representation of data
and protocol machinery.  

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 11:24 PM
> To: sipping
> Subject: [Sipping] Conferencing Framework open issue: scope of data
> which is manipulated by CPCP
> 
> 
> Eric raised an issue in his comments on conf-fw, to which I replied:
> 
> >> Also, w.r.t. section 5.8.2, I would really hope that CPCP is SIP:
> >> I'm really hesitant to have to implement all the same protocol
> >> actions with two different protocols "just because."  Let's pick
> >> one and run with it.
> > 
> > 
> > See above discussion on why these are just not the same. In the case
> > of conference participants, you will basically learn them as the
> > result of a full-state update generated by a subscription to the
> > conference state.  CPCP, being a data transaction protocol, would
> > also allow you to directly query for the list. Just because there is
> > this sliver of overlap does not mean that they are the same 
> protocol.
> > 
> 
> My response is wrong. In the current design, you cannot use CPCP to 
> access any of the focus state, such as the current 
> participant list. It 
> is strictly viewed as a protocol for manipulated the 
> conference POLICY.
> 
> This leads to the question - is this sensible? On one hand, one would 
> expect that a protocol for accessing state of the conference 
> should give 
> you access to ALL of the state, not just the subset which is 
> defined as 
> policy. On the other hand, as Eric points out, conference policy and 
> conference state are very different. Indeed, they may likely 
> reside in 
> entirely different servers in the network. One can imagine using an 
> external DB to hold the policy, whereas focus state is in-memory 
> soft-state. Thus, using the same protocol to access them may be 
> complicated to support.
> 
> What do people think about this issue?
> 
> Thanks,
> Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Scientist                             Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP