Subject: RE: [Simple] Presence Rules Issue 4: Rules apply to tuple or to s ubscription

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Thu, 20 May 2004 07:07:06 -0500

I'd go for model B with the suggested simplication for transformation being applied globally and let the selective inclusion of elements in tuples be controlled by the composition-guiding policy.
 
Rgds/gf

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, May 20, 2004 6:16 AM
> To: Simple WG
> Subject: [Simple] Presence Rules Issue 4: Rules apply to tuple or to
> subscription
> 
> 
> 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
> 

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

---

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Thu, 20 May 2004 07:07:06 -0500

Rgds/gf