On ti, 2008-03-04 at 07:19 -0800, ext Eric Rescorla wrote: > > [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.
Then I'd appreciate any suggestion to make it clearer. > 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. Can you point out the unambiguity? > > 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. It means the only thing the client is ever going to do is offer that same entity-tag back to the notifier in a Suppress condition. The entity-tag, as defined, is an opaque token that has no meaning to the subscriber beyond serving as a tag, or reference to the state it received in the NOTIFY. If the draft says something contrary, we'll change it. > 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. The header field is actually called SIP-ETag just for this purpose. Unlike RFC2616, we don't have weak and strong entity-tags, nor do we allow a list of entity-tags in SIP-ETag. Especially the former is what makes entity-tags confusing in HTTP. This is also discussed somewhat in RFC3903 where SIP-ETag is defined. I can add some text to the introduction that refers to that RFC with regards to entity-tags. 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
