Subject: [Simple] Few questions on <draft-ietf-simple-presence-10.txt>

From: "Song, Youngsun" <[email-masked]>
Date: Mon, 1 Dec 2003 10:27:33 -0500

Hi,

In <draft-ietf-simple-presence-10.txt>, it mentions
"application/cpim-pidf+xml" as the presence data format content type. 
However in <draft-ietf-impp-cpim-pidf-08.txt>, it defines the presence
content type as "application/pidf+xml". Are these different types of content
types?

In Section 6.11.2, Migration, of <draft-ietf-simple-presence-10.txt>, it
seems that the migration is likely to be used to migrate subscriptions from
PA to PUAs. At the end of the section, it states "A PA SHOULD NOT migrate
the subscription if it is composing aggregated presence documents received
from multiple PUA." Since it is likely that there will be multiple PUAs
where the PA will act as State Agent for presence, it seems that the
subscription migration is not likely to occur. Is this right? I am trying to
understand the usage of migration for presence.

Thanks,
YoungSun

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2003 11:16:16 -0500

> content type as "application/pidf+xml". Are these different types of content

Looks like a bug to me.

> understand the usage of migration for presence.

There are many ways to implement this, and I'm not sure I understand 
what one you have in mind. One way that seems likely is for there to be 
a single PA acting on behalf of many presentities. For each presentity 
there may be zero, one, or more PUAs providing presence documents to be 
composed.

The decision the PA must make about migrating a subscription needs to be 
made independently for each presentity. If the PA is aggregating 
presence from multiple PUAs on behalf of a particular presentity, then 
it would be unwise to migrate the presence subscriptions to one of the 
PUAs. But it can be fine to do so for a presentity that has only one PUA 
reporting.

Clearly there are logistical problems if a second PUA comes online when 
subscriptions have been migrated to what had been the only PUA. Either 
that case needs to be avoided by configuration, or else it must be 
detected so that subscriptions can be migrated back to the PA.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Dec 2003 11:16:16 -0500

Looks like a bug to me.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Dec 2003 12:21:44 -0500

>> content type as "application/pidf+xml". Are these different types of 

Yup, and a big one. I'll be sure it gets fixed in authors 48.

>> understand the usage of migration for presence.

My general sense is that migration will not be terribly common. Over 
time, I would expect that the common case is multiple PUA, in which 
case migration is not possible. I think the system is overall easier 
to design and manage when presence is stored and processed in a 
single, reliable place.

> detected so that subscriptions can be migrated back to the PA.

I believe it can be detected if the second PUA uses PUBLISH. When the 
publish reaches the presence server for the domain, it would 
presumably forward the request to the UA that is currently acting as 
PA. If that UA cannot compose together presence documents, it can 
reject the PUBLISH (with a Retry-After), terminate all subscriptions, 
and unregster support for the SUBSCRIBE method. This would force 
migration back to the server.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 01 Dec 2003 12:21:44 -0500

-Jonathan R.