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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 May 2004 04:55:28 -0400

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. This might require the presence server to place a
different contact into the merged tuple. 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.

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.

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]
(2) should we add a permission that grants access to tuples based on 
contact URI scheme [I vote for 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]
(4) should we define additional permissions that specify that certain 
presence attributes should be aggregated together in a tuple-combining 
process [not sure]

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

---

From: [email-masked]
Date: Fri, 7 May 2004 13:48:31 +0300

> -----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
> 
> 
> 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

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.

> 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.

> (1) do you think we should be following model I or model II 

I vote I also. I never thought of II as an option.

> contact URI scheme [I vote for yes]

Yes.

> results in two tuples being the same, they be combined [I 

Yes, but we need to discuss what "the same" means.

> presence attributes should be aggregated together in a 

See above.

Thanks,
Hisham

---

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

> 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:
> 
> > 
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>ext Jonathan Rosenberg
> >>Sent: 04.May.2004 11:55
> >>To: Simple WG
> > 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.
> > 
> > 
> > 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).
> > 
> > 
> > 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.
> > 
> > 
> > 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.
> > 
> >

---

From: [email-masked]
Date: Wed, 12 May 2004 23:58:47 +0300

Hi,

> (1) do you think we should be following model I or model II 

Model I is better. However, as pointed out in another mail, the composition rules actually probably need to be applied at three stages: 1. for the "raw" data, 2. after authorization, 3. after watcher-defined filtering.

> contact URI scheme [I vote for yes]

Definitely yes. This way I could for instace govern access to tuples about my MMS or SMS status (provided that the related URI schemes get registered). 

> results in two tuples being the same, they be combined [I 

Somehow this sounds like a composition policy, or rather the composition policy tells by which criteria the tuples actually are the "same", i.e. does the contact URI matter or not. So I think I'm saying no; this is beyond the scope of authorization policies. 

> presence attributes should be aggregated together in a 

My answer is same as for point (3).

Markus

> Sent: 04 May, 2004 11:55

---

From: [email-masked]
Date: Mon, 17 May 2004 14:59:29 +0300

This looks great. That's how I viewed it. I wonder though if the composition policy should also be applied before the watcher filter.

Regards,
Hisham

> Sent: 17.May.2004 11:13
> To: Isomaki Markus (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> I think there's been some convergence here. Let me restate 
> what I think 
> we have.
> 
> (1) We think we're currently specifying the document format 
> that applies 
> polciies toa  document after composition (model I)
> 
> (2) there may be composition required after such policies are 
> applied, 
> however, how thats done is outside the scope of presence-auth.
> 
> (3) there is a model representing the data flow of policy 
> processing we 
> should write down.
> 
> (4) it would be a good idea to have a permission that allows you to 
> grant access to a tuple by its URI scheme
> 
> 
> Here is a picture for (3), which is an ascii art version of a diagram 
> Henning sent me:
> 
>            Please view in a fixed-width font such as Courier.
> 
> 
> 
>    +---------+
>    |Presence |
>    | Source  |\
>    +---------+ \                   +-----------+
>                 \                  |           |
>                  \   /------\      | Raw       |    //------\\
>    +---------+    \// Create \\    | Presence  |  || Privacy  ||-----+
>    |Presence |----|   View     |-->| Document  |->|| Filtering||     |
>    | Source  |     \\        //    |           |    \\------//       |
>    +---------+    /  \------/      |           |                     |
>                  /      ^          +-----------+       ^             |
>                 /       |                              |             |
>    +---------+ /    +------------+                 +------------+    |
>    |Presence |/     | Composition|                 | Presence   |    |
>    | Source  |      | Policy     |                 | Auth       |    |
>    +---------+      | (TBD)      |                 |            |    |
>                     |            |                 |            |    |
>            +--------|            |                 |            |    |
>            |        +------------+                 +------------+    |
>            |                                                         |
>            V                                                         V
>         ------          +-----------+                      
> +-----------+
>     ////      \\\\      |           |       ------         |  
>          |
>    |  Post        |     | Filtered  |    ///      \\\      | 
> Candidate |
>   |   Processing   |<---| Presence  |<--|   Watcher  |     | 
> Presence  |
>    |  Composition |     | Document  |   |   Filter   | <---| 
> Document  |
>     \\\\      ////      |           |    \\\      ///      |  
>          |
>         ------          |           |       ------         |  
>          |
>           |             +-----------+                      
> +-----------+
>           |
>           |
>           |
>           |
>           V
> 
>       +-----------+
>       |           |
>       | Final     |
>       | Presence  |
>       | Document  |
>       |           |
>       |           |
>       +-----------+
> 
> 
> I've left out rate limiting from this.
> 
> Its important to note that, in each stage of the pipeline, the 
> information content in the document can only be reduced, never 
> increased. As long as that's true, we can introduce new stages in the 
> pipe with their own rules, without violating privacy safety.
> 
> 
> Comments?
> 
> Thanks,
> Jonathan R.
> 
> [email-masked] wrote:
> 
> > Hi,
> > 
> > 
> > Model I is better. However, as pointed out in another mail, 
> the composition rules actually probably need to be applied at 
> three stages: 1. for the "raw" data, 2. after authorization, 
> 3. after watcher-defined filtering.
> > 
> > 
> > Definitely yes. This way I could for instace govern access 
> to tuples about my MMS or SMS status (provided that the 
> related URI schemes get registered). 
> > 
> > 
> > Somehow this sounds like a composition policy, or rather 
> the composition policy tells by which criteria the tuples 
> actually are the "same", i.e. does the contact URI matter or 
> not. So I think I'm saying no; this is beyond the scope of 
> authorization policies. 
> > 
> >