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: Paul Kyzivat <[email-masked]>
Date: Tue, 04 May 2004 09:02:18 -0400

Jonathan Rosenberg wrote:

[snip]

> be computed with an OR operation (i.e., open as long as any are open).

I'm not ready to comment on the whole thing yet. But I want to comment 
on this part.

I am concerned about creating a presence composition mechanism that 
effectively *requires* the PS to be able to construct a synthetic 
contact address.

This really raises the bar for a PS, because it potentially puts it in 
the loop for all sip traffic - effectivly causing it to implement the 
same type of decision logic that a proxy has.

I can see that for certain kinds of integrated systems this would be a 
reasonable thing to do. But it could be quite a pain for other kinds of 
PS that simply layer on other independent sip components.

Maybe it is a worthwhile tradeoff to set the bar that high, but we 
should think hard about it before making that kind of decision.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 May 2004 09:02:18 -0400

[snip]

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 May 2004 23:34:31 -0400

Paul,

I think this is good input. In another note, I have proposed what you 
are arguing for - making this behavior purely an implementation choice.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 May 2004 23:34:31 -0400

Paul,

Thanks,
Jonathan R.