It seems like there are a number of open issues: 1. Is the only thing that is important from the subscriber's point of view the current value of the event package, or is it important to know something of the history of that value? (People have been discussing this.)
2. The interaction of ETags with partial notifications. The draft reads: With partial event notification, the NOTIFY message only carries the delta state, or the set of changes to the previous version of the entity. In that case, implementations MUST consider the full event state as the version of the entity to which the entity-tag in the NOTIFY message applies. That is, the ETags carry information about the composed full state that the subscriber is maintaining by integrating the partial notifications that it receives. But it is problematic to use partial notifications in combination with ETags: When the notifier determines that the subscriber's current state ETag is different from the current ETag of the resource, it does not know what the subscriber's current state *is* (unless it maps the presented ETag to a previous package value), and so cannot update the subscriber with a partial notification. Use of ETags seems to effectively require the use of full notifications at all times. 3. Some event packages (e.g., dialog and resource-list) specify that the package values within any individual subscription be sequence numbered via a 'version' attribute in the XML. This reduces the chances of an ETags match between requests that are part of different subscriptions, because a new poll-type SUBSCRIBE will necessarily fetch a value with 'version="1"', and its ETag will not match the ETag of any value that had a different version attribute, even if the rest of the XML is the same. This is particularly unfortunate because the version attribute does not carry information that is important to the application; it is control information that is largely redundant with the ETags mechanism itself. 4. Conflicting assignments of ETags to values in notifiers that are not co-administered, but are alternative forking destinations of some URI in the universe. (People have been discussing this.) Dale _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
