Subject: RE: [Simple] 200 vs. 202

From: "Brian Stucker" <[email-masked]>
Date: Wed, 7 Nov 2001 03:35:22 -0600

Seems dangerous to allow the watcher to take NOTIFY messages that it didn't
get the 2xx response for. What is the watcher going to do if the
notifications that it receives don't mesh, ie.:

- one PA says a contact is online, the other says it's offline?
- a PA says the subscription is pending, and is an aggregator of the PUA's,
but another PA says the subscription is active, and is not an aggregator?

I think you need to have some sort of order of precedence for the watcher to
be able to process the notifications correctly. Before your order of
precedence rules were pretty simple: if the tags match, take it, otherwise
don't. Now, you've opened yourself up to all sorts of new complexities.

Hmmm... There's got to be a better way...

Regards,

Brian Stucker
Nortel Networks

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 1:58 AM
To: 'James Undery'; Robert Sparks; Jonathan Rosenberg; Stucker, Brian
[NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier
Lachlan'; 'adam.roach'; 'ext Paul Kyzivat'
Cc: 'simple'
Subject: RE: [Simple] 200 vs. 202

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Tuesday, November 06, 2001 11:06 AM
> To: 'Robert Sparks'; 'Jonathan Rosenberg'; 'Brian Stucker'; 'Moran Tim
> (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext
> Paul Kyzivat'
> Cc: 'simple'
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> > > > >  * 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.
> 
> 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).

That was my assumption as well. If you accept more than one NOTIFY, you
really have to refresh each individual subscription. The watcher would then
need to continue to compose aggregated presence documents throughout the
lifetime of the subscriptions.

Again, I prefer that the watcher not have to do that, but since I can't
guarantee that there won't be forking proxies, there doesn't seem to be a
clean way to get around it.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com