Subject: RE: [Simple] immediate notify issue

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2001 09:28:04 -0500

> -----Original Message-----
> From: James Undery [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 9:20 AM
> To: Nicolas Dramais
> Cc: Jonathan Rosenberg; SIMPLE LIST
> Subject: Re: [Simple] immediate notify issue
> 
> 
> 
> 
> On Wed, 28 Feb 2001, Nicolas Dramais wrote:
> 
> > 
> > 
> > Jonathan Rosenberg wrote:
> > 
> 
> > >
> > > 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.
> > 
> > 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 ?
> 
> 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.)

I also think it provides a nice clean separation between different
functions. Point one above that James makes is a benefit of this separation.

The biggie is that this is how CPIM works. CPIM was a compromise abstract
protocol, which all the camps agreed to adhere to. As a working group, we
are required by our charter to develop a protocol compliant to CPIM. I am
not about to go and question that consensus on CPIM, especially since there
are technical advantages in any case.

-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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2001 23:24:16 -0500

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Wednesday, February 28, 2001 12:04 PM
> To: Harald Alvestrand; Jonathan Rosenberg;
> [email-masked]
> Subject: RE: [Simple] immediate notify issue
> 
> 
> So, we have to reconcile several requirements:
> 
> 1) Allow fine grain control by the user -- this means that, even if we
> were to load a program on a server, that program would not be able to
> conclude without an explicit interaction with the user.
> 
> 2) Be able to do this in such a way that there is no difference being
> refusing a subscription and being offline, so as to not raise any
> suspicion.
> 
> 3) If possible, do this without creating an opening for a DoS attack.
> 
> 4) Be compatible with CPIM.
> 
> Combining requirements 1 and 2 implies that there must be an immediate
> response from the presence manager, and that this response 
> should be the
> same whether the subscription is "on hold" or "blocked", or 
> whether the
> user is offline. The requirements, however, leave us the 
> choice between
> two solutions: either just sending a 202 (no information provided), or
> sending a message state with some fake information, e.g. responding
> "offline" whether that is true or not.

No, there is only one choice. If a sucessful subscription generates a NOTIFY
with presence state, then a subscription that JUST generates a 202 is known
to be not successful or pending. This reveals information to the subscriber.

> 
> If we take the DoS attack into consideration, we get a further design
> requirement: that a single subscribe generates a single automatic
> response. This means that we should not send both a 202 and a Notify,
> because this is a "traffic multiplier." This means that only two
> solutions would be acceptable, just sending a 202, or sending 
> a 200 that
> contains an embedded notification. 

No, what you would do is the standard sip solution for this. A presence
server should be stateless for any unauthenticated requests. An
authenticated subscribe would generated the 202 and then the NOTIFY. An
unauthenticated subscribe generates only a 401, and no state is generated in
the system.

> 
> CPIM implies that simple agents must be ready to receive a 
> subscription
> acknowledgement that is essentially an empty 202, and that they will
> receive a Notify some time after. Some read the CPIM requirement as
> saying that we should send a Notify in all cases, whatever we know of
> the state of the user. I read it differently. The CPIM 
> requirement apply
> to the CPIM gateway, not to the end system. So, if we were to 
> just send
> a 202, we could very simply have the gateway send a fake Notify to the
> other party upon receipt of the 202, or maybe on some timer after the
> 202, if no notification was received before that. Alternatively, if we
> were to send a 200, the gateway could extract the notify 
> informationfrom
> inside the 200 and carry that as a Notify.

The requirement to send a NOTIFY with state of the user upon successful
subscription is not motivated by CPIM. Its a functional requirement of the
system. In current presence systems, if I subscribe and am accepted, I get
to know right away what the state of the presentity is. I shouldn't have to
wait for that state to change in order to get a notify.

Basically, I believe it is a functional requirement that a successful
subscription cause the current state of the presentity to be sent
immediately to the subscriber.

-Jonathan R.

---

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 05 Mar 2001 13:26:11 +0100

At 23:24 28/02/2001 -0500, Jonathan Rosenberg wrote:
>authenticated subscribe would generated the 202 and then the NOTIFY.

authenticated or authorized?

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Mar 2001 12:41:56 -0500

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Monday, March 05, 2001 7:26 AM
> To: Jonathan Rosenberg; 'Christian Huitema';

Sorry, let me try again:

The server should be stateless for UNAUTHENTICATED requests. An
authenticated,
but UNAUTHORIZED subscribe would generate the 202 and then a NOTIFY.

-Jonathan R.
---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 18 Mar 2001 23:53:00 -0500

> From: Hisham Khartabil [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 8:01 AM
> To: Jonathan Rosenberg; [email-masked]
> Hi,
> What about when the Presence Agent is located at the client 
> (ie: Presence
> Client).  If I subscribe directly to that presence client, 
> and that client
> is off line, then I know because I don't even get a response to my
> subscribe.  I guess nothing could be done about that besides 
> motivate the
> need for a presence server (Is that what we are trying to 
> motivate, or are
> we trying to motivate pushing login to peripherals?)

In general, you will need a server to handle the cases when the client is
offline. Pushing the PA functionality to the end devices only works when
those devices are available, and have knowledge of all the communications
means of the presentity.

-Jonathan R.

---