Subject: [Simple] On Class

From: Sharath Chandra <[email-masked]>
Date: Tue, 1 Feb 2005 18:00:20 +0530

How does existing Presence data model address the following issues ?

1) Unique identity for a user across the domains and networks. For a
presence document to be complete it may need to handle alias for a
user within the same network as well as across the domains and
networks. Presence informations multiple application (not sip based
sources) also needs to be handled. Is there a proposed architecture
for such requirement

2) Categorizing the watchers into groups for a presentity to specify
different levels of privacy and trust. Like Family, Friends,
Colleagues etc. I believe once the grouping/class is available i can
have more control on what data i can disclose to which class and i can
make a authorization document using XCAP.

Thanks,
Sharath

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 19 Feb 2005 10:38:59 -0500

Another note I never responded to. Apologies.

Answers inline.

> sources) also needs to be handled. Is there a proposed architecture

I'm not sure I entirely I understand your question.

I think you mean the following. A particular user can have multiple 
identities in many domains - sip:[email-masked], yim:jdrosen, 
sip:[email-masked], and so on. Some of these may not even be SIP 
domains (like the Yahoo IM one). In that case, how do we create a 
consolidated view of my presence?

This is a very complex question; something folks often refer to as 
presence federation. I think it is a topic worthy of consideration in 
the presence processing model draft, as it ultimately is about how a 
compositor collects information from different sources; in this case, 
the source is a presence server in another domain. There are several 
ways to do that in SIMPLE. Rather than write a long extended note on 
this topic, I'll put some initial text in the next revision of the 
procssing model document.

> make a authorization document using XCAP.

There were capabilities for this in previous versions of the draft. The 
idea was that a new type of condition was whether an identity was on a 
resource list specified elsewhere in the xcap root. You could then 
define lists for friends, co-workers, etc, and key authorization rules 
off of it.

We purposefully reduced the scope of the presence auth rules to bare 
minimum, and this particular feature was dropped. The expectation is 
that we could address it downstream via a separate specification that 
added this new type of condition.

Another way to do this kind of thing is trait-based authorization, which 
eliminates the need for maintenance of lists of users. For example, if a 
SUBSCRIBE showed up and the domain it came from asserted that the 
subscriber was in the marketing department of some company, I could 
define authorization rules that applied to any users with that trait (in 
the marketing department of some company).

WOrk on trait-based identification is ongoing in sipping/sip:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-authz-01.txt
http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-02.txt

this work is still relatively early but I think is very promising. Once 
it matures, the time will be ripe for defining presence rules conditions 
that can take advantage of the traits placed into a SUBSCRIBE request.

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