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

From: "James Undery" <[email-masked]>
Date: Fri, 22 Feb 2002 10:12:51 -0000

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
 
> > Lamine Brahimi wrote:

> > 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 .
> 
> 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.

I'd like to interject that using registration info for presence isn't a
good idea, the draft 
http://search.ietf.org/internet-drafts/draft-donovan-publish-requirement
s-01.txt provides the requirements of a better mechanism. 

> > 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.

What you're doing is a bad idea description params are far more likely
to change than registrations.

> > 
> > 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.
> 
> 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.

The subscriptions and the registrations are totally unrelated, sending a
NOTIFY with offline status seems the most sensible. (You can't send a
404 to a subscriber inplace of a NOTIFY and I'd contend your confusion
arises from you're abuse of registration.)

> > 
> > 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?
> 
> You shouldn't have to retain state about expired registrations.
> There shouldn't be any difference to the subscriber for the two cases.

Have I mentioned using registrations was a bad idea.

James

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Feb 2002 08:47:46 -0500

Comments below.

	Paul

> s-01.txt provides the requirements of a better mechanism.

I partially disagree. 

If I use registration to add, remove, or change contact information,
that ought to affect a presence server. It just doesn't make any sense
for a presence server to be advertising that I am present when in fact I
am unreachable. Also, the callerprefs draft introduces options on the
Contacts in registrations that clearly ought to be interrelated with
presence.

Of course you can place the burden on the UA to update both in a
consistent way, but that is simply asking for trouble. And it isn't
consistent with the semantics of registration, where independent UAs can
register with the same address of record and be merged automatically.
The discussions of merging presence documents went nowhere, so if you
want to permit that, using registration to update presence is better
defined.

That said, if you want to maintain a consistent registration, but want
to update nuances of your presence within the the envelope of that
registration, then some other mechanism might be appropriate.

Another observation - for somebody building something now, a draft of
*requirements* for publishing a presence document isn't very useful.

> to change than registrations.

Well, by definition the description param is part of the registration,
so it can't be more likely to change than the registration.

But I suppose your point is that the description of presence state is
more likely to change than is the contact address, so that if all you
want to change is presence state it might be better to use some
mechanism other than Contact parameters to represent it.

But that assumes that you don't need to change registration data at the
same time.

For example, suppose you want to change your presence state when you are
in a call, and suppose your registration initially contains:

   Contact: <sip:[email-masked]>;q=1
   Contact: <sip:[email-masked]>;q=.5

If all you want to do is say you are busy in a call, just updating a
presence document makes sense. But if you want to remain available for
urgent calls but not others, then (using callerprefs) you would need to
update your registration with:

   Contact: <sip:[email-masked]>;q=1;priority=urgent
   Contact: <sip:[email-masked]>;q=.5

and then at the end of the call you would need to restore your
registration to the original value. Updating only a presence document
wouldn't have the same effect, because it wouldn't affect calls that
ignore presence.

This just highlights the point that callerprefs and presence haven't
been aligned.