Subject: RE: [Simple] immediate notify issue

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2001 06:29:12 -0500

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Tuesday, February 27, 2001 1:23 PM
> To: James Undery
> Cc: Christian Huitema; Jonathan Rosenberg;
> [email-masked]
> Subject: Re: [Simple] immediate notify issue
> 
> 
> If I don't care about this property, is it still legal for me 
> to configure 
> my client to 403 the SUBSCRIBE?  (say my client will only 
> accept subscribes 
> from folks that have ever sent me a message or invite)

Yes. I think this is fine, but be warned that the client will know you have
rejected the subscription. Probably 600 is better than 403, but I have to
think about that.

James wrote:
> >Well there is a difference, a notify is required immediately 
> by the CPIM
> >draft if the subscribe is successful, a 202 I'd consider 
> success of a kind.
> >If you consider the three cases
> >
> >1 I subscribe get a 202 and no notify for the presentity
> >2 I subscribe get a 202 and a notify that they are offline
> >3 I subscribe get a 202 and a notify that they are online
> >
> >case 3 my subscription was accepted.
> >case 2 my subscription may not be accepted but I know the 
> presentity is
> >offline.
> >case 1 my subscription was rejected and I know the 
> presentity is online.
> >
> >In both cases the presentity did not want me to have 
> presence info I know
> >its presence state. Jonathan's suggestion fixes this so 
> "being offline" and
> >being rejected are identical as cases 1 and 2 become identical.

Thats it, exactly. The key is that the immediate notify contains presence
data which reveals little yet is also a valid piece of presence data that
they might get if the subscription was accepted.

Nicolas wrote:
> My thought is that a NOTIFY shall be used only to signify a 
> *change* in a
> presentity's communication status.
> I find it somehow misleading to use it to transport a 
> current, unmodified
> communications status as answer to a SUBSCRIBE.
> I'd rather prefer to specify in CPIM that setting the current 
> presence info in a
> response to a SUBSCRIBE is optional and that when done (e.g. 
> for IM independent
> Presence service) it eliminates the need for an immediate NOTIFY.

This is incorrect. The whole reason that notify's contain a full view of
state is that they make sense at any point in time. Its important to tell
the subscriber the state when the subscription is accepted. This is a
standard feature on existing presence systems.

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

---

From: Nicolas Dramais <[email-masked]>
Date: Wed, 28 Feb 2001 14:08:53 +0100

Jonathan Rosenberg wrote:

> the subscriber the state when the subscription is accepted.

Well, of course. This is not under question but what I really meant was : what
is the reason why, in the CPIM draft, we cannot use the body of the 200 OK to
insert the current state of the presentity when the subscription is accepted
(like was done in the draft-rosenberg-impp-presence-00.txt) instead of
mandating the use of immediate notify's for doing so ?
In the latter draft, a 6xx response with no body is returned in case the
subscription is rejected and when a change occurs in the state, notify's are
used to convey a full view of the new state.
What makes things different for the CPIM draft ?

Thanks in advance for your explanation,
Nicolas.

> This is a
> _______________________________________________
> simple mailing list
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: James Undery <[email-masked]>
Date: Wed, 28 Feb 2001 14:19:52 +0000 (GMT)

> What makes things different for the CPIM draft ?

There are all sorts of problems with the response containing the state
info. Firstly what if the contact in the subscribe is a different PUA, it
won't get the state. Secondly what if the subscription forks to multiple
presence servers, the subscribing client will only see the state from one
location. (There are probably other reasons I can't remember offhand
butthis should be enough.)

James Undery