<--! From: Jonathan Rosenberg dynamicsoft.com> Subject: Re: Thoughts on list template Newsgroups: gmane.ietf.simple Date: 2002-11-21 08:18:10 GMT (3 years, 46 weeks, 4 days, 16 hours and 32 minutes ago) inline. Ben Campbell wrote: > This certainly seems like an elegant way to allow assymetric hierachies. Thanks. I definitely think this is right. > There are a few areas that give me heartburn, but on reflection, I > realize these issues are with the idea of recursive lists in the first > place. > > 1) We talk about the idea that a watcher can infer list contents from an > initial full state notify. But it is not entirely clear to me what a > full state notify looks like for a list that contains other lists. Do we > expect the watcher to be able to infer the full hiearchy? I thought that the presence list server (or whatever we are calling it these days) would subscribe to each element, and when it gets the notifies, will know whether each element is a single URI or itself a list. It then reports its own result as a list, where elements are either a single URI, or another list, based on its downstream subscribes. The result is that the hierarchy would be constructed and placed in the full state notify. Now, the bigger issue is full-state notifies for big lists. They quickly become unwieldy. If we apply the current semantic - which is that NOTIFY's triggered from SUBSCRIBE contain full state, you end up with this huge NOTIFY after every refresh, probably not what you want. If you assume that the list structure itself (ie., the set of presentities in any list), rather than the state of the presentities, is synchronized separately, you don't really have a strong need for full state updates. Instead, you can send a bunch of partial updates (state for a single presentity) that are then used by the subscriber to fill in the state of the individual leaves of the tree. Its probably OK for those partial notifies to be sent to the subscriber over some window of time after the subscribe (i.e, it takes 2 seconds for the state of all leaves to be transferred). We could also define a parameter in the SUBSCRIBE somewhere that explicitly tells the server to send a full state in a NOTIFY. The deafult operation is to never send full state, only when requested. > > 2) Robert mentioned a scary one to me this morning: What about circular > references in lists? Yikes!! We can either do a "hop counter" - every time a server triggers a subscription to get state for an incoming subscription it decrements a counter, or we can detect the loop through a persistent identifer as sean suggests. I think that there is no real meaning of "spiral" here, which would immensely complicate such an approach. One way or another, we have to worry about this case if we accept recursive lists. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com --> Pingtel Corp.

400 West Cummings Park, Suite 2200 Woburn MA 01801 US +1 781 938 5306 x173 dworley@pingtel.com

Transport SIP Resource list event package The author implemented a server for SIP "resource list" events. Based on the implementation experience, the author lists a number of desiderata for the design of the resource list event system for it to achieve its design goal of minimizing network traffic between the UAC and UAS for the resource list URI. The current definition of resource list events is assessed in light of these desiderata.

The concept of a "resource list" event is to provide a means of aggregating into a single subscription the event notifications that would be produced by a set of subscriptions to a set of resources. A SUBSCRIBE specifying a particular event-type is sent to a URI. This URI routes the SUBSCRIBE to a "resource list server" which implements the resource list notification algorithm for a particular set of resources. The set of resources is implied by the URI, but is perhaps known only to the resource list server. That the SUBSCRIBE is for a resource list is determined only by the request-URI, but the willingness of the UAC to accept resource list event notifications is specified by a "Supported: resource-list" header. The resource list server establishes and maintains subscriptions for the specified event-type to the resources in the set. (These subscriptions can be SIP subscriptions or can use other means, but the information obtained by the subscriptions is modeled as a series of event notifications as in . The notifications received from the subscriptions for the member resources are aggregated into multipart MIME bodies which are the event notifications for the resource list subscription.

This section lists a series of desirable properties for the design of the resource list mechanism. Some are extracted from its definition , others were observed during implementation of a resource list server. They are intended to support the situation when the resource list server is distinct from the notifiers for the individual resources, and obtains its information by mechanisms similar to SIP event subscriptions. In general, these desiderata are intended to reduce the network traffic between the subscriber and notifier of the resource list subscription in the face of uncooperative notifiers for the individual resources in the resource list.

The resource list notification algorithm should be independent of the event-type, and thus of the structure of the event notifications for that event-type. This independence allows the resource list server to process all event types for its resource list. The current design achieves this independence.

Whether the resource list is ordered (a list) or unordered (a set) must be specified. The current design leaves it unstated whether the resources in the resource list are ordered or unordered, and implicitly, whether the <resource> elements that are within the <list> element in RLMI XML must be in their natural order. The current design does not specify an ordering, which seems to imply that there is no ordering. And yet, I have seen UACs for resource list subscriptions that depend on an ordering.

Whether a particular URI may appear more than once in the resource list must be specified. (And if duplicates are not allowed, the comparison rule must be specified.) Since a resource URI has no identifier other than its URI (e.g., its ordinal number in the list), <resource> elements are only identified a resource URI. This implies that a specific resource URI can appear in a resource list only once. But this might be an inconvenient restriction in practical situations. In addition, if a uniqueness requirement is laid on the resource URIs, there should be a statement of what the uniqueness requirement is, as two URIs can be "the same" according to the rules of their schema without being textually identical.

The duration of the resource list subscription should be independent of the duration allowed for the individual resources. In particular, it should be possible for the duration of the resource list subscription to be substantially longer than the subscription allowed by individual resources. This is achieved by the current design.

If the resource list subscription duration is longer than the resource subscriptions, if there is no change in the state of the resources over a refresh cycle for the resource list subscription, only one resource list notification should be generated (in response to the re-SUBSCRIBE). This is quite helpful in reducing the amount of network traffic generated by a resource list subscription. But since two updates to the state of a single resource cannot be sent in the same resource list notification, and each re-SUBSCRIBE to a single resource generates an update for that resource, the resource list server is constrained to send notifications at least as often as the fastest re-SUBSCRIBE rate of any of its individual resources. (This limitation can be lifted if the resource list server understands the semantics of the notifications for the subscription's event-type and reaggregates the information into a new stream of event notifications summarized at the moments it chooses, but that violates the principle of event-type independence.) It seems like it would be useful to extend the design to allow a single resource list event notification to contain multiple <instance> elements for the same instance (with the same id attribute), to carry successive notifications for the same resource instance.

If two subscriptions are established to the same resource list, the resource list server should need to only maintain one subscription to each individual resource in order to serve both resource list subscriptions. Similarly, if two subscriptions are established to two resource lists which both have a particular resource as a member, the resource list server should need to only maintain one subscription to each individual resource in order to serve both resource list subscriptions. Avoiding redundant subscriptions is advised against in for security reasons. This aspect of this desideratum is discussed below in "Security Considerations". In addition to security considerations, there are architectural features that make it difficult to avoid redundant subscriptions to individual resources. Many event types require that the event notifications be serial numbered starting with a specific number, making it difficult copy the latter part of a sequence of event notifications and present it as a valid sequence of event notifications. Also, some event types allow "partial" notifications, and so a valid tail of a sequence of event notifications must start at a "full" notification. This means that the initial notification may have to contain a full notification and a series of partial notifications to bring it up to date. Absent a mechanism for putting several notifications for the same resource in one resource list notification (see above), this requires sending a series of notifications to transmit the initial state.

The subscriber to a resource list should be able to throttle notifications more intensely than would be permitted by the individual resources.

Since the set of subscriptions generated by a SUBSCRIBE directed to an individual resource may change over time, the resource list server needs a way to represent the set of subscriptions for each resource URI and how it changes over time.

Individual resources in a resource list may be the URIs of other resource lists. The resource list server must be able to indicate whether it is willing to process such nested resource list event notifications, and if it is, it must be able to avoid recursive membership loops.

An initial SUBSCRIBE, and especially an initial SUBSCRIBE with "expires=0", should return the complete state of all the resources.

(These security considerations are in addition to the security considerations described in .) It should be noted that the resource URIs contained in a resource list are revealed to the subscriber to the resource URI.