Subject: RE: AW: [Simple] reachibility information for services in current presence data model

From: "Hyttfors, Per" <[email-masked]>
Date: Wed, 6 Apr 2005 16:54:50 +0200

The problem I see is that the current presence data model doesn't allow
for such "service composition policy" without having to define a new
format that can describe one service reachable through serveral
published addresses.

/Per

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: onsdag den 6 april 2005 16:32
To: Hyttfors, Per
Cc: [email-masked]
Subject: Re: AW: [Simple] reachibility information for services in
current presence data model

Hyttfors, Per wrote:
> Hello,
> 
> Lets say that the same person would have several devices with the same

> service running on all of them (lets say a telephone service) but with

> different service contact addresses (telephone numbers). Each device 
> will have its own Presence User Agent that publish its part of the 
> presence information. Would this scenario require that the NOTIFY that

> is sent to a watcher with the overall presence information of that 
> person would have to contain several <tuples> with different contact 
> addresses but with the same duplicated service information? (in the 
> case that the service is the exact same one for all devices)

This is a function of how the multiple sources of presence information 
are composed by the presence server. Simply making a union of all the 
tuples (which is what you ask about) is one simple approach, because it 
requires no understanding on the part of the part of the presence 
server. But it is clear that people would like to have more intelligent 
composition policies. So far we have deferred actually defining such 
intelligent composition policies just because it is hard and we want to 
get something out. But it is entirely permissible to implement such a 
compostion policy even in the absence of a standard.

	Paul

> /Per
> 
> 
> Henning Schulzrinne wrote:
> 
>>Unless there is some significant difference between services, you
>>wouldn't publish multiple contact addresses for it. Thus
>>
>><tuple>
>>   ... description ...
>>   sip:foo@somewhere
>>   sip:bar@example
>>   sip:123@whoknows
>></tuple>
>>
>>makes very little sense - why publish three URIs that the observer has
>>no way of distinguishing? If there's no annotation, the user can only 
>>throw darts and pick one.
>>
>>With the possible exception of having both a "tel" and SIP URI that
>>reach the same device, I see little practical use for your
description,
> 
> 
>>but maybe I'm misunderstanding your use case.
>>
>>Boehmer Bernhard Com Berlin wrote:
>>
>>>Hi Henning,
>>>my assumption is that a user has a certain service available at 
>>>different locations (devices, agents, etc.) each identified by 
>>>different contact addresses. The user wants to publish all these 
>>>contact addresses for this service. Together with the contact 
>>>information, however, (s)he also publishes also a bunch of other 
>>>information about this service. Due to the fact that only one contact

>>>is possible in <tuple>, my current understanding is that the user has
>>
> to publish
> 
>>>multiple tuples indicating the different contacts but *duplicating* 
>>>the other service information. This information, therefore, seems to 
>>>be doubled. I would like to avoid this redundancy somehow.
>>>
>>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Per Hyttfors
> ___________________________________________________________ 
> Development Engineer - Messaging Application Development 
> Sony Ericsson Mobile Communications AB 
> SE-221 88 Lund, Sweden 
> +46 46 2126534
> [email-masked]
> ___________________________________________________________ 
> The information in this email, and attachment(s) thereto, is strictly
> confidential and may be legally privileged. It is intended solely for
> the named recipient(s), and access to this e-mail, or any
attachment(s)
> thereto, by anyone else is unauthorized. Violations hereof may result
in
> legal actions. Any attachment(s) to this e-mail has been checked for
> viruses, but please rely on your own virus-checker and procedures. If
> you contact us by e-mail, we will store your name and address to
> facilitate communications in the matter concerned. If you do not
consent
> to us storing your name and address for above stated purpose, please
> notify the sender promptly. Also, if you are not the intended
recipient
> please inform the sender by replying to this transmission, and delete
> the e-mail, its attachment(s), and any copies of it without,
disclosing
> it.
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 6 Apr 2005 19:01:53 +0200

Are you asking for multiple <contact> elements per tuple?

Hisham

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Apr 2005 12:55:19 -0400

I never answered this.

If the intelligent composition policy is to reduce this to one tuple, it 
must also reduce it to one contact address. Sometimes this could be the 
AoR. If that doesn't work, then it may have to create an address, 
serviced by an intermediary, that does the job. If you can't do that, 
then don't do the composition.

I think maybe you are looking at the intelligent composition as just a 
data compression scheme. While it may have that effect, that isn't 
really its purpose. If all you care about is the size of the document, 
use compression.

	Paul