Subject: [Simple] comments on draft-schulzrinne-simple-composition policy

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 Jul 2006 18:59:25 -0400

* On the topic of overlap with presence-processing-model, I think there 
is overlap principally between section 4.2.2 of presence processing 
model (which specifies concepts for composition) and this document. The 
specification of an actual composition format is clearly not overlapping 
with presence processing model. If we do decide to move forward with 
both documents, I'd suggest combining the high level concepts from 
simple-composiiton-policy into presence-processing-model, and then 
composition-policy would specify detailed mechanisms and the policy format.

* Clearly a big question is whether composition policy is per-watcher or 
not. This document assumes its not, and presence-processing-model 
assumes it can be.

* the document assumes that the sources of presence composition are all 
presence documents. But, if you look at other sip event packages, almost 
every one of them are useful sources of presence data, on which 
derivation would be a useful operation. I think the model needs to 
support derivation of presence from non-presence XML sources

* scope is another huge question here (we had similar issues with RPID). 
Do we know what we really need to specify in terms of composition 
policies at this time? It would be good to have some requirements from 
actual deployments

* another big question we need to ask is whether we really expect 
composition policies to be pluggable like this, or whether they are 
simply a set of hard-coded functions built into a presence server. In 
the latter case, we don't need to specify a language per se; guidance on 
the types of things that might be done would be more appropriate

Some minor comments:

* section 2 enumerates different types of presence data. However, it
wasn't clear to me that this particular taxonomy was either exhaustive
or the right set. For example, where in this taxonomy would information
from an IP PBX on whether the user is in a call be?

>  Composition involves adding or removing information from a set of
>    sources, and this may be done at a tuple or element granularity.
>    Some of the steps operate at one granularity or another.  While any
>    of the operations may be done on any tuple type, some operations may
>    be more likely performed on certain types.  This information is

nit: the table talks about <person>, <device> and <tuple>. These are not 
types of tuples. I thin the paragraph about should say "on any data 
component". Data component is defined in the presence data model.

Generally this problem happens in many places. Sometimes the document 
uses tuple to mean one of <tuple>, <device> or <person> and sometimes it 
means just <tuple>.

* the document claims that you can't have conflicts for service or 
device information, but it really wasnt clear why this is true

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Ron Shacham <[email-masked]>
Date: Mon, 10 Jul 2006 13:12:00 -0400 (EDT)

Jonathan,
Thanks for your helpful comments.  Please see responses inline.

Regards,
Ron

On Sun, 9 Jul 2006, Jonathan Rosenberg wrote:

> * On the topic of overlap with presence-processing-model, I think there is 
> overlap principally between section 4.2.2 of presence processing model (which 
> specifies concepts for composition) and this document. The specification of 
> an actual composition format is clearly not overlapping with presence 
> processing model. If we do decide to move forward with both documents, I'd 
> suggest combining the high level concepts from simple-composiiton-policy into 
> presence-processing-model, and then composition-policy would specify detailed 
> mechanisms and the policy format.
>
> * Clearly a big question is whether composition policy is per-watcher or not. 
> This document assumes its not, and presence-processing-model assumes it can 
> be.

>From the processing-model draft, it appears that this is limited to a case 
like "polite block".  We agree that in such a case, there would be a 
special policy, although in general different composition policies do not 
seem useful.  Are you thinking of other use cases?

We haven't specified a specific way to do polite blocking; maybe this 
doesn't have to be done through "composition", but rather a separate document
that is shown to the polite blocked watchers, since the view is probably 
static anyway (eg. a single service whose basic status is closed)

> every one of them are useful sources of presence data, on which derivation 
> would be a useful operation. I think the model needs to support derivation of 
> presence from non-presence XML sources

This is a good suggestion.  You discuss 'dialog-info' and 'reg' in the 
draft.  I think that maybe 'message-summary' and 'conference' could have 
useful applications as well.  Would the conversion of other notification
data to presence data be more appropriately handled by the server, without the 
user specifying it?  Once the data is represented as presence, it 
is easier for the composition policy document to reference and 
manipulate it.

In general, we need to clarify what will be done through "hard-coding" as 
you mention, and what should be specified by the user in an XML 
composition policy document.

>
> * scope is another huge question here (we had similar issues with RPID). Do 
> we know what we really need to specify in terms of composition policies at 
> this time? It would be good to have some requirements from actual deployments
>
> * another big question we need to ask is whether we really expect composition 
> policies to be pluggable like this, or whether they are simply a set of 
> hard-coded functions built into a presence server. In the latter case, we 
> don't need to specify a language per se; guidance on the types of things that 
> might be done would be more appropriate
>
>
>
> Some minor comments:
>
>

Okay, we have been using bad terminology, and we'll fix that.

>
> Generally this problem happens in many places. Sometimes the document uses 
> tuple to mean one of <tuple>, <device> or <person> and sometimes it means 
> just <tuple>.
>
> * the document claims that you can't have conflicts for service or device 
> information, but it really wasnt clear why this is true

In general, we consider multiple service instances to be different 
representations of the same service, so they do not conflict.  The 
example in your draft of overriding service info by publishing another 
service with the same service URI clearly doesn't assume this.  Would 
overriding work by using the same instance ID?  Are there other examples 
where services (or devices) conflict?