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

From: "James Undery" <[email-masked]>
Date: Fri, 22 Feb 2002 14:24:30 -0000

Comments inline

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

> James Undery wrote:
> > 
> > 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-r
> equirement
> > 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.

Yes, if all you provide is online/offline info only, registration is
tolerable, however, once you've introduced presence descriptions such as
busy/on the phone/in a meeting then registration is totally
inappropriate. Presence is more dynamic in nature than registration.

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

I'd definately place the burden on the PA, which is exactly where it is
today in services like MSN (bad example I know), Yahoo, ICQ etc. The
semantics of registration aren't well defined if a location service
returns multiple contacts it's local policy that decided how a proxy
will try to contact them (or even redirect to them).

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

Well perhaps looking closer at the requirements and experimenting would
be a better project ;-)

> > What you're doing is a bad idea description params are far 
> more likely
> > 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 is exactly why this is a really bad idea. And the reason for using
480 or 486 responses. Just because you can get the same effect in SIP
from multiple mechanisms doesn't mean they are all equally good.

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

Well callerprefs are hints and presence is about hints so I guess the
two are related, unfortunately for the original poster this whole area
is pretty much undefined.

James

---

From: "Li Hua Tang" <[email-masked]>
Date: Mon, 25 Feb 2002 10:56:35 +0800

Please see my comments below.

Best regards,

Tang Lihua
Research Member, IBM China Research Lab.
Email:  [email-masked]

                    Paul Kyzivat                                                                          
                    <[email-masked]>             To:     Lamine Brahimi/Zurich/IBM@IBMCH              
                    Sent by:                         cc:     [email-masked]               
                    [email-masked]       Subject:     Re: [Simple] Handling unregistration of 
                    icsoft.com                        a Presentity in a presence  server                  

                    2002-02-22 09:58                                                                      

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

           Paul

Lamine Brahimi wrote:
>
> 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.

>Glad to hear that IBM is sponsoring such useful work.

> 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 quite agree this. Registrar is an important components of PS.

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

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

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

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

Brahimi, I guess you still use an old version of sip-events draft. In the
latest one
http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-03.txt, the
header "Subscription-Expires"  has been changed to "Subscription-State" and
the reason code is totally different. And I think you'd better use the
defined reason code to describe the status.

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

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

It's different. You know REGISTER and SUBSCRIBE requests are quite
different. A valid user is the one who can access to Presence Sevice. Even
if this valid user has unregistered, the PS must handle the subscription to
it. So if a SUBSCRIBE request is received to a invalid presentity (the PS
never hears about), 404 Not Found can be sent back. If the SUBSCRIBE
request is to a valid presentity but now it's not available, the PS must
handle it and send back NOTIFY acting as a PA. This NOTIFY requst has such
a header "Subscription-State: terminated;reason=deactivated", or
"Subscription-State: terminated;reason=probation;retry-after=100". It's
your preference to choose an impementation way.

>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
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple