I split out this issue from Dale's email into a separate message. ext [EMAIL PROTECTED] wrote: > The entity-tag values for a single resource are the same across > subscriptions, but it is not clear whether they are in some sense the > same between subscriptions for different resources, or for different > resource-IDs that refer to "the same" underlying resource. This may > have significance for renewed subscriptions whose initial requests are > sent to the same resource AOR but which are ultimately routed to > different but "equivalent" resource-IDs.
Qian also had similar comments; obviously this seems to be something the draft does not define clearly enough. I suspect Section 5.1. would need additional text explaining the model behind etags in more detail. However, before we try to come up with that text, let's see if we are on common ground on some basic assumptions (as I suspect we might not be there 100%). For the most parts the model should be equivalent to that in HTTP (or at least to my reading of RFC2616). Here are the assumptions under which subnot-etags are currently defined: - There is a single authoritative notifier agent responsible for any single resource. - A resource is identified using a SIP URI. - A subscriber subscribes to a resource using the SIP URI. - With a successful subscription, a subscriber gets access to an entity from the resource. (Entity is HTTP lingo, and basically means a certain "view" of the resource state.) - An entity can be influenced by different external data, e.g., filter rules, authorization rules, etc. - There is a one-to-many relationship between the resource and the entities. - Each entity has an assigned entity-tag. - There is a one-to-many relationship between an entity and its versions (different etag values, of which only one is current). - An entity-tag must be unique across all versions of all entities from a resource. - The rest are implementation details. Comments? Cheers, Aki _______________________________________________ Sip mailing list https://www1.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
