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

[Jonathan Rosenberg <[e-mail]>]

Paul Kyzivat wrote:

> 
> 
> Song, Youngsun wrote:
> 
>> 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?
> 
> 
> Looks like a bug to me.

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

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

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.

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

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
[e-mail]                     FAX:   [phone]
http://www.jdrosen.net                      PHONE: [phone]
http://www.dynamicsoft.com


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