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? > -- 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". 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? 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. 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
