Subject: [Simple] Migration and client PA as a definitive authority.

From: "Brian Stucker" <[email-masked]>
Date: Fri, 28 Sep 2001 15:47:16 -0500

Question about presence migration. Still looking at it, and the new 03 draft
clears a lot of questions up, but one still remains for me...
 
How do we go about ensuring that a PUA that signals that it wishes to become
the PA for the presentity, by migrating the PA away
from the presence server, is the definitive source of the aggregated
presence information?
 
As I understand it, the PUAs feed presence fragments to the PA via the
REGISTER method, which a client UA shouldn't be receiving
as it's not a registrar. Therefore, if the client PA/PUA doesn't have a way
of getting the presence fragments from the other various
PUAs (at least not through SIP), should it be allowed to migrate the PA
function away from the presence server? I know we could signal
across devices using some means other than SIP, but looking at this as a
state agent handling state synchronization within an event
framework, shouldn't there be defined a method to use the same protocol for
this job (SIP) as a baseline mechanism?
 
I noticed in the documentation under the migration and forking sections text
that said that it was best for a network PA to do aggregation,
and I agree with that. How do we ensure that the aggregation is handled
correctly when the PA is no longer in the network?
 
Another question that I have regards what is really saved by migrating to a
client device? We still have to keep the presence server in the route
in order to detect migration back to the presence server from the client
PA/PUA. The notifications still have to travel through the presence server
because they must follow the same route as was established in the SUBSCRIBE.
So it seems that all we're saving is the aggregation piece, which
seems relatively simple to do from a centralized server.
 
The reason I bring the last bit up is because one way I was thinking the PUA
information could be dealt with is by making the presence server a
reflector of the information fed in by PUAs in registrations by way of
having the PA/PUA subscribe to itself at the presence server (which would
always be allowed, and this portion of the PA would not migrate). That way
the registrations cause a NOTIFY to be sent back to the migrated PA to
keep it in sync.
 
Does this make any sense, or am I seriously off in the weeds somewhere?
 
Thanks all,
 
Brian

---

From: "Robert Brown" <[email-masked]>
Date: Sat, 29 Sep 2001 18:11:57 -0700

Hey, if you're off in the weeds, I think I'm somewhere nearby :-)

Actually, I think REGISTER is only meant to be an example of one way an
implementer might want to publish presence to the PA.  You've hit on one
of the examples of why this isn't a great idea (and I agree).  A few
other reasons I don't like using REGISTER to publish presence: 1)
REGISTER is something you'll want to send pretty frequently unless you
have a very stable and static network, but you only need to send new
presence status when you actually have some new state; 2) there are only
so many ways you can overload REGISTER and complicate its semantics -
it's better IMHO just to invent a different method or do something out
of band; or do something tricky like have the PA subscribe to the PUA;
3) why should I be registered in order to publish presence?

IMHO subscribing to your own URI is an excellent way to keep track of
what your PA is telling people and keeping in synch.  We've done it for
non-SIP implementations and it works like a charm.

Anyway, that's just my $0.02.

- Rob

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: Friday, September 28, 2001 1:47 PM
To: simple
Subject: [Simple] Migration and client PA as a definitive authority.

Question about presence migration. Still looking at it, and the new 03
draft clears a lot of questions up, but one still remains for me...

How do we go about ensuring that a PUA that signals that it wishes to
become the PA for the presentity, by migrating the PA away

as it's not a registrar. Therefore, if the client PA/PUA doesn't have a
way of getting the presence fragments from the other various

framework, shouldn't there be defined a method to use the same protocol
for this job (SIP) as a baseline mechanism?

I noticed in the documentation under the migration and forking sections
text that said that it was best for a network PA to do aggregation,

Another question that I have regards what is really saved by migrating
to a client device? We still have to keep the presence server in the
route

in order to detect migration back to the presence server from the client
PA/PUA. The notifications still have to travel through the presence
server

because they must follow the same route as was established in the
SUBSCRIBE. So it seems that all we're saving is the aggregation piece,
which

The reason I bring the last bit up is because one way I was thinking the
PUA information could be dealt with is by making the presence server a

reflector of the information fed in by PUAs in registrations by way of
having the PA/PUA subscribe to itself at the presence server (which
would

always be allowed, and this portion of the PA would not migrate). That
way the registrations cause a NOTIFY to be sent back to the migrated PA
to

keep it in sync.

Thanks all,

Brian

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 2 Oct 2001 10:56:21 -0400

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Friday, September 28, 2001 4:47 PM
To: simple
Subject: [Simple] Migration and client PA as a definitive authority.

>Question about presence migration. Still looking at it, and the new 03
draft clears a lot 
>of questions up, but one still remains for me...
>
become the PA for 
>the presentity, by migrating the PA away
presence 
>information?

I took a stab at answering this in a separate thread:
http://mailman.dynamicsoft.com/pipermail/simple/2001-October/000844.html

The basic answer is that its a system level decision. I think that
eventually, it will be almost impossible to do this migration as the sources
of presence become large.

>As I understand it, the PUAs feed presence fragments to the PA via the
REGISTER method, 
>which a client UA shouldn't be receiving
>as it's not a registrar.

As Robert indicated, REGISTER is one way. The requirement for migrating is
that whatever the inputs to presence, a PUA have access to all of them. If
presence is effectively being fed to the presence server through
registrations from a single client, then the client also has complete
presence information.

>Therefore, if the client PA/PUA doesn't have a way of getting 
>the presence fragments from the other various
function away 
>from the presence server?

I say no.

>I know we could signal
state agent 
>handling state synchronization within an event
this job 
>(SIP) as a baseline mechanism?

In that case, you haven't really migrated at all, since the presence server
is still acting as a UA, but just for one subscription (from the PUA which
is know trying to act as a PA). I hadn't thought about doing this. It can be
done within the bounds of the protocol, but I suspect that the complexity
will buy you little.

>I noticed in the documentation under the migration and forking sections
text that said 
>that it was best for a network PA to do aggregation,
correctly when 
>the PA is no longer in the network?

You can't - which is why the spec says you shouldn't migrate the function
unless the PUA is sure its effectively the only source. 

>Another question that I have regards what is really saved by migrating to a
client 
>device? We still have to keep the presence server in the route
PA/PUA. The 
>notifications still have to travel through the presence server
SUBSCRIBE. So it seems 
>that all we're saving is the aggregation piece, which

No, you gain a lot in terms of fault tolerance. The presence server is now a
proxy, not a PA, which means it has no state and has a much better story for
fault tolerance. The overall system performance will also be a lot better.
You no longer have a centralized component managing subscriptions  - that
task is delegated out to clients. 

>The reason I bring the last bit up is because one way I was thinking the
PUA information 
>could be dealt with is by making the presence server a
having the PA/PUA 
>subscribe to itself at the presence server (which would
the 
>registrations cause a NOTIFY to be sent back to the migrated PA to
>keep it in sync.

Well, one can build a system that works this way. I'm not sure I want to go
into this in the specification, though. I'd rather not be migrating in cases
like this.

>Does this make any sense, or am I seriously off in the weeds somewhere?

No, it makes sense. Migration is an odd and complex topic. 

I welcome suggested text to help improve the clarity of this issue in the
specification.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com