Subject: [Simple] Determination of <sphere> in presence authorization

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Feb 2005 13:37:22 -0500

One of the issues I have raised in the past about the presence
authorization work was how to determine the value of the <sphere>
condition. This interacts substantially with the data modeling work, and
composition in particular. The difficulty, if you'll recall, was that 
the value of <sphere> itself depends on composition and authorization 
policies. Furthermore, if we allow documents with multiple person 
elements (as there appears to be consensus to allow), the value is 
ambiguous. Yet, we need that value to be computed in order to determine 
if an authorization policy matches in the first place.

The current version of the document suggests that the value is computed 
based on the default composition policy. We have two problems with that:

1. we are pushing out the composition policy work based on Robert's 
proposal, so the default will be ill defined for some time

2. the presence document can have multiple values of person

I would suggest the following solution to this conundrum.

Along the lines of Robert's general proposal, we should punt this 
problem. I'd like to state that the authorization spec does not define 
how to arrive at a single value of <sphere>, and that it be a matter of 
local implementation and policy, and that we expect future 
standardization work to provide further guidance on this topic.

In the short term, real world deployments where we aren't likely to see 
multiple elements publishing <spheres>, or we won't see complex 
authorization policies that restrict who gets to see <sphere>, there 
isn't really a problem. The presence doc has a single value for sphere 
and their is no ambiguity. As we see more complex systems getting used, 
we can address this via the composition work.

Is this workable?

Thanks,
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: Henning Schulzrinne <[email-masked]>
Date: Thu, 17 Feb 2005 21:07:46 -0500

Agreed.

In reality, this gets even messier since one could easily imagine 
systems that set <sphere> through some out-of-band, non-PUBLISH means 
(e.g., a web page or some time-based logic).

While it would be nice if different systems arrived at the same sphere 
value given the same inputs, this seems like a minor consistency issue 
in practice. It doesn't affect interoperability; there are any number of 
places (e.g., even in basic call routing and forking) where we don't 
specify exactly what should happen under all possible circumstances and 
inputs.

Henning