On ke, 2008-03-05 at 23:42 -0500, ext [EMAIL PROTECTED] wrote: > 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.)
IMHO, this is not a use-case that conditional notification needs to address. > 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. Correct. The draft also talks about this. If the notifier wants to do journaling, it not only needs to generate unique etags, it also needs to *remember* them, along with the entities. Once it has this history, it can generate a diff based on the entity-tag in the Suppress-If-Match and the journal it has stored. > 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. Um, the 'version' parameter is largely redundant with the CSeq. Cheers, Aki _______________________________________________ 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
