On Mar 4, 2008, at 9:19 AM, Eric Rescorla wrote: >> >> What we currently say on the subject is this: >> >> [An entity-tag is] guaranteed to be unique across all versions >> of all entities for a resource and event package. >> >> If the version of the entity, in this case "A", is identical to a >> previous version, which is "A" in this case, then the entity-tag can >> certainly be the same as well. > > It's not clear to me that the text you are quoting implies the > interpretation that you just provided. In fact, I would note that you > are referring to "the version" and "the previous version" which > suggests that they are separate versions and must have different > ETags. > > Given that when I asked this question I got two different answers from > Dale and Dean, I submit that the draft might be improved by directly > addressing this point. Note that I don't care about the resolution, > but I do care that the draft be unambiguous. > > > >> We would have the exact same result were we to generate the entity- >> tag >> value using a hash function over the entity itself. >> >> This is also unimportant for the subscriber, since it needs to >> store the >> entity-tag "statelessly", and cannot defer any meaning from its >> value. > > I'm not sure what that means, but I'm not convinced that this is > meaningless to the client.
I look at it in terms of sequential application of differential transforms. If we start with a given object O1, then there exists a differential transform D1 that when applied to that object produces a second object, 02. In other words, D1(O1)->02. Clearly O2 has a different etag from O1. If we then apply a second differential D2 that produces O3 such that D2(O2)->O3==O1, we have a new object O3. Is it reasonable for O3 to have the same etag as O1? Mathematically, it's not the same version of the object -- it's another version of the object that just has the same value. So it instinctively irks me to give it the same entity tag as that other version of the document. Consider the aspect of state -- if I'm sending the whole object every time, it doesn't matter. If I only work from the current version of an object, it doesn't matter. But if I'm doing version control and I need to make sue I've stored the entire sequence of transformations (or at least know whether I've missed any steps), it DOES matter. Working as Aki proposed, any cycle (any sequence of transformations that takes us back to a state we've seen before) could be undetectably dropped out of the history. Do we have a requirement to keep our history straight? Perhaps not. After further reflection, I think that for the common use case (keeping track of the current version of a document with full document transmittal) the technique as proposed by Aki works just fine. Since etags aren't really sequential, we don't really gain anything by the ability to detect dropped cycles, do we? Somebody needs to think this through from the perspective of partial notification. -- 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
