At Wed, 05 Mar 2008 15:44:49 +0200, Aki Niemi wrote: > > > On ti, 2008-03-04 at 12:55 -0800, ext Eric Rescorla wrote: > > At Tue, 04 Mar 2008 22:44:01 +0200, > > Aki Niemi wrote: > > > > > > > > > On ti, 2008-03-04 at 12:20 -0800, ext Eric Rescorla wrote: > > > > > Then I'd appreciate any suggestion to make it clearer. > > > > > > > > Explicitly state that in the case I described that it's permissible > > > > to deliver the same Etag in the first and third versions. > > > > > > Something like in S 5.3: > > > > > > The subscriber MUST be > > > prepared to receive a NOTIFY with any entity-tag value, including a > > > value that matches any previous value that the subscriber might have > > > seen. > > > > Yeah, I don't think that's at all clear. For all I know, that > > could mean the server is running in a VM and was rolled back. > > It could also mean the Lakers just fired Koby in order to make room in > their salary cap to hire me as their point guard.
Yes, precisely. It's not clearly written. > It just doesn't matter; the subscriber is not supposed to even attempt > to infer such a meaning from the entity-tag value. > > Perhaps you're looking for something like this: > > The entity-tag is an opaque token to the subscriber. The > subscriber MUST NOT attempt to infer any meaning from the value > beyond a simple reference, or assume a specific formatting. The > relationship between the current entity-tag and any future or > past entity-tags is undefined. But that's not true. You require that if value(A) != value(B), ETag(A) != ETag(B). that's not undefined at all. > Therein lies the problem. To make it unambiguous would mean we either > mandate different entity-tags for identical entities, or we mandate > identical entity-tags for identical entities. No, that's not true. I'm perfectly happy to have it be unambigous that you may or may not have identical etags for identical entities. What I'm not OK with is the current state in which it is not clear whether this is legal or not and so the subscriber doesn't know whether he can rely on it. I appreciate that you believe that the current text clearly allows both designs, but I don't. I think it can be interpreted either way (as either (1) allowing both designs or (2) prohibiting one). > But currently this is *intentionally* undefined. If my notifier > implements MD5 hash over the entity as the entity-tag value for event > package X, identical entities would indeed receive identical > entity-tags. That will work. > > But if my notifier implements a timestamp as the entity-tag value for > event package Y, identical entities would receive different entity-tags. > That will also work. > > Bottom line is, the subscriber doesn't care, and the notifier can do > what it wants. We require uniqueness of entity-tags as a friendly > suggestion not to shoot self in foot. If the notifier dishes out the > same entity-tag for different entities, it can cause the notifier to > suppress a NOTIFY that should have been sent. That's not a friendly reminder. It's a hard requirement of the spec. > If this is inline with how you think this should work, I can try to > sketch a paragraph or two into section 6.1 basically saying the above in > normative language. I'm fine with what you describe above, but what I'm looking for is to have you *explicitly* state that if there are two instances with the same value they MAY have the same etag, even if there was an intervening instance with a different value. Not MUST, MAY. And the reason I think this is important is that IMO, the current text can be interpreted as forbidding this. -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
