Subject: [Simple] Presence Rules Issue 4: Rules apply to tuple or to subscription

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 May 2004 06:15:50 -0400

This is an issue that is a spin off from discussions that arose around 
issue 3 (specifying a view). Henning had proposed a different model 
where the rules apply to tuples. I discussed this with him over the 
phone, and now understand what he had in mind sufficiently well to 
describe it here.

So, one model for how things could work (model A) is this. Take the 
current presence document, and break it into tuples. When a subscription 
arrives for a user, for each tuple in that user's document, find the set 
of matching permissions that apply to the tuple. It would be allowed, 
and defined, to have conditions in the permissions that are based on the 
tuple states (for example, the value of sphere). Thus, we end up with a 
set of permissions for each tuple. Apply the transformations defined in 
those permissions to the tuples. Re-compose the document as the union of 
the resulting tuples. You may need to do come downstream cleanup, like 
merging tuples (that can happen in other models too).

A complexity if this model is that, currently, the action specifies 
whether or not to accept the subscription. If this ended up being 
different between different tuples, you'd presumably need to then 
combine the actions across tuples, using the normal combining rules, but 
just for the actions. An alternative would be to drop the actions 
entirely, and have a separate document format that JUST specifies 
whether or not to accept a subscription, reject it, or block it. If you 
buy model A, I think you'd probably want to do that.

Model B is the model I think most of us have been running with. The 
permissions apply to the entire document. When a subscription arrives, 
you find all of the permissions that match the subscription. You combine 
those permissions using the defined additivity rules, and then apply the 
result.

A concern with model B is that, if you wanted transformations to apply 
to tuples selectively (for example, only include a specific RPID element 
in tuples where another RPID element has a specific value), you'd have 
to introduce an additional layer of if() statements within the 
transformations themselves (the condition statements already 
representing a layer of if() statements on applicability of the 
permissions to a subscription). That's what I have in the current 
version of the spec. It is that concern which led to Henning's idea on 
model A.

Another concern with model B is that it makes it hard to have conditions 
based on my current state. For example, we currently have a condition 
called <sphere>. A permission applies to a subscription when my current 
sphere is equal to the specified value. The problem is, what happens if 
two tuples have different values for sphere? The solution Henning and I 
came up with is this - if the applicability of the condition is 
ambiguous in any way, the condition fails. We'd need to define what 
"ambiguous" means. Clearly, if you have multiple tuples with differing 
values for <sphere>, you're current state is ambgious, and none of the 
permissions with a sphere condition would apply. This maintains the 
desired privacy-safe operation.

So, the issue is, which model to choose?

I am strongly in favor of model B. Here's why:

1. I think model A is too complex
2. I think it will be hard for users to understand the model, resulting 
in the possibility of surprising results because permissions are not 
constructed properly.
3. The model differs from most current usages and other protocols, such 
as WV, where permissions apply to subscriptions, not to 
tuple/subscription pairs.
4. It requires us to split out whether or not to accept or reject 
subscriptions. I think there is a fine line between content 
transformations and accepting/rejecting subscriptions, and I'd rather 
not treat them as separate.
5. model A's operation is unclear on how it would work for for content 
outside of a tuple (for example, contacts and some of the rpid elements)
6. the ambiguity problem could still happen in model A, and in any case, 
the proposed solution seems to be good so that this is a non-issue for 
model B IMHO.

As it regards to the concerns about a separate layer of if() statements, 
I'll buy that. I'd propose to keep it simple, and simplify this. Let us 
stick with permissions that don't allow for selective inclusion in 
specific tuples. The transformations apply globally across the document. 
Thus, you could include or not include an rpid element everywhere, but 
could not pick the tuples in which it would appear. If you want to put 
specific rpid elements in specific tuples, it should be controlled by 
the composition-guiding policy which we can define at a later time.

Thoughts?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple