Subject: RE: [Simple] collection template

From: Adam Roach <[email-masked]>
Date: Fri, 20 Sep 2002 14:10:47 -0500

> This suggestion might also address one issue I had. When you 
> first establish the subscription, or refresh it, or do a 
> one-time poll for status, the event mechanism requires that a 
> single notification be returned immediately, containing the 
> current state of the resource (in this case the contact 
> list). This is hard to do if the only notifications are 
> relays of notifications from individual members of the collection.

RFC 3265 requires a NOTIFY. That NOTIFY isn't required to contain
correct state information, just well-formatted state information.

> This idea would begin to solve that problem. But other 
> problems remain. For instance there is then still no way to 
> poll for the current state of everything in the collection.

I'm willing to accept that as a limitation of the mechanism. Polling
is usually too heavy on network resources to warrant deployment.

> Also, the kind of response you are describing doesn't seem to 
> fit within the current definition of PIDF.

It wouldn't *be* PIDF. It would be whatever the collection
{package,template} defines. My vote would be for mime multipart.

> Without some kind of change I don't see how to make a 
> collection conform to all the rules of an event package.

Odd. I don't see any barriers.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Sep 2002 19:08:07 -0400

Adam,

I appologize - I have allowed a bit of confusion to creep into this discussion between collections in general, and presence collections. Torrey seems to be interested in presence collections, and so he is proposing a modification to PIDF, or a special use of PIDF, to represent the collection as a whole in the initial response to a subscription.

But as currently being discussed, the collection needs to work for any kind of event. (But only one type of event at a time with templates.) This puts different constraints on the problem. There must be a way to define a valid form of initial response without knowing anything about the content type for the members of the collection.

More below.

	Paul

> correct state information, just well-formatted state information.

I read the requirement as a bit stronger than that. From 3.1.6.2:

   Upon successfully accepting or refreshing a subscription, notifiers
   MUST send a NOTIFY message immediately to communicate the current
   resource state to the subscriber.  This NOTIFY message is sent on the
   same dialog as created by the SUBSCRIBE response.  If the resource
   has no meaningful state at the time that the SUBSCRIBE message is
   processed, this NOTIFY message MAY contain an empty or neutral body.

Here I think we have to assume the "resource" is the collection, and that "communicate the current resource state" means "communicate the FULL resource state". Sending the state of one, or a subset, of the members of the collection is not the same thing as communicating the current resource state. Nor is it an empty or neutral body. So far there isn't any neutral body that would apply to a collection, except an empty body.

The above assumes that the subscribe is immediately accepted. It would also be possible to treat this case as falling under the following from 3.1.6.1:

   If the notifier cannot immediately create the subscription (e.g., it
   needs to wait for user input for authorization, or is acting for
   another node which is not currently reachable), or wishes to mask
   authorization policy, it will return a "202 Accepted" response.  This
   response indicates that the request has been received and understood,
   but does not necessarily imply that the subscription has been
   authorized yet.

This could be without a body I think, so it would technically comply. Subsequently, notifications with the state of individual members might be delivered. But this wouldn't be useful in a polling mode.

So, the way I read the current proposal and 3256, the only real option for the initial response is an empty body.

> is usually too heavy on network resources to warrant deployment.

Yes, if it is done repeatedly. But certainly there are cases where it is appropriate, such as single-shot use. Maybe this is an acceptable limitation for collections. I'm not sure.

> {package,template} defines. My vote would be for mime multipart.

That comment only made sense in the context of Torrey's message, which is specific to presence collections.

In general, I thought the proposal under discussion used the same content type collection.foo at is used for foo. The trouble with that is that it can in general only represent the status of a single foo, not a collection of foo, and so doesn't fulfill the requirements of 3265.

> Odd. I don't see any barriers.

Well, maybe only small barriers. Or maybe I misunderstand what the current proposal is. I think you can make this work in one of the following ways:

1) content type for collection.foo is same as for foo. The initial response for a subscription to content.foo is always without any body. (Assuming that is the same as an empty body.) Subsequently, status for members of the collection is returned in distinct notifications when it becomes available.

2) content type for collection.foo is always mime multipart plus the content type for foo. The initial response can be a multipart with exactly one part for every member if that can be returned promptly. If not it would have to be an empty body rather than returning state for a subset of members. If there happens to only be one member in the collection, it could be returned without the multipart wrapper. Subsequently, status for members of the collection can be returned independently, or grouped in a multipart wrapper.

3) Instead of returning empty bodies as above, return a body containing the definition of the collection. (This will probably need to be defined as a mime type so it can be defined anyway.) Subsequent notifications could conform to 1 or 2 depending on whether subscriber supports multipart.

4) change 3265, relaxing the requirement that the initial notification in response to a subscribe communicate the (full) current state of the resource. This could possibly take the form of a parameter to the subscription indicating that it is ok to omit the initial full status in favor of some kind of partial status.

I personally have a preference for (4), because I see other cases where requiring full status (for instance in refreshes) is burdensome. But (3) is also appealing.

	Paul