Subject: RE: [Simple] immediate notify issue

From: "Christian Huitema" <[email-masked]>
Date: Wed, 28 Feb 2001 09:04:17 -0800

> What the discussion seems to boil down to is that the model of having 
> subscriptions' fate being decided by the client whose 
> presence is being reported is not workable.

I beg to differ. There is working code today, used by millions of people
that proves that this model is workable -- an example being MSN
Messenger. It is in fact a major requirement of any IM system, that user
have the option to explicitly approve subscriptions on a case by case
basis.

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.

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. 

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.

Now, if CPIM is creating the problem, it is possibly something we want
to fix in CPIM. After all, the privacy requirements of APEX or PRIM
should not be very different from those of SIMPLE...

-- Christian Huitema

---

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

>have the option to explicitly approve subscriptions on a case by case

Christian,
you obviously know more than I about this example.
I would love to see you describe MSN Messenger's responses in the following
cases where a WATCHER subscribes to a PRESENTITY:

1) PRESENTITY is offline, and has said that anyone can watch him

2) PRESENTITY is offline, and has said that only a limited list, which does
    not include WATCHER, can watch him

3) PRESENTITY is online, and answers NO to a request for subscription

4) PRESENTITY is online, and answers YES to a request for subscription

5) PRESENTITY is online, but has left terminal unattended for an hour.

In particular, what does the WATCHER know, and when does he know it?

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