Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Tue, 13 Nov 2001 13:18:25 -0600

Good points, however, I would change the wording a little bit. It should be
up to the network whether or not it wants to send back a 300 to the client.
Forcing the client to fork seems too harsh a requirement. In the -03 draft
it's already stipulated that if there are multiple PA's representing a
presentity, that they MUST all have the same "picture" of the user's
presence. So in terms of what you're going to get back from any given PA, is
dealer's choice to the originating subscriber. It makes no difference.
Forking is just looking for which one is available the quickest, and nothing
more.

The proxy may not know which contacts are really PA's. All we've said is if
you want to be a PA, mark your contact using the caller preferences in your
registration. There are any number of other event packages that could lay
the same claim to including a methods="SUBSCRIBE" to identify the
willingness of the client to support some sort of subscription mechanism
(not just presence). This could cause forking to occur, but some (or none)
of the clients that got forked to support subscriptons to the presence event
package. Once again, sending back a 300 doesn't help us any.

If we leave the stake in the ground that presence information should not be
aggregated at the watcher, because policy is difficult at best to apply in
this situation, then we need to ensure one of two things:

- Making sure that there is one, and only one, PA (which is what ICQ, AOL,
MSN, etc. have been doing for a long time now).
- Making sure that if there is going to be more than one PA, either the
results are always aggregated somewhere in the network (for policy
decisions) or that all of the PA's are kept in sync (which is extremely
difficult to do).

If we solve either of these problems, not only do we solve the forking issue
with presence (because it either won't matter which response you get back,
or you'll only ever get one positive response). I'd argue it's far easier to
just say "there shall be only one" and build the architecture around that.
When you take into account that the SUBSCRIBE may get forked by an ignorant
proxy somewhere to clients that might not support SUBSCRIBE (405), or might
not support presence subscriptions (489), or might support presence
subscriptions, but don't want to authorize the user (202), or do want to
authorize the user (200) you run into a huge mess.

How much are we really buying ourselves by trying to allow multiple,
synchronized (as is in -03) PA's instead of simply having a single,
*logical* (not necessarily physical) PA in the network?

Cheers,

Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, November 13, 2001 12:49 PM
To: [email-masked]
Cc: 'Robert Sparks'; 'James Undery'; Jonathan Rosenberg; Stucker, Brian
[NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier
Lachlan'; 'simple'
Subject: Re: [Simple] 200 vs. 202

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

[email-masked] wrote:
> 
> > -----Original Message-----
> > From: Robert Sparks [mailto:[email-masked]]
> >
> > 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.
> 
> 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 18:13:16 -0500

below... Paul

[email-masked] wrote:
> 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.

Yeah, I know that. I should have explained my thinking better.

First, most of this discussion has come about because it is more or less
impossible to guarantee that two presence agents that appear as forking
alternatives are in fact functionally identical. So somebody (I think
Jonathan) proposed having the client merge the multiple Notifies that
might result from forking a subscribe.

My basic conclusion is that forking of subscribe just can't be made to
work right as things stand. The proposal to forbid forking in proxies
and push it back on the client via a redirect is intended to show one
way of making it work. That doesn't make it feasible or practical - the
reason you mention is a good argument of why it isn't.

But if forking can't work, then we are back to the requirement that
there either be only one PA, or else assume that if there are multiple
PAs then they are functionally equivalent and know exactly the same
state. It is unfortunate that we have no way to verify this, because it
will probably be the source of many bugs.

So, I believe I am agreeing with Brian.
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple