At Tue, 04 Mar 2008 13:08:05 +0200, Aki Niemi wrote: > > > On ma, 2008-03-03 at 10:32 -0800, ext Eric Rescorla wrote: > > I'm sure I'm wading into a swamp here, but: > > > > Say I have a resource identified by URI http://www.example.org/X. > > > > 1. Initially it has value A. I do a SUBSCRIBE and get value > > "A" and Etag 1 > > 2. I do a subsequent get and get "B" with Etag 2. > > 3. I do a third get and get "A". > > > > Can the Etag in event 3 be 1? > > 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 also wonder whether it's a good idea to call this feature ETags. My understanding is that ETags has been a very confusing feature of RFC 2616. Even if we think that the semantics here are the same, perhaps we should consider giving it a different name. -Ekr _______________________________________________ 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
