Subject: RE: [Simple] Presence Rules Issue 3: Specifying views

From: [email-masked]
Date: Mon, 10 May 2004 11:02:37 +0300

If we go for model I where the composition happens before the authorization rules are executed, then I believe we need to give specifics on what to do when 2 or more tuples end up being "the same" (whatever that means). 

There is an alternative, however: Since I believe that the document that defines the composition rules for tuples needs also to define what "the same" tuple means and how the composition is done for those "same tuples". Then in the presence rules document, you mention only that after the authorization rules have been applied, further aggregation may need to happen, and reference the document that defines composition.

How does that sound?

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 10.May.2004 07:01
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] Presence Rules Issue 3: Specifying views
> 
> 
> Hisham,
> 
> You raise good points; there is definitely complexity in 
> decided what to 
> merge. In another note, I had proposed just punting this problem, 
> mentioning only that such aggregation may need to happen, and 
> not saying 
> anything on how. Would that address your concerns, or do you think we 
> need to give specifics?
> 
> Thanks,
> Jonathan R.
> 
> [email-masked] wrote:
> 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>ext Jonathan Rosenberg
> >>Sent: 04.May.2004 11:55
> >>To: Simple WG
> >>Subject: [Simple] Presence Rules Issue 3: Specifying views
> >>
> >>
> >>In the previous version of the draft, there was a permission that
> >>allowed the presentity to say something about the view 
> created by the
> >>presence server - presentity view, service view, watcher view. There
> >>were a bunch of problems with this. One of them was that 
> there really
> >>isnt a strict privacy ordering amongst these choices. 
> Second was that
> >>the meaning of constructing these views is still sufficiently
> >>ill-defined that it was hard to figure out what it might mean.
> >>
> >>Indeed, there's a reasonable question about whether it even 
> >>makes sense
> >>to include directions on how composition is done as part of the
> >>auhtorization policies. It depends on the model that the system is
> >>operating under. In one model, the presence server collects presence
> >>data from various sources, composes it together, and creates an
> >>uber-presence doc that has everything in it. Once that is 
> done, *then*
> >>the authorization policy is applied, reducing information 
> sent to any
> >>particular watcher. Call this model I.
> >>
> >>In another model, however, the authorization policies themselves
> >>effectively guide the composition process, and instruct the presence
> >>server how to create the presence document from the raw 
> data for each
> >>particular watcher. Call this model II.
> >>
> >>In model I, its clear that it would be out of scope for the
> >>authorization documents to say anything about how the 
> >>presence document
> >>is composed. Perhaps some other xcap document could define 
> >>that, but it
> >>would be presence-rules, and its unlikely that such a 
> policy statement
> >>would fit under the scope of common-policy. In model II, its 
> >>not so; one
> >>could argue that you can always represent, in some way, 
> composition as
> >>an algorithm that can operate with increasing levels of 
> data presented
> >>to watchers, and therefore could be controlled within the 
> >>context of our
> >>privacy framework.
> >>
> >>I'm inclined to go for model I, and if others agree, 
> >>explicitly describe
> >>that in the document.
> >>
> >>Assuming this is the case, we still have some issues. Lets say the
> >>presence server computes a document with two tuples, both 
> specifying a
> >>phone. One specifies a work phone, the other, a home phone. 
> For both,
> >>the presence server generates the uber-document with only the basic
> >>status and the <placetype> rpid element. If the user sets the
> >>authorization policy such that placetype is not provided, the 
> >>resulting
> >>presence document makes little sense; it would present two 
> tuples that
> >>don't give any context about *why* there are two - that 
> >>context has been
> >>removed by the presence authorization policies.
> >>
> >>As a result, I think it makes sense to further specify 
> that, after the
> >>authorization policies are applied, the presence server looks at the
> >>remaining tuples. If it turns out that two tuples no longer 
> differ in
> >>any way except basic or contact URI (assuming the same scheme), that
> >>they be merged together into a single tuple by the presence server
> >>before distribution. 
> > 
> > 
> > Basic has 2 values: open and closed. so if it turns out 
> that two tuples no longer differ in any way except basic, the 
> the tuple with closed basic status is removed.
> > 
> > 
> >>This might require the presence server to place a
> >>different contact into the merged tuple.
> > 
> > 
> > I think if the tuples differ in contact URI, then they 
> should not be merged since the contact URI does give context 
> why there are 2 tuples. Tuples with the came contact URI (and 
> the same everything else except basic) are merged (or as I 
> said earlier, the tuple with basic value of closed is removed).
> > 
> > 
> >>The merged basic status would
> >>be computed with an OR operation (i.e., open as long as any 
> are open).
> >>
> >>That's kind of neat, since it does allow for some amount of 
> >>control over
> >>views. If you don't want to reveal inforamtion about your various
> >>devices to a watcher, then tell the presence server to remove the
> >>contact type and the prescaps information which would be needed to
> >>specify exactly that to the watcher.
> >>
> >>ANother nice artifact of this is that, if you don't specify any
> >>permissions except allow/deny for the overall subscription, the 
> >>resulting presence document would
> >>always end up having no more than one tuple for any 
> particular contact
> >>URI scheme. If you had a way to specify that only tuples with 
> >>particular
> >>URI schemes were to be included in a document, that would give the
> >>presentity the ability to, virtually independently of the 
> composition
> >>process used by the presence server, cause the server to spit 
> >>out a bare
> >>bones presence doc.
> > 
> > 
> > is sip:[email-masked] the same as 
> sip:[email-masked]? Why don't these 2 URIs define 
> any context why there are 2 tuples? Clearly one RUI points to 
> one device and the other points to the second device.
> > 
> > 
> >>So, this got me thinking further. The combination of tuples 
> when they
> >>don't differ, as I propose above, might be more 
> controllable. We could
> >>specify permissions that indicate that, if two tuples differ 
> >>by presence
> >>attribute X, then the presence server still do the merging 
> operation,
> >>but it combines the differing values in some way that would 
> be defined
> >>on an attribute-by-attribute basis, possibly including 
> >>dropping of that
> >>attribute.
> >>
> >>In other words, rather than try to specify composition in 
> >>terms of types 
> >>of views, it effectively gets specified by defining which presence 
> >>attributes get combined together, and which don't.
> > 
> > 
> > This sounds complicated. Do we want the authorisation 
> policy to define how the composition is done? or do we not? 
> if not, then we should avoid it at any level. I prefer to 
> leave composition issues out of this.
> > 
> > 
> >>So, some specific questions to ask the group:
> >>
> >>(1) do you think we should be following model I or model II 
> >>[I vote for I]
> > 
> > 
> > I vote I also. I never thought of II as an option.
> > 
> > 
> >>(2) should we add a permission that grants access to tuples 
> based on 
> >>contact URI scheme [I vote for yes]
> > 
> > 
> > Yes.
> > 
> > 
> >>(3) should we specify that, if authorization policies remove 
> >>data which 
> >>results in two tuples being the same, they be combined [I 
> >>vote for yes]
> > 
> > 
> > Yes, but we need to discuss what "the same" means.
> > 
> > 
> >>(4) should we define additional permissions that specify 
> that certain 
> >>presence attributes should be aggregated together in a 
> >>tuple-combining 
> >>process [not sure]
> > 
> > 
> > See above.
> > 
> > Thanks,
> > Hisham
> > 
> > 
> >>Thanks,
> >>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
> >>
> > 
> > 
> 
> -- 
> 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: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 May 2004 08:30:31 -0400

[email-masked] wrote:

> If we go for model I where the composition happens before the
> authorization rules are executed, then I believe we need to give
> specifics on what to do when 2 or more tuples end up being "the same"
> (whatever that means).
> 
> There is an alternative, however: Since I believe that the document
> that defines the composition rules for tuples needs also to define
> what "the same" tuple means and how the composition is done for those
> "same tuples". Then in the presence rules document, you mention only
> that after the authorization rules have been applied, further
> aggregation may need to happen, and reference the document that
> defines composition.
> 
> How does that sound?

Very similar to the model that I mentioned a few days ago. I don't think 
we need to specify composition now. Also, it seems likely that the 
merging step may well occur after subscriber filtering, as this could 
also result in two tuples being the same.

I do think it would be helpful to have a general "data flow model" for 
presence information, where information is inserted on the left by 
PUBLISH or REGISTER and leaves the pipe on the right via NOTIFY.

> Regards, Hisham

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 May 2004 08:30:31 -0400