Subject: RE: [Simple] collection template

From: Adam Roach <[email-masked]>
Date: Mon, 16 Sep 2002 18:05:19 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> 
> Adam Roach wrote:
> > 
> > It appears to me that the cleanest approach will still
> > be to use the template approach. This allows us to reduce
> > the number of subscribes to match the number of event
> > packages supported by the UA. This is still much smaller
> > than the number of URIs being subscribed to, and appears
> > to require far less standardization.
> 
> This reduces the number of subscriptions issued by UACs. But 
> it doesn't reduce the number of total subscriptions - it 
> increases it. And it doesn't reduce the number of 
> notifications received by the UAC (well, its actually a UAS 
> for the notify, but you know what I mean.)

This is true for both the collection package and the collection
template-package approach.

This is a known architectural result of the approach being
pursued. If operators don't want to support this, they can
disable whatever collection mechanisms are available on their
servers; this would force the clients to either not subscribe
or to fall back to sending individual subscriptions instead
of subscriptions to collections.

> It might even increase the number of notifications further - 
> if the collection refreshes its subscription to each member 
> of the collection before it expires, and also refreshes each 
> subscription when the UAC refreshes its subscription to the 
> collection.

This is true for both the collection package and the collection
template-package approach.

I would expect reasonable implementations of servers that aggregate
these subscription collections to not pass along information unless
it has actually been updated. This means that if it is using
SUBSCRIBE on the back-end to learn about state, it won't send the
resulting NOTIFY messages to the collection subscriber unless the
NOTIFY actually represented a change in state.

I would NOT expect the server that agregates these subscriptions
to automatically refresh their subscription to the members of
the subscription every time the the UAC refreshes its subscription
to the collection.

> This situation could be improved if the collection can be 
> set, via filters or whatever, to normally return only changes.

This is true for both the collection package and the collection
template-package approach.

I would expect this to be the normal mode of operation, in fact.

What I *would* hope to be able to do via filters is say something
like "when you get a state change, hold off 30 seconds before
sending it to me, in case you get additional changes that you
might be able to send in the same message" or something like that.
 
> 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.

This is true for both the collection package and the collection
template-package approach.

> Of course there is a problem with this. If you and I both 
> subscribe to X, we may get different results based on who we 
> are. If we both subscribe to collection CX, is the data 
> delivered to the collection server on our behalf the same as 
> we would have gotten directly? Or is the data delivered to 
> the collection server by X based on the identity of the 
> collection server?

This is true for both the collection package and the collection
template-package approach.

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.

Was your letter trying to differentiate the package approach from
the template-package approach? That is what context would imply,
but the content doesn't seem to live up to that expectation. Or
were you just trying to raise issues with the idea of subscription
collections regardless of which approach is taken?

/a
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 17 Sep 2002 09:32:41 +0300

I believe the collection template-package approach is a cleaner and
simpler solution.

Having a server fan out heterogeneous (i.e., different events)
subscriptions seems to me like streeching too much the concept of a
collention of events.

Let's handle different events with different SUBSCRIBES.

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Sep 2002 09:32:49 -0400

below...

	Paul

> collections regardless of which approach is taken?

The latter.

> 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).

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.

	Paul