Subject: [Simple] Presence data model: overriding

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Oct 2004 22:13:19 -0400

We had a lot of discussion on overriding. To summarize, the issue is how 
one PUA can explicitly overried the services, devices or persons set by 
another PUA. The data model currently prescribes that the element doing 
the overriding publish a service or device with the same ID as the one 
to be overriden, and that in the absence of other policy, the compositor 
take the most recent service or device for a particular ID.

If you don't know what the default is, or the default doesn't achieve 
this goal, you would have to set an explicit policy that selects your 
desired service/device over the other one, presumably with xcap.

Markus has asked for a more explicit way to ask for overriding within 
the presence document itself. Ultimately, I think his concern was that, 
without standards for composition policies, the user won't know what the 
server will do and the user has to have control.

I argued, and continue to argue, that including information about how 
composition should be driven, within the presence dcouments itself, is 
wrong. The presence documents need to have meaning as standalone 
documents, and the information they convey is presence, nothing more. If 
you start to put override commands into these documents, you may run 
into conflicts between these commands and explicitly specified 
composition policies that we will define downstream. You don't want two 
ways to do the same thing.

Thus, I think we can address Markus' problem by being more forceful, and 
defining a baseline composition (and authorization) policy at SHOULD 
strength, adding caveats that changing these can result in unexpected 
behavior, but recognizing that the provider themself is a valid source 
of policies and you cannot preclude them from providing input.

The default policy would be that, for devices and services, if their ID 
is unique, they are included in the raw document. If their ID conflicts 
with another one, we look further. If its a service, and the IDs are 
AORs (assuming the compositor knows this), the services are combined by 
a merging operation. Otherwise, for devices, or for services with the 
same ID, but not an AOR, the compositor selects the most recently 
published service. For person information, the person data are merged 
together, such that if an attribute appears in more than one <person> 
and the values are the same, that attribute appears in the merged 
document with that value. If they are different, the attribute value 
from the most recently published <person> is used

This makes it clear how to override someone elses service or device or 
specific attribute of <person> if this default composition policy is 
implemented.

Separating this from the question of whether or not we can report 
conflicting inforamtion, do folks agree that mandating a baseline 
composition policy in this way addresses the issue?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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: Alex Audu <[email-masked]>
Date: Thu, 21 Oct 2004 10:51:14 -0500

I think conveying how compositor should handle conflicting presence
documents
is a policy issue.  In the absence of a comprehensive compositor policy,  it
will be
best to come up with  a default  or baseline compositor policy.  What you
have
proposed will probably do.

Regards,
Alex.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 31 Oct 2004 22:20:21 -0500

> composition policy in this way addresses the issue?

I would argue that there are two equally valid composition policies:

(1) "Bold" or Latest wins (the above); the "black-and-white" view of the 
world - it's either right or wrong, but no need to expose ambiguities to 
the world (you could call this the Bush policy :-))

(2) "Cautious" or No information loss; the composer makes sure that 
there is no information loss to the watcher and defers decisions to the 
watcher. Information from multiple sources is kept separate. (You could 
call this the Kerry policy.)

I'm really worried about enshrining one policy as the default one, 
particularly one that forces information loss.