Subject: [Simple] Handling unregistration of a Presentity in a presence server

From: "Lamine Brahimi" <[email-masked]>
Date: Thu, 21 Feb 2002 19:15:06 +0100

Dear all,

I'm a Student doing his Diploma Thesis at IBM and I'm writing a presence
server for handling NOTIFY and SUBSCRIBE requests.
The presentity updates its presence info via a REGISTER method to the
presence Server with a description param.
For the moment  the presence server does not act as a registrar. We do not
need it. It only generates notifications of changes to watchers on behalf
of a presentity .
We do not use Proxys.

I have three questions:

1) I think that only one Contact header should be present in the REGISTER
request with the desired description param. Is it OK? Otherwise can you
tell me what is the benefit of having multiple Contact headers.

2) suppose a presentity does not refresh its Registration to the server and
timeout occurs. What should the Presence Server send to the unregistered
presentity's watchers ?
Do we NOTIFY  watchers for example  with an "offline" or whatever
convenient state or it is not worth sending a NOTIFY and in this case send
a 404 (NOT FOUND) or possibly a NOTIFY with Subscription-Expires=0;reason
="presentity does not exist" when receiving
SUBSCRIPTION/SUBSCRIPTION-refresh for that unregistered presentity.

3)As a consequence, What is the difference when  we receive a SUBSCRIBE to
a presentity that has unregistered (do we need to keep trace that it has
been registered one time before ?) and a SUBSCRIBE to a presentity the
presence server never heard about. Does the presence server have to send a
404 (NOT FOUND) for both?

Regards,
Lamine.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Feb 2002 20:58:13 -0500

I'm not the expert, but I will offer an opinion. See below.

	Paul

> server for handling NOTIFY and SUBSCRIBE requests.

Glad to hear that IBM is sponsoring such useful work.

> need it. It only generates notifications of changes to watchers on behalf

Using REGISTER but not acting as a registrar seems to be cheating.
You can presumably get away with it for testing, but it would seem
unwise to ship something like that.

I think either you should integrate your presence server with your
registrar, or else you should update your presence info some other way.

> We do not use Proxys.

Really? I suppose this is why you don't need a registrar!
So are your clients required to use SUBSCRIBE to learn where to send?
How do they know where to send the SUBSCRIBE? Normally I would
expect that would find the presence server via a proxy.

If this is really true, then you could claim that your presence
server really is a registrar, but there just aren't any proxies
around to use the results. 
(A bogus argument but impossible to disprove.)

> tell me what is the benefit of having multiple Contact headers.

The benefit is when you have multiple points at which your address
of record may be reached. E.g. an office phone, home phone, cell phone.

Using REGISTER, it might be unusual for these to be registered
in the same REGISTER message, but it is legal. More likely for this
example would be for each to send separate REGISTER messages.
In that case you are expected to aggregate them when reporting
presence.

It is also permissible to register different kinds of URLs - e.g.
a sip address and a mailto address. Of course the mailto address
might not be of much use to your presence clients.

> SUBSCRIPTION/SUBSCRIPTION-refresh for that unregistered presentity.

I believe you are expected to send a NOTIFY to subscribers when
the registration expires. You might be able to avoid this by
controlling the expiration time of the subscriptions so that they
never extend beyond the expiration of the registration, but that
doesn't sound like a good idea.

> 404 (NOT FOUND) for both?

You shouldn't have to retain state about expired registrations.
There shouldn't be any difference to the subscriber for the two cases.

> 
> Regards,
> Lamine.
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple