On Mar 9, 2008, at 7:00 AM, Aki Niemi wrote: > > On pe, 2008-03-07 at 23:27 +0200, ext Dean Willis wrote: >>> We're sending it so that the next time the subscriber sends a >>> SUBSCRIBE, >>> it can say: "Here's the last entity I've seen. Suppress-If-Match, >>> please". >> >> But in the case we're discussing, the last entity the subscriber has >> seen is not the last entity that that the server has seen. And the >> entity that the subscriber currently has isn't the same entity that >> the server has > > What makes "seen" and "has" different here?
see below . . . > > >> -- it's another entity that just happens to have the >> same etag as the entity that the subscriber currently has. > > This is against what the draft says. We require unique etags "across > all > versions of all entities for a resource and event package". But that's not what you said earlier. 1) Let's say I have an resource that consists of the string "abcd" and the eTag "H". 2) The resource's string value changes to "defg" and its eTag changes to "89" 3) It's value changes again, this time to "abcd". Can it have the eTag "H" again, or does it have to have an eTag that is unique across all versions of the resource? Coming back to the "has" vs "seen" question. if a watcher misses the "defg" eTag "89" phase at step 2for some reason. It sees state 1, then it sees state 3. If the eTag is allowed to repeat, it doesn't know it missed a state change. If the eTag is required to be unique, then the watcher knows SOMETHING happened, just not exactly what that was. My current belief is for applications in which this matters, the object should contain a serial number or timestamp so that the object's value never repeats. This pretty much makes the question moot. > > > Now I understand the text needs a little explaining, which I'll add, > about what "version" really means here, i.e., can two versions with > identical content also have identical etags? > Yes! That is exactly the question. > This is the special case that we need to explicitly call out. For > instance, an MD5 sum over the entity is a good enough entity-tag, even > though it will give the same entity-tag to different "versions" of > entities, albeit they're entities with identical content. > >> That's a close enough match for some purposes (perhaps all of our >> purposes), but it's not the same thing. > > I still fail to see what significance this has for the subscriber? The > subscriber is at the mercy of the notifier, and it's the notifier's > responsibility to keep its entity-tags straight. It all depends on whether the application requires the subscriber to know about ALL transitions to the notifier state or perhaps requires knowing about null-transitions -- that is, where the object was "written" but its value did not change. -- Dean _______________________________________________ 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
