Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01

   From: Aki Niemi <aki.niemi@nokia.com>

   On ti, 2007-09-18 at 11:06 -0400, ext worley@dworley.hsd1.ma.comcast.net
   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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip