On ke, 2008-03-05 at 14:59 -0600, ext Dean Willis wrote: > On Mar 5, 2008, at 7:44 AM, Aki Niemi wrote: > > > > The entity-tag is an opaque token to the subscriber. The > > subscriber MUST NOT attempt to infer any meaning from the value > > beyond a simple reference, or assume a specific formatting. > > The > > relationship between the current entity-tag and any future or > > past entity-tags is undefined. > > > But we DO infer something -- if the entity tag has changed, then the > object has changed. So we infer that the object has changed when we > see a different entity tag.
No, we really don't. The semantic for the subscriber is simply: ah, a notification! That'd be the current state of the resource. Oh, there's also a reference tag on it. Great. I'll store them and render the state to the user. The semantic is not: hmm, a notification. I know they're supposed to be generated when state changes, but I'm not convinced the state has changed. I better match the etag with my stored history of etags to see whether the state *really* changed. Ha! A match! The notifier farm must've rebooted or the Lakers indeed fired Koby! I better calculate the nth decimal of pi, launch doom and busy-loop for the rest of the day. There *really* is no comparison done; the subscriber throws away the old state when a NOTIFY is received, and stores the new state. (In the case of partial notification, there's also patching done, but still no comparison of etags). This is how notifications work without conditional notification and we're not changing that in any way. > But if the object changes (and we miss the notification), then changes > back (returning to the same entity tag value) then we can no longer > infer that the object changed, because we have the same entity tag. We > don't know that the object ever changed, and would assume that it had > just always been the way it is. Thus our inference would be incorrect. > > While this may not matter to the state of the object, it might matter > to our understanding of how the object arrived at that state. > > On the other hand, if the entity tag were unique for each version of > the object, we'd at least know that there had been some state change > in the object (which could have been a missed notification, or might > have been a null-operation that just updated the timestamp). > > I have a vague, queasy feeling that this might turn out to be > important for some applications. But perhaps I'm looking at this in > the wrong way. > > For objects where this kind of state awareness matters, perhaps one > could just require that the object in question include a timestamp, > or better yet a serial number. Assuming this application currently doesn't use etags, how is it *now* handling missed notifications? If it requires etags to handle them correctly, then it's using etags in a way they're not meant to be used. I would rather see the event package itself sport a mechanism that allows it to carry this additional information about recent state transitions, if necessary. IMHO, that is the only correct place for such features. 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
