RE: [XCON] CPCP Issue 31: Expelling a User

["Noa Kissilov" <NoaK at radvision.com>]

Hi,

As I see it this problem is derived from the problem that authorization
RULES shouldn't be used to take actions on participants. A RULE is
something referred to when you consider a certain behaviour. Action,
such as having a server do something, should have a different mechanism
to be set. This is only one aspect of another question, which is the
essence of the conference policy document - is it a state descriptor
(like described about sidebars: if no sidebar element appears in
conference policy, it means there are no sidebars currently in the
conference, and vice versa), policy definition (like rules - someone
asks to do something, we check it with the policy and then decide upon
our behavior), or a mechanism to fire actions? I believe currently there
is a mixture between the 3, and this causes some inconsistency and
confusion. For example, for expelling a user we need to both change
policy (so that this user will not be allowed in the conference) and say
somehow to disconnect it now. These are 2 distinct tasks, and I believe
they should have 2 distinct mechanisms.

Another question about this subject: why is it required to have "block"
value for actions? In the common policy it is stated specifically that
rules only permit. Why is "block" required anyway, especially when it is
with the lowest value of 0 and will be overridden upon any other value
apearance (in other rules)? It is stated that this is the default
anyway. Let's make it simpler...

    noa.


-----Original Message-----
From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf Of
hisham.khartabil at nokia.com
Sent: Monday, September 13, 2004 15:31
To: hisham.khartabil at nokia.com; xcon at ietf.org
Subject: RE: [XCON] CPCP Issue 31: Expelling a User


This is a draft-ietf-xcon-cpcp-00.txt issue now.

I have not received any comments about this and I honestly have no idea
how to simplify this besides creating a new expel list (which I don't
like).

If no one has any better ideas, then I will keep the text as is (no
expel list, but to expel a user, multiple rules may need to be altered).

Regards,
Hisham

> -----Original Message-----
> From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org]On Behalf Of

> ext hisham.khartabil at nokia.com
> Sent: 13.August.2004 16:14
> To: xcon at ietf.org
> Subject: [XCON] CPCP Issue 31: Expelling a User
> 
> 
> This issue was missed during the presentation since the chair
> ;) accidentally put up the old version of the slides.'
> 
> Back to the issue:
> 
> Care must be taken since if one rules allows a user to join and one
> blocks a user from joining, the result in that the user is allowed to 
> join.
>  
> For example, Bob can join a conference since an authorization rule has
> been defined to allow everyone at example.com:
> 
> <rule id="1">
>    		<conditions>
>    			<identity>
>    				<domain>example.com</domain>
>    			</identity>
>    		</conditions>
>    		<actions>
>    			<join-handling>allow</join-handling>
>    		</actions>
>    		<transformations/>
> </rule>
> 
> Setting the following rule will not block Bob from joining nor will it
> expel him since the above rule overrides it:
> 
>   	<rule id="2">
>    		<conditions>
>    			<identity>
>    				<uri>bob at example.com</uri>
>    			</identity>
>    		</conditions>
>    		<actions>
>    			<join-handling>block</join-handling>
>    		</actions>
> 		<transformations/>
>    	</rule>
> 
> So, in order to expel Bob, the original rule has to be modified using
> the <except> element:
> 
>    	<rule id="1">
>    		<conditions>
>    			<identity>
>    				<domain>example.com</domain>
>    				<except>bob at domain.com</except>
>    			</identity>
>    		</conditions>
>    		<actions>
>    			<join-handling>allow</join-handling>
>    		</actions>
>    		<transformations/>
> 	</rule>
> 
> This type of behaviour makes it very hard to a client implementation
> to figure out how to expel a user because it depends on all the rules 
> in a conference. It must go through all the rules and change all the 
> necessary ones so that that user is not capable of joining again.
> 
> Does anyone have ideas on how to simplify this? A separate expel list
> that overrides any rules???
> 
> Regards,
> Hisham
> 
> _______________________________________________
> XCON mailing list
> XCON at ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon
> 

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon


_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon