[XCON] CPCP Issue 31: Expelling a User
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.