Subject: RE: [Simple] immediate notify issue

From: Rohan Mahy <[email-masked]>
Date: Wed, 28 Feb 2001 08:06:10 -0800

An immediate 403 is exactly the meaning I want to convey.  I *want* the 
other end to know that they have hit a brick wall.

There is another problem with a refected SUBSCRIBE spawning a 200 and a 
NOTIFY, is that this invites a clasic denial of service attack (where one 
message spawns multiple messages and consumes state, etc. etc.).  If I just 
blast out SUBSCRIBEs and don't respond to the NOTIFYs, the other agent will 
have to retransmit the NOTIFY many times before giving up.

thanks,
-rohan

At 03:29 AM 2/28/01, Jonathan Rosenberg wrote:

>
>
> > -----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: James Undery <[email-masked]>
Date: Wed, 28 Feb 2001 16:34:11 +0000 (GMT)

> other end to know that they have hit a brick wall.

Yes but this doesn't allow your friend you haven't spoken to in years to
contact you. Once they're on the banned list fine it works, but how do
friends get off the banned list.

> have to retransmit the NOTIFY many times before giving up.

This is something that could be tackled by returning 401s to the
subscription (I am loathed to mention authentication as it is SIP
authentication rather than the authentication surrounding subscription).

James Undery