From: Aki Niemi <[EMAIL PROTECTED]> On ti, 2007-09-18 at 11:06 -0400, ext [EMAIL PROTECTED] wrote: > I have one technical issue (which is probably insoluble and can only > be documented) and a number of nits. > > * Section 4 specifies that a resource is identified by one or more > URIs. It seems to be implicit that one URI always identifies the same > resource. Without that, it would be difficult to use ETags > effectively, since ETags are only unique for a single resource.
Yes. > In the general case, the mapping from URIs to resources involves the > full complexity of SIP routing. This means that without additional > information, the subscriber does not know that request-URI that it > uses always maps into the same resource URI, and so has no absolute > guarantee that the space of ETags it is working with does not change > over time. The subscriber really need not know. It is the notifier's responsibility to keep the entity-tags unique across all of the insanely difficult SIP routing that it may deploy in front of it. The notifier cannot know what routing is in front of it, because it cannot know what URIs might route to it. > One assumes that all SUBSCRIBEs within a subscription are routed to > the same destination URI because the refresh SUBSCRIBEs are sent using > the route-set and contact. But a "resumed" subscription does not have > this protection. Correct. > It is not clear that there is any solution to these problems, and we > may only be able to document that the subscriber is responsible for > assuring that successive subscription requests are delivered to the > same resource. This isn't the subscriber's problem. Moreover, I really doubt that it is even feasible to build a system where a new subscription sent to the same AoR will randomly reach a different notifier instance that is in no way synchronized (as in state, entity-tag values, etc) with the other instances. There is no requirement that the SUBSCRIBE was sent to an "AoR" (even if that term was well-defined). It is trivial to build a system where a new subscription could go to a place that is much different than a previous subscription: sip:a.example.com forwards to sip:b.example.com - I think of this as "my call center". What I don't know is: sip:b.example.com uses time-of-day-based routing to forward to either sip:c1.example.com or sip:c2.example.com - My company has outsourced the call center to two different companies in in two different places, one for the day shift and one for the night shift. sip:c1.example.com parallel-forks to sip:d1a.example.com and sip:d1b.example.com - The day-shift call center workers are in several locations. sip:c2.example.com parallel-forks to sip:d2a.example.com and sip:d2b.example.com - And so are the night-shift call center workers. OK, now I send "SUBSCRIBE sip:a.example.com". Unless I know the details of the above routing, there's no way for me to know that the routing changes with time. Similarly, there's no way for the notifiers at d1a.example.com, d1b.example.com, d2a.example.com, and d2a.example.com to even know what notifiers they *might* have to synchronize with. Dale _______________________________________________ Sip mailing list http://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
