Subject: [Simple] Draft on optimized presence federation

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Nov 2007 10:10:28 -0500

I've just submitted an I-D that defines a SIP event framework extension 
called "view sharing". View sharing optimizes the performance of 
subscriptions inter-domain and is meant as an answer to the scaling 
analysis and requirements drafts we've been working on. The basic idea 
is, if there are ten watchers that are interested in the same presentity 
and will get the same presence document, have just one subscription 
rather than ten.

Here is a pointer to the draft:
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-view-sharing-00.txt

-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: <[email-masked]>
Date: Wed, 14 Nov 2007 16:38:42 +0200

Hi,

This draft addresses an important problem, assuming we want to support
SIMPLE based presence between large domains. I think it is also
important to address the problem with minimum affect to the UAs, as this
draft does. The key question seems to be whether we want to allow a
domain to decide how much it wants to reveal on the policies of its
users' policies to a particular other domain. If we set that as a
requirement, I think building upon the ideas proposed in this draft is
the way to go.   

I have one specific question:

Have you considered whether the ACL format can effectively cope with
"domain" and "exception" logic in common policy? For instance the common
policy RFC has a following example rule:

       <rule id="f3g44r1">
           <conditions>
               <identity>
                   <many domain="example.com">
                       <except id="sip:[email-masked]"/>
                       <except id="sip:[email-masked]"/>
                   </many>
               </identity>
           </conditions>
           <actions/>
           <transformations/>
       </rule>

In this kind of case (assuming no other rules) the presence server would
know that everyone else from example.com would get a certain view, while
alice and bob would be blocked. Is this readily supported in ACL doc by
listing two rules there? (BTW, instead of calling the ACL elements
rules, how about calling them e.g. views to avoid confusion with common
policy terminology?) 

Markus

>-----Original Message-----
>From: ext Jonathan Rosenberg [mailto:[email-masked]] 
>Sent: 12 November, 2007 17:10
>To: Simple WG
>Subject: [Simple] Draft on optimized presence federation
>
>I've just submitted an I-D that defines a SIP event framework 
>extension called "view sharing". View sharing optimizes the 
>performance of subscriptions inter-domain and is meant as an 
>answer to the scaling analysis and requirements drafts we've 
>been working on. The basic idea is, if there are ten watchers 
>that are interested in the same presentity and will get the 
>same presence document, have just one subscription rather than ten.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Nov 2007 14:15:55 -0500

Thanks for your comments. Responses below:

> requirement, I think building upon the ideas proposed in this draft is

If you buy into the idea of some kind of optimization like this, I think 
you absolutely need to build in controls that allow a domain to decide 
on the performance/privacy tradeoff.

> rules, how about calling them e.g. views to avoid confusion with common

I believe so. The ACL document would look like:

<rule id="1">
   <member>sip:[email-masked]</member>
</rule>
<rule id="2">
   <member>sip:[email-masked]</member>
</rule>
<rule id="3">
   <other/>
</rule>

this would tell the originating domain to do a subscribe for alice and 
bob individually (since there are no rules defined for their presence, 
so each needs to have a subscription extended), and then a rule for 
everyone else.

-Jonathan R.