Subject: RE: [Simple] collection template

From: [email-masked]
Date: Fri, 13 Sep 2002 17:54:20 +0300

I think its much simpler if we have <event>.collection. 

Can the subscriber rely on the content-type of NOTIFY to decide if this NOTIFY contains payload for mwi or buddylist?

/Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 6:15 AM
> To: Ben Campbell
> Cc: [email-masked]
> Subject: Re: [Simple] collection template
> 
> 
> We could do something similar to what I had suggested for the Accept 
> header. The SUBSCRIBE has Allow-Events which lists the event types 
> supported. If one of the URI in the list is of a type not 
> indicated in 
> Allow-Events, the subscription is rejected.
> 
> Not quite the intended use of Allow-Events, for sure....
> 
> -Jonathan R.
> 
> Ben Campbell wrote:
> > Interesting. I am concerned, however, that the event 
> negotiation part 
> > would now get lost. The event is now "collection" rather than 
> > "presence.collection" or whatever. By subscribing to 
> <event>.collection, 
> > I am asserting that I care about and can do something useful with 
> > notifies with an event header of <event>. If I susbscrbe to 
> "collection" 
> > without an event scope, I now have to expect NOTIFY requests for 
> > arbitrary events.
> > 
> > 
> > Jonathan Rosenberg wrote:
> > 
> >> Folks,
> >>
> >> The current version of the old "buddy list" package now defines a 
> >> collection template that can allow a user to subscribe to 
> a list of 
> >> URIs for a particular package, such as presence.
> >>
> >> It has occurred to me since the meeting that we can take 
> this one step 
> >> farther for a really generally useful tool.
> >>
> >> The idea is to make this a collection PACKAGE, not a 
> template. The URI 
> >> that you subscribe to represents a list of URIs, each of 
> which can be 
> >> for a different package. The list would also include 
> information on 
> >> the package that URI is associated with.
> >>
> >> The idea here is that a UA could send a single subscribe 
> to a server 
> >> which would, in turn, fan out subscriptions to each of the 
> events/URIs 
> >> the user was interested in.
> >>
> >> Heres an example. Lets say a UA is interested in a 
> subscription to two 
> >> message waiting indicators and two buddy lists:
> >>
> >> sip:[email-masked], mwi package
> >> sip:[email-masked], mwi package
> >> sip:[email-masked], collection package
> >> sip:[email-masked], collection package
> >>
> >> the two buddy lists are themselves lists, each of which is 
> a URI that 
> >> represents a presentity. We could assign a single URI to 
> the two MWIs 
> >> and two buddy lists - sip:[email-masked]. 
> The UA would 
> >> then do this:
> >>
> >> SUBSCRIBE sip:[email-masked] SIP/2.0
> >> Event: collection
> >> Accept: text/collection-info, application/cpim-pidf+xml,
> >>   application/simple-message-summary
> >>
> >>
> >> The server would fan out a subscription to each element in 
> the list 
> >> within the package for that element, copying the Accept 
> headers from 
> >> the collection SUBSCRIBE. The collection server would be 
> responsible 
> >> for refreshing those fanned out subscriptions, and passing 
> the content 
> >> of notifications towards the UAC. The collection server could be 
> >> ignorant of the detailed operation of any of the packages, 
> and could 
> >> generate subscriptions for packages it doesnt even understand.
> >>
> >> If we envision that UAs will frequently have lots of long-lived 
> >> subscriptions to a number of things, this mechanism can 
> save a lot of 
> >> overhead for wireless or other access constrained devices. It 
> >> increases the administrative burden overall, since each 
> collection URI 
> >> needs to specify a modereately complex data structure - a list of 
> >> elements, each of which is a URI/event pair. But, I think 
> this is a 
> >> worthwhile tradeoff.
> >>
> >> Do people think this is a worthwhile approach?
> >>
> >> Thanks,
> >> Jonathan R.
> > 
> > 
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 Sep 2002 13:14:36 -0500

Inline.

> From: Jonathan Rosenberg [mailto:[email-masked]]
>
> The idea here is that a UA could send a single subscribe to a server 

I had imagined that the template approach could do the same thing.

> the two buddy lists are themselves lists, each of which is a URI that 
> represents a presentity. We could assign a single URI to the two MWIs 
> and two buddy lists - sip:[email-masked]. The UA would 
> then do this:
> 
> The server would fan out a subscription to each element in the list 
> headers from the 
> collection SUBSCRIBE. The collection server would be responsible for 
> refreshing those fanned out subscriptions, and passing the content of 
> notifications towards the UAC. The collection server could be 
> ignorant 
> of the detailed operation of any of the packages, and could generate 
> subscriptions for packages it doesnt even understand.

The template approach seems to have the same properties, except for the
heterogeneity of event types. So, for example, you could send the following
two messages:

SUBSCRIBE sip:[email-masked] SIP/2.0
Event: mwi.collection
Accept: text/collection-info

SUBSCRIBE sip:[email-masked] SIP/2.0
Event: presence.collection.collection
Accept: text/collection-info

For both of these, the node processing the collection templates does not
need to know anything about the underlying package (we defined templates
this way on purpose!) and can still operate in a useful fashion.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 16 Sep 2002 13:26:51 -0500

I appear to have missed the proposal you're referring to, and
I can't find it in the i-d archives.

The way 3265 is defined, if you subscribe to "presence.collection",
you get notifies for "presence.collection". You *never* get
notifies for "presence" because you did not subscribe to "presence".

This is an important property of templates. It allows for generic
implementation of them. For example, you can easily see how
it might be useful to subscribe to "foo.winfo" without even
necessarily knowing the semantics behind the "foo" package.

/a

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, September 16, 2002 7:52
> To: [email-masked]; [email-masked]
> Subject: RE: [Simple] collection template
> 
> 
> Hi Jonathan,
> 
> It seems that this approach also makes the recursion of 
> presence-list subscriptions easier. I had some doubts about 
> the previous template package based proposal (especially the 
> part about defaulting to presence from presence.collection), 
> because of the fact that one could potentially have both 
> presence *and* presence-collection events in the same SIP URI. 
> 
> So, I like this approach. Let's go for it.
> 
> Cheers,
> Aki
> 
> 
> > Sent: Friday, September 13, 2002 12:26 AM
> > To: [email-masked]
> > Subject: [Simple] collection template
> > 
> > 
> > Folks,
> > 
> > collection template that can allow a user to subscribe to a 
> > list of URIs 
> > for a particular package, such as presence.
> > 
> > It has occurred to me since the meeting that we can take this 
> > one step 
> > information on the 
> > package that URI is associated with.
> > 
> > increases 
> > the administrative burden overall, since each collection 
> URI needs to 
> > specify a modereately complex data structure - a list of 
> > elements, each 
> > of which is a URI/event pair. But, I think this is a 
> > worthwhile tradeoff.
> >

---

From: [email-masked]
Date: Tue, 17 Sep 2002 09:54:08 +0300

Hi Adam,

> I can't find it in the i-d archives.

Yes, it's not in the draft, but the issue was discussed in Yokohama. 

> notifies for "presence" because you did not subscribe to "presence".

The issue was with recursing of presence.collection subscriptions, i.e., if a URI in the buddy-list was itself a list of URIs, you could potentially recurse the subscription until it reached the "leaf" and defaulted to the presence event of that URI.

However, the above looks like something destined not to work. Now I forget the other option that was presented as possible solution for this recursing problem...
 
> necessarily knowing the semantics behind the "foo" package.

Yes, this is very clear.
 
Cheers,
Aki

---

From: [email-masked]
Date: Wed, 18 Sep 2002 10:12:18 +0300

You left out one scenario (the one we should really be comparing to collection as a package), which is the one that uses collection as a template. It very much looks like your first diagram, if its for one type of package like presence. The numbers increase slightly if there is more than one base package that need to use the collection template.

Besides the security issues and who authenticates/authorises who, there is the issue of filtering. Each package like presence, mwi, winfo or whatever might have its own filtering that needs to be apply. A collection package does not help is this situation.

Subscription duration: What is the behaviour when a SUBSCRIBE for collection package is used and the fanned out subsriptions resulted in lower expiration intervals than the interval sent in the original SUBSCRIBE to the collection package? This is probably a case for both types of collection packages, but I see much more complicated when the subscription is for 2 or more different types of services.

Regards,
Hisham 

> From: ext Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, September 17, 2002 6:58 PM
> To: 'Paul Kyzivat'; Adam Roach
> Cc: 'Sean Olson'; Niemi Aki (NET/Espoo); Jonathan Rosenberg;
> > From: Paul Kyzivat [mailto:[email-masked]]
> > 
> > > > It could be improved vastly in some cases if many collections
> > > > have elements in common, and the server is permitted to
> > > > multiplex one subscription to a collection element across
> > > > many containing collections. Moreso if the lifetime of the
> > > > subscriptions the collection server makes are independent of
> > > > those to the collections it serves.
> > > 
> > > After studying this problem for an extended period of time, I
> > > have reached the conclusion that this sort of aggregation doesn't
> > > generally work. The permissions problems that arise from doing
> > > this are pretty much intractible unless you make some walled-
> > > garden type assumptions about how servers are going to protect
> > > the data they receive in this way.
> > 
> > I'm inclined to agree, but I keep looking for a way to make 
> > it work, because otherwise there are significant scaling 
> > problems with highly interconnected collections of users - 
> > its something like O(n^2).
> 
> That's true. It's a general truth that comes with any model of
> presence that allows users to set policy that is different
> for different sets of watchers, regardless of whether you
> use collections. Let's consider a system of two servers,
> each of which has three clients. Each client has a subscription
> to all five other clients.
> 
> With collections, the number of subscriptions between each
> node is as follows:
> 
>         +----+        18        +----+
>         | S1 |------------------| S2 |
>         +----+                  +----+
>      2 / 2|  2\               2/ 2|  2\
>       /   |    \              /   |    \
> +----+  +----+  +----+  +----+  +----+  +----+
> | C1 |  | C2 |  | C3 |  | C4 |  | C5 |  | C6 |
> +----+  +----+  +----+  +----+  +----+  +----+
> 
> Each client has a collection subscription to its server; each
> server has either a non-collection subscription to each of its
> clients or a publication relationship. I'm going to consider them
> to be about as heavy as each other. I'm making an assumption that
> clients trust their own server to honor their privacy policies,
> instead of implementing all privacy at the peer level.
> 
> Given these assumptions, we have a total of 30 subscriptions
> in the system. It should also be obvious, as you state, that
> the number of subscriptions in the system increases at the rate
> of about O(n^2).
> 
> Now, let's look at the same system without collection subscriptions.
> (Sorry; the limitations of ASCII art show up here).
> 
>                  ----------------------
>                 /3                     \
>                /        +----+  +----+  +----+
>               /  -------| C4 |  | C5 |  | C6 |
>              /  /3      +----+  +----+  +----+
>             /  /             3\/ 3|   3/
>            /  /            3  /\  |   /
>         +----+----------------  +----+
>         | S1 |   ---------------| S2 |
>         +----+  /3      --------+----+
>       3/ 3|  3\/       /3      /
>       /   |   /\      /       /
> +----+  +----+  +----+       /
> | C1 |  | C2 |  | C3 |      /
> +----+  +----+  +----+     /
>       \                  3/
>        -------------------
> 
> Here, each client has two subscriptions to its local server
> (one for each other client attached to that server), and the
> server has either a subscription to or a publication relationship
> with each of its clients. Each client additionally has three
> subscriptions to the remote server (one for each of its clients),
> leading to 18 interdomain subscriptions (exactly like before).
> In total, then, this system -- the one without collections --
> has 36 total subscriptions. It should also be obvious that this
> system will increase the total number of subscriptions at the
> rate of approximately O(n^2).
> 
> So, yes, you've hit on the fundamental scaling problem inherent
> in presence systems. Collections neither worsen nor significantly
> improve this. What collections *do* accomplish is reduction of
> the traffic from the client to the server. If you go through
> the excercise of increasing the size of the systems I've diagrammed
> above, you'll notice that the system with collections keeps the
> relationship between the client and the server(s) to 2
> subscriptions (or one subscription and one publication relationship),
> while the system without collections increases this realationship
> linearly as you add users.
> 
> > There is a permissions problem even if you don't aggregate 
> > this way. In order for the permissions to be evaluated in a 
> > straightforward way, the server for a collection will need to 
> > represent itself as the user who subscribed to the 
> > collection, or as an agent that has been explicitly 
> > authorized to act on behalf of that user. I don't see an 
> > obvious way to do that other than for each user to provide 
> > the collection server with one of his secret keys, or else to 
> > have the end user sign a certificate for the collection server.
> 
> Now this *is* an interesting problem. If this problem is
> tractible (and it feels like it should be), then we're home
> free. I'll leave it to the security guys to comment on whether
> this sort of limited delegation is something that's feasible.
> 
> /a