Subject: [Simple] Notifier Migration Clarification

From: "Ngo, Dai (c)" <[email-masked]>
Date: Tue, 04 Sep 2001 20:25:14 +0000

All,

In section 5.12 "State Agents and Notifier Migration" of
draft-ietf-simple-presence-02.txt it says, "The presence server MAY migrate
the subscription if, for a given address of record, there is one, and only
one registered contact that indicates explicit support for the SUBSCRIBE
method."

What's the behavior of the presence server if there are multiple registered
contacts which explicitly support for the SUBSCRIBE method?

Thanks.

-- Dai

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 4 Sep 2001 18:39:09 -0400

-----Original Message-----
From: Ngo, Dai (c) [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 4:25 PM
To: [email-masked]
Subject: [Simple] Notifier Migration Clarification

>In section 5.12 "State Agents and Notifier Migration" of
draft-ietf-simple-presence-02.txt 
>it says, "The presence server MAY migrate the subscription if, for a given
address of 
>record, there is one, and only one registered contact that indicates
explicit support for 
>the SUBSCRIBE method."
contacts which 
>explicitly support for the SUBSCRIBE method?

It can't migrate the PA function.

-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

---

From: "Ngo, Dai (c)" <[email-masked]>
Date: Fri, 14 Sep 2001 20:40:26 +0000

Does this seem inflexible to you? We allow (serial/parallel) forking for
SUBSCRIBE, why not for this?

-- Dai

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 5:39 PM
To: Ngo, Dai (c); [email-masked]
Subject: RE: [Simple] Notifier Migration Clarification

-----Original Message-----
From: Ngo, Dai (c) [mailto:[email-masked]]
Sent: Tuesday, September 04, 2001 4:25 PM
To: [email-masked]
Subject: [Simple] Notifier Migration Clarification

address of 
explicit support for 
contacts which 

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Sep 2001 08:09:54 -0400

-----Original Message-----
>Sent: Friday, September 14, 2001 4:40 PM
>To: 'Jonathan Rosenberg'; [email-masked]
SUBSCRIBE, why 
>not for this? 

We do allow SUBSCRIBE to fork, but the spec only allows one of them to
proceed (the one whose 200 OK went to the subscriber). So, I don't mind
changing the text to allow it to fork the SUBSCRIBE in the migration case,
but you should recognize that the effect will be the same - only one of the
forked SUBSCRIBEs will actually be used.

The issue is one of aggregation. Consider a presentity whose presence is
based on the aggregation of presence state from a phone and a PC
application. The question is: how performs the aggregation of that state? I
have argued that the aggregation of presence state is highly policy
dependent, and can only be done properly by an entity in the domain of the
presentity. Thereofre, it makes sense for a server to handle the
subscription, and for it to generate an aggregate presence document that
combines the state of the phone and the PC. If the phone and PC were to each
act as presence agents, both would send notifications of their individual
states to the subscribers. Then, the role of aggregation would lie with the
subscriber. I don't think it belongs there for user presence.

So, forking of subscribe to independent devices, each of which knows its own
presence, is not a good thing. Forking a subscribe to a set of elements,
each of which knows the full presence state of the presentity, is just fine
and perfectly reasonable.

So, my proposal would be this:

1. I add text which says that a PUA only indicate support for SUBSCRIBE in
its registration if it is certain that it has full knowledge of the presence
state of the presentity (although I have no idea how it would know this in
general)

2. migrations are allowed when multiple contacts have registered indicating
support for subscribe.

OK?

-Jonathan R.

-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2001 5:39 PM 
To: Ngo, Dai (c); [email-masked] 
Subject: RE: [Simple] Notifier Migration Clarification 

-----Original Message----- 
From: Ngo, Dai (c) [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2001 4:25 PM 
To: [email-masked] 
Subject: [Simple] Notifier Migration Clarification 

address of 
explicit support for 

contacts which 

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Sep 2001 15:58:38 -0400

Since no one objected, I have made this change.

-Jonathan R.

---

> From: Jonathan Rosenberg 
> Sent: Tuesday, September 18, 2001 8:10 AM
> To: 'Ngo, Dai (c)'; Jonathan Rosenberg; [email-masked]
> >Does this seem inflexible to you? We allow (serial/parallel) 
> forking for SUBSCRIBE, why 
> >not for this? 
> >-- Dai 
> 
> We do allow SUBSCRIBE to fork, but the spec only allows one 
> of them to proceed (the one whose 200 OK went to the 
> subscriber). So, I don't mind changing the text to allow it 
> to fork the SUBSCRIBE in the migration case, but you should 
> recognize that the effect will be the same - only one of the 
> The issue is one of aggregation. Consider a presentity whose 
> presence is based on the aggregation of presence state from a 
> phone and a PC application. The question is: how performs the 
> aggregation of that state? I have argued that the aggregation 
> of presence state is highly policy dependent, and can only be 
> done properly by an entity in the domain of the presentity. 
> Thereofre, it makes sense for a server to handle the 
> subscription, and for it to generate an aggregate presence 
> document that combines the state of the phone and the PC. If 
> the phone and PC were to each act as presence agents, both 
> would send notifications of their individual states to the 
> subscribers. Then, the role of aggregation would lie with the 
> So, forking of subscribe to independent devices, each of 
> which knows its own presence, is not a good thing. Forking a 
> subscribe to a set of elements, each of which knows the full 
> presence state of the presentity, is just fine and perfectly 
> reasonable.
> 
> 1. I add text which says that a PUA only indicate support for 
> SUBSCRIBE in its registration if it is certain that it has 
> full knowledge of the presence state of the presentity 
> (although I have no idea how it would know this in general)
> 
> 2. migrations are allowed when multiple contacts have 
> registered indicating support for subscribe.
> 
> OK?
> 
> -Jonathan R.
> 
> 
>