Subject: Re: [Sipping] Conference Package and Conferencing Framework

From: "Arjun Roychowdhury" <[email-masked]>
Date: Thu, 7 Nov 2002 13:55:49 -0500

Hisham,
my perspectives  inline, prefixed <ARC>

Firstly let me say something about Basic and complex participants.
There might be participants that are not allowed to subscribe to 
conference policy info nor are they allowed to subscribe to media policy 
info. Similarly, some participants don't want to know either. Others are 
allowed to see one and not the other. Yet all want and must be able to 
subscribe to the participant list for that conference (some participants 
might just want to know who else is in this conference, nothing else).

So, we need 2 things:

1. a participant that is between a basic and a complex one.

<ARC>

My reading of the framework doc. was a 'basic' participant was one whose 
UA does not need
any special features to be in the conference and is technically unaware he 
is in a conference. A complex one would be 'conference aware' and would 
therefore support the required extensions to avail of more features. To 
me, this is a clean differentiation.
Now, within a complex participant, whether you can/not access various 
policies is well, a policy matter.
I dont know whether it makes sense to try and define each such set 
explicitly. 
</ARC>

2. break conference package into 4: conference (the same as before), 
conference.participant, conference.confpolicy, and conference.mediapolicy.

Participants can subscribe to any combination.

<ARC> 
I don't think the drafts published have reached this level of detail yet, 
but nothing
that I read did not indicate that these look like elements that are not 
allowed. I would expect
future drafts would address these in more detail.
</ARC>

This give much more flexibility for participants to choose to see that 
info. It also gives flexibility on who can or cannot see certain info 
about a conference. The question is:  Where is such policy stored? Is it 
part of the conference policy include who can see its instance?
Secondly, Moderator needs to be defined. Is a moderator always a complex 
participant? is the converse true? are they the same thing? 
How can one become a moderator? Is moderator info (who is moderator and 
what can they do) part of the conference policy? If so, does that mean all 
complex participants know who the moderators are?

<ARC> 
Surely, a moderator MUST be a complex participant but not vice versa. What 
makes a complex participant
a moderator is policy and I would guess the 'Conference Policy Protocol' 
would dictate that.

Again, looking at the previous discussions since the drafts have been 
released, there seems 
to be more participation from the readers than the authors themselves ;-) 
which makes me believe
that (hopefully) other drafts are soon to be release that will expand on 
the ambiguities more concretely.

regds
arjun
</ARC>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Nov 2002 14:41:40 -0500

inline.

> I dont know whether it makes sense to try and define each such set 

I agree. Whether or not a user is allowed to subscribe to the conference 
package is a matter of policy, and doesn't require new terminology.

> Participants can subscribe to any combination.

Well, first off, you don't mean conference.<foo>, since the dot notation 
is for templatizing. Nothing here is a template.

What I think you are asking for is four separate packages, each of which 
could be subscribed to independently.

The design team discussed it a little so far. THere are two appraoches - 
  either you put everything into one package, and let users obtain 
subsets through filtering operations in the subscription. Of, users have 
to subscribe to finer grained packages, and no filters are needed.

WHich one is best depends on the common case. If you expect most people 
to want all of the information, having four separate packages is a big 
waste. Its four times the subscribe traffic, since you need to refresh 
each independently.

If you expect most people to want just one or two pieces, separate 
packages are better, since specifying filter information all the time 
would be a big waste.

Its hard to know which is right until we have more use cases flushed 
out, and sample flows, which give us an idea of what kind of 
conferencing features will require which packages.

> part of the conference policy include who can see its instance?

Yes.

> participant?

Not necesarily. They can use the web to do many moderation functions, so 
that their SIP UA is just basic.

> is the converse true? 

Is a complex participant always a moderator? No.

> are they the same thing? 

No. Complex participant describes capabilities of a SIP UA.

Moderator is a policy term. It describes a set of permissions granted to 
a user for controllign the conference through the conference policy 
control and media policy control protocols.

> How can one become a moderator? 

That too, is a matter of policy.

> Is moderator info (who is moderator and 
> what can they do) part of the conference policy? 

Yes.

> If so, does that mean all 

If policy allows participants to know who the moderator is, the 
conference event package will let them know.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[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