Subject: RE: [Simple] 200 vs. 202

From: Robert Sparks <[email-masked]>
Date: Tue, 6 Nov 2001 10:46:35 -0500

> > >  * a subscriber SHOULD accept all NOTIFY requests generated
> > > by a particular
> > > subscription (i.e., not reject all but the one matching the 2xx to
> > > SUBSCRIBE), and then compose the presence data from each
> > > notification into a
> > > complete presence document
> >
> > This will cause the composed document to be different before
> > and after the first refresh (RR will prevent all but the
> > notifier whos 2xx we received from being refreshed).
> 
> Sorry, I am a bit slow and can't see why not. The NOTIFY will 
> follow the
> route set created from the SUBSCRIBE(?!), all proxies wishing 
> to record
> route will get the opportunity to add a record route header 
> to the NOTIFY as
> per normal.

The problem is not with the NOTIFY, its with the reSUBSCRIBE
that will refresh the subscription. That request will get to
exactly one of the notifiers.

RjS

---

From: "James Undery" <[email-masked]>
Date: Tue, 6 Nov 2001 16:06:14 -0000

> exactly one of the notifiers.

Well that's what I missed, I assumed each subscription would be refreshed
individually following the route-set (which at a minimum should be the
contact for that subscription).

James

---

From: [email-masked]
Date: Tue, 13 Nov 2001 11:20:05 -0600

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
>

Okay; apparently, I need to clarify this in the SUB/NOT draft:
each NOTIFY is intended to set up a unique route. Each route
corresponds to a subscription. Each subscription will be refreshed
individually.

If I send a SUBSCRIBE to B and it forks to B1 and B2, I'll get a
2xx from (say) B1. I will get a NOTIFY from B1 and B2. These
NOTIFY requests each set up a route. They also communicate the
subscription duration in the "Subscription-Expires" header.

When I go to refresh the subscriptions (which may or may not
occur at the same time), I will send *two* SUBSCRIBE messages:
one to B1 (using whatever route set B1's NOTIFY established),
and one to B2 (using whatever route set B2's NOTIFY established).

I'll try to make this less prone to misinterpretation for -02.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Nov 2001 13:49:13 -0500

With this developing interpretation, it seems that the 2xx response to
the original subscriber is of little significance - there can be a
variety of NOTIFYs coming back from different places, and all of them
may be important. This is both similar and different than a forked
INVITE:

- in the case of INVITE, while it is possible to end up with multiple
dialogs, in general the desire is for only one. A forking proxy will
typically try to prevent multiple dialogs by sending CANCELs after the
first 2xx response. Because of this, retransmission of the invite on
other forks isn't important.

- in the case of SUBSCRIBE, if it is forked, it is likely that each and
every fork may have something unique to contribute. Therefore it is
important that the normal efforts to achieve reliable delivery be
applied to each fork. Clearly this won't be the case if CANCELs are
sent, as they are for INVITE. (Whether this should happen seems to be an
open issue in bis5.) Even if CANCELs are not sent for extra forks after
receiving a 2xx, will the proxy continue to retransmit on the other
forks until it gets a response, or might a proxy simply cease
retransmissions on other legs once one leg has succeeded? If they are
dropped, some important participants may be missed. Even if
retransmissions are done, the original subscriber will not hear about
failures after an initial success, and so will not be aware of what
potentially important information may be missing.

If dealing with multiple PAs is an obligation of the subscribing client,
then I think that client needs to be given the tools to do it right. One
solution would be to require that if subscribe must be forked, that a
proxy simply return a 300 with the multiple Contacts rather than
attempting to do the fork itself. At least then it wouldn't get in the
way of doing a proper job.

	Paul

---

From: [email-masked]
Date: Tue, 13 Nov 2001 14:15:35 -0600

> From: Paul Kyzivat [mailto:[email-masked]]
>

Forking proxies -- the ones that have already been developed,
sold, delivered, and put in service -- don't know SUBSCRIBE from
INFO, MESSAGE, or FOO. We can't impose ex-post-facto requirements
on them.

/a