Subject: RE: [Simple] collection template

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

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
>  
> At the very least, I would not rely on the Accept
> headers for a pseudo-negotiation. Instead, I would
> turn to an appropriate "filter" for the body of 
> the SUBSCRIBE to create a meta-level of negotiation.
> This is already feeling too complex to me, but we
> should make this as clean a design as possible.

I think Sean's hit on the thing that's bothering me
here: we're overloading the semantics of headers
here. We've made this mistake in the past, and should
now recognize it as such.

I agree that if we're to go down the path of making
this a package, we need to define clean semantics for
this negotiation, and that they need to be separate
from the normal event negotiation.

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.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Sep 2002 16:16:25 -0400

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

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 situation could be improved if the collection can be set, via filters or whatever, to normally return only changes.

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.

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?

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Sep 2002 04:27:03 -0400

Adam Roach wrote:
 >> -----Original Message----- From: Sean Olson
 >> [mailto:[email-masked]]
 >>
 >> At the very least, I would not rely on the Accept headers for a
 >> pseudo-negotiation. Instead, I would turn to an appropriate
 >> "filter" for the body of the SUBSCRIBE to create a meta-level of
 >> negotiation. This is already feeling too complex to me, but we
 > I think Sean's hit on the thing that's bothering me here: we're
 > overloading the semantics of headers here. We've made this mistake in
 > the past, and should now recognize it as such.

I agree that we should not overload these things.

I am really trying to flesh this idea out some more to see how much 
merit it does or doesn't have. It does have a clear benefit in reducing 
client to server traffic, as the only one advantage over the template 
approach.

The right way to think about the collection package is to forget about 
fanout. The fanout of subscriptions represents one, but not the only, 
way in which the server can find out about the state of the thing thats 
being subscribed to. In this case, the thing is a list of resources, 
which is itself a resource, called a collection. What differentiates a 
collection as a resource from other resources is that its state is 
described by a variety of different document formats, rather than a 
small number that is bound to the package itself. Event package 
negotiation is per the spec; this resource could potentially support a 
variety of event packages beyond the collection package.

Now, like any other resource, if you SUBSCRIBE to it, but don't list a 
document format in the Accept header thats needed to understand events 
generated by that resource, the subscription fails. Same here. If I list 
a set of document formats in my SUBSCRIBE that doesn't cover the full 
set of formats I need to understand events generated by that resource, 
the subscription fails. How the server determines whether that list is 
correct, is its own choice. It could copy the Accept header into 
fanned-out subscriptions as I suggested. Or, it could know the types for 
each package and reject the subscription outright if it finds one missing.

So, in this way of thinking about a collection package, there is no such 
thing as negotiating packages for the fanned out subscriptions between 
the the UAC and the actual notifiers. Each leg negotiates its packages 
independently.

A collection does appear to represent a well-defined package. It would 
define its own default subscription duration. It has a well-defined 
treatment for forked requests (not allowed). It would have its own 
notification rates; the entire point of the package is to buffer 
package-specific notification rates and have one independent one. State 
agents would make no sense in this package.

Filters would allow you to specify what aspect of the resource you do or 
don't want to know about; this would provide the mechanism, for example, 
to request more frequent presence updates and less frequent MWI updates.

So, I think its a reasonable package definition. However, there is no 
doubt that its somewhat of a hack. I would welcome thoughts on other 
specific problems that arise with it, to determine if it makes sense or not.

-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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Sep 2002 10:06:38 -0400

> agents would make no sense in this package.

There is one way that it is not like a well-defined package:

With a normal event package, when you send a subscription you get back an initial notification that is supposed to represent the full state of the subscribed resource, and if your subscription is a poll (Expires:0), then you expect to get only the one notification.

With the collection package as I think you are proposing it (or even the collection template) this isn't really the case. The initial subscription might result in a bunch of notifications, each carrying part of the state of the collection as a whole.

This could be fixed in various ways:

- the collection server could buffer the responses from all the members of the collection and return everything in a single multipart response.

- we could change rfc 3265 so that the first notify in response to a subscribe isn't necessarily obligated to report the full current resource state.

- (are there other ways???)

	Paul