From: Aki Niemi <[EMAIL PROTECTED]> 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. And my original suggestion was that it not even attempt to address it. But rather that it provide a warning that under some circumstances it could produce paradoxical results. (I'm assuming that you agree with me that these problems could arise.) > 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. Unfortunately it's not. But that isn't relevant. The 'version' parameter is *mandatory* for some event packages, and it makes ETags (as they are now defined) nearly useless for those packages. 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
