I agree that the point we're discussing is largely a matter of providing a "beware" statement, except with the exception of a possible *solution* to the problem which I will mention at the bottom. But in any case, I don't see the need for agenda time at the metting to discuss this.
From: Aki Niemi <[EMAIL PROTECTED]> > The notifier cannot know what routing is in front of it, because it > cannot know what URIs might route to it. Then that's bad. How does the notifier then know which PIDF to pick in presence subscriptions? Especially if it's not a presence subscription. But seriously, is this proposal confined to presence events? I see no such text. In general, a SUBSCRIBE will fork, and the subscriber presumably knows how it wants to integrate the events it will receive from the various subscriptions, based on the semantics of its situation. I agree this kind of setup presents a problem. But I also think that what we're dealing with here is not that different from the web world. There are a lot of load balancing schemes that can be used with HTTP, which result in a GET ending up in different data centers in different parts of the world at different times. What's important to note there is that if the service that is accessed via this GET needs sessions and gives out cookies, then the backend system needs to be synchronized. Otherwise, the servers will be unaware of each others cookies, and the service won't work correctly. Similarly, the backend to the SIP notifiers needs a synchronized backend, otherwise, subnot-etags won't work. Naturally, the etags just like cookies can be constructed in such a way that they contain the necessary state. There's a hidden philosophical problem: People think of SIP routing as being like PSTN routing, where the caller sends the call to a number which designates one destination, or at least, a single device which has total knowledge of a small number of possible destinations. The caller knows the globally-recongized *name* of the destination-group, and every destination knows of and is coordinated with *every other possible destination*. Your HTTP model is similar; you assume the request will reach one of a set of servers that are co-adminstered. But the reality is that SIP routing can be like sending e-mail to a mailing list -- the sender doesn't know what the possible destinations are, and each destination doesn't know what all the destinations are either, because some of the routing can be done by agents that are not co-administered with either the sender or the destination. Now I think the first case is more common, but if we are going to design a general mechanism, it should not fail badly in practice in the second case. Getting back to possible solutions: Looking at section 6.1, I see '[An entity-tag] can have any value, except for "*".' (Let's correct that to 'An entity-tag can be any token, except for "*".') We can dodge the problem of uncoordinated notifiers by demanding that entity-tags have some minimum amount of randomness. E.g., if any group of coordinated notifiers picks a 64-bit random value, and the entity-tag is generated by making a 64-bit hash of that value with the event information, the chances of an etag-value collision in any single instance is 2^-64. One can easily encode a 64-bit value in 11 token characters using (modified) base64. Compare that to the 5-character values used as examples in the I-D. Though if we used 6 base64 characters, we would still have a 36-bit hash, which is probably good enough. Dale _______________________________________________ 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
