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

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 
> [I vote for I]

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.

> (2) should we add a permission that grants access to tuples based on 
> 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). 

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

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. 

> (4) should we define additional permissions that specify that certain 
> presence attributes should be aggregated together in a 
> tuple-combining 
> process [not sure]

My answer is same as for point (3).

Markus

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 May 2004 04:13:17 -0400

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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 May 2004 04:13:17 -0400

+---------+
   |Presence |
   | Source  |\

      +-----------+
      |           |
      | Final     |
      | Presence  |
      | Document  |
      |           |
      |           |
      +-----------+

Comments?

Thanks,
Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Wed, 19 May 2004 14:13:05 +0300

Very nice indeed. I like it.

I think leaving out rate-limiting from this data flow diagram is the 
right thing to do. In fact, I don't think it has any bearing on this 
data flow, as I think it is part of the notification process and not the 
  policy-applying process.

Cheers,
Aki

ext Jonathan Rosenberg wrote:
>>> (1) do you think we should be following model I or model II [I vote 
>>> for I]
>>
>>
>>
>> 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).
>>
>>> (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]
>>
>>
>>
>> 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.
>>
>>> tuple-combining process [not sure]
>>
>>
>>
>>> Indeed, there's a reasonable question about whether it even makes sense
>>> authorization documents to say anything about how the presence document
>>> is composed. Perhaps some other xcap document could define that, but it
>>> would fit under the scope of common-policy. In model II, its not so; one
>>> 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.
>>>
>>> authorization policy such that placetype is not provided, the resulting
>>> don't give any context about *why* there are two - that context has been
>>> That's kind of neat, since it does allow for some amount of control over
>>> URI scheme. If you had a way to specify that only tuples with particular
>>> process used by the presence server, cause the server to spit out a bare
>>> bones presence doc.
>>>
>>> specify permissions that indicate that, if two tuples differ by presence
>>> 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.
>>>
>>> (1) do you think we should be following model I or model II [I vote 
>>> for I]
>>> (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]
>>> tuple-combining process [not sure]
>>>
>>> Thanks,
>>> Jonathan R.
>>>
>>>
>>>
>>>
>>> --