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

---

From: Alex Audu <[email-masked]>
Date: Thu, 20 May 2004 10:22:37 -0500

Complexity is certainly a thing to avoid as much as possible.  I am 
still trying to digest the
implications of both models. But  assuming I'd like to serve different 
parts of the document
(tuples) to different watchers based on my preference settings,.. which 
model  maps better?

Regards,
Alex.

Jonathan Rosenberg wrote:

> 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).
>
> combine the actions across tuples, using the normal combining rules, 
> but just for the actions. An alternative would be to drop the actions 
> 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.
>
> you find all of the permissions that match the subscription. You 
> combine those permissions using the defined additivity rules, and then 
> apply the result.
>
> 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 
> 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.
>
> 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 
> 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.
>

---

From: Alex Audu <[email-masked]>
Date: Thu, 20 May 2004 10:22:37 -0500

Regards,
Alex.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 May 2004 14:27:07 -0400

You can send different tuples to different watchers in both models.

In model B, we are going to have a show-tuple transformation which 
allows you to provide tuples to watchers based on class and the contact 
URI scheme only.

In model A, you would define additional condition statements which allow 
you to determine whether a permission applies to a tuple, and then the 
transformations would grant access to all or some elements in the tuple. 
  The lack of any permissions applicable to the tuple for a watcher 
would mean that the tuple is not given to the watcher.

So, for example, if my presence doc looks like this:

<?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          entity="pres:[email-masked]">
        <tuple id="sg89ae">
          <status>
            <basic>open</basic>
          </status>
          <contact priority="0.8">tel:+09012345678</contact>
        </tuple>
        <tuple id="ajjj8a">
          <status>
            <basic>closed</basic>
          <status>
          <contact>mailto:[email-masked]</contact>
        </tuple>
      </presence>

in model A, to give out only the tel tuple to someone:

<?xml version="1.0" encoding="UTF-8"?>
    <cr:ruleset
     xmlns:cr="urn:ietf:params:xml:ns:common-policy"
     xmlns:rpid="urn:ietf:params:xml:ns:rpid"
     xmlns="urn:ietf:params:xml:ns:pres-rules"
     xmlns:cr="urn:ietf:params:xml:ns:common-policy"
     xmlns:rs="urn:ietf:params:xml:ns:pidf:status:rpid-status"
     xmlns:ts="urn:ietf:params:xml:ns:pidf:rpid-tuple"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <cr:rule id="1">
      <cr:conditions>
       <cr:identity>
        <cr:uri>[email-masked]</cr:uri>
       </cr:identity>
       <uri-scheme>tel</uri-scheme>
      </cr:conditions>
      <cr:actions>
       <tuple-handling>give-tuple</tuple-handling>
      </cr:actions>
     </cr:rule>
    </cr:ruleset>

and in model B:

<?xml version="1.0" encoding="UTF-8"?>
    <cr:ruleset
     xmlns:cr="urn:ietf:params:xml:ns:common-policy"
     xmlns:rpid="urn:ietf:params:xml:ns:rpid"
     xmlns="urn:ietf:params:xml:ns:pres-rules"
     xmlns:cr="urn:ietf:params:xml:ns:common-policy"
     xmlns:rs="urn:ietf:params:xml:ns:pidf:status:rpid-status"
     xmlns:ts="urn:ietf:params:xml:ns:pidf:rpid-tuple"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <cr:rule id="1">
      <cr:conditions>
       <cr:identity>
        <cr:uri>[email-masked]</cr:uri>
       </cr:identity>
      </cr:conditions>
      <cr:actions>
       <sub-handling>allow</sub-handling>
      </cr:actions>
      <cr:transformations>
       <provide-tuples>
        <scheme>tel</scheme>
       </provide-tuples>
      </cr:transformations>
     </cr:rule>
    </cr:ruleset>

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 May 2004 14:27:07 -0400

and in model B:

Thanks,
Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Fri, 21 May 2004 15:24:52 +0300

Hi,

I think model B is better. I get nervous with the way model A makes use 
of tuples in the conditions. I think this is where the line between 
composition and authorization gets crossed. I don't think conditions is 
the correct place for this sort of thing.

I think the working assumption that presence information is already well 
formed, providing the needed hooks (class, place-type, etc.) and 
structure for transformations to make use of, when it hits the 
authorization process is the correct assumption to make. I agree that we 
can always deal with composition at a later time.

Cheers,
AKi

---

From: Aki Niemi <[email-masked]>
Date: Fri, 21 May 2004 15:24:52 +0300

Hi,

Cheers,
AKi

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 May 2004 14:33:22 -0400

> tuple states (for example, the value of sphere). Thus, we end up with a 

This is part of the confusion of the current (under-specified) model. 
There are really two sets of conditions that can influence rule behavior:

- The set of elements in one or more tuples.

- The "state" of the presentity itself, as some global abstraction.

The two are obviously related, but with a thinning privacy model, the 
presentity state may not be explicitly coded at the time rules are 
applied, so they may not always be the same. In addition, to keep things 
manageable, a presentity can only be in one state at one time. (Once you 
allow a presentity to be multi-valued, things get messy. This is a 
separate discussion, which we started earlier.)

My general requirement is that it should be possible to repeatedly apply 
privacy rules in our "food chain". This is practically useful, e.g., if 
corporate policy and personal preferences need to be accommodated. A 
corporate policy may prohibit the delivery of certain information, even 
if the employee is willing to share it.

Thus, we need to be very careful in stating what variables we're using 
as conditions.

> buy model A, I think you'd probably want to do that.

Indeed, I consider them to be largely orthogonal issues. The decision as 
to whether matching happens for the document or the tuple should not be 
affected by the action issue.

> those permissions using the defined additivity rules, and then apply the 

The permissions apply when a notification is to be made, not at 
subscription time, since the presentity state may change after the 
subscription.

> desired privacy-safe operation.

To add to this: in my model, there is a separate step that computes the 
state of the presentity. This is orthogonal to the rule processing and 
should be considered separately. As the default model, a merging that 
declares contradiction => no value, seems simplest. There is no reason, 
however, that we couldn't later decide that a different model is more 
effective. This doesn't affect the rule processing, except that the 
state of the presentity has to have a single value for each relevant 
condition (location, sphere, activity, etc.)

This is typically based on tuples published, but this is not logically 
required. The state is certainly not directly related to the current 
input into the "left" of the rule machine, for the reasons I mentioned 
above.

I don't think the division into models A and B is quite right. Since 
this note is already too long, let me try in a separate message.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 May 2004 14:33:22 -0400

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 May 2004 14:54:18 -0400

Let me try to summarize the overall model and see if we can agree on 
these assumptions:

(1) The inclusion of elements depends on the state of the presentity 
(see last message), the watcher identity and the time of day. The state 
of the presentity has one value for each dimension. Almost by 
definition, the URI scheme (mailto, sip, etc.) can't be part of the 
state of the presentity.

(2) The SUBSCRIBE response depends on the watcher identity. It might 
depend on other factors, but since those are subject to change during 
the subscription, this seems unnecessary. (For example, it's rather 
strange to say, for example, that a one-hour subscription can be made 
between 9-5, so that a subscription covering 4.58 pm to 5.58 pm is ok 
even though it covers a no-subscription period, but one made two minutes 
later is not.)

(3) It is sufficient to add elements to all tuples, rather than just 
individual tuples. Jonathan called this 'Model B', but that's really 
just a part of the problem.

(4) We need to be able to select tuples by class. Otherwise, the 'class' 
identifier becomes pointless.

(5) Unclear: we may need to select tuples by contact URI type. This is 
not an element removal; once I remove the contact URI in the tuple, I 
probably want to ditch the whole tuple.

(6) Unclear: we may need to select tuples by presentity type ("include 
only service tuples"). Again, this is most readily viewed as whole-tuple 
selection.

Before getting to solutions, are these reasonable requirements? Do we 
need to support (5) and (6)?

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 May 2004 14:54:18 -0400

Henning