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

From: "Hyttfors, Per" <[email-masked]>
Date: Thu, 7 Apr 2005 12:26:31 +0200

I hope that several devices running the same service for the same person
will publish the same service URI representing an address-of-record with
all the individual service addresses for each device.

But the conversation between Boehmer Bernhard and Henning Schulzrinne
made me think and realize that maybe there is a use case where you
actually would have a person with several devices running the same
service publishing different service addresses. Hence, it would maybe be
beneficial from a watcher's standpoint for the presence server (running
some sort of composition policy) to be able to express several service
addresses for the same service and maybe to express which device has
which service address without needing to duplicate the whole service
tuple. But I won't fight over this since it sounds like people don't see
this as a likely problem.

/Per

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

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

Hisham

On Apr 6, 2005, at 4:54 PM, Hyttfors, Per wrote:

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Apr 2005 10:57:44 -0400

The *point* of publishing multiple tuples in presence is because you 
want the watcher to make the choice. And for the watcher to do so you 
must give him some basis on which to make that choice. But if all the 
tuples are identical except for the contact, then there is no basis for 
the choice.

In this case I think it is preferable to publish a single tuple with a 
single contact, where requests sent to that contact try any or all of 
the actual services based on presentity logic. Often that can be 
achieved simply by merging the tuples into one with the AoR as the contact.

You *may* of course publish all those tuples that differ only in 
contact, and leave the decision up to the watcher. But then you must 
accept that you have no control over which gets tried. As a result, your 
watchers may be annoyed with you.

I'm not seeing much value in adding a second way to represent a poor use 
case. I think you would be better off figuring out what criteria would 
allow the watchers to make an informed choice, and publishing that so 
the tuples *aren't* identical.

	Paul

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 7 Apr 2005 17:38:42 +0200

I agree with Paul here. If you possess multiple devices running the 
same service and each service publishes identical presence info except 
for the contact, then the ideal thing is for your compositor to merge 
those tuples and populate the contact element with your AoR.

Regards,
Hisham

On Apr 7, 2005, at 4:57 PM, Paul Kyzivat wrote:

> tuples are identical except for the contact, then there is no basis 
> for the choice.
>
> accept that you have no control over which gets tried. As a result, 
> your watchers may be annoyed with you.
>
> I'm not seeing much value in adding a second way to represent a poor 
> use case. I think you would be better off figuring out what criteria 
> would allow the watchers to make an informed choice, and publishing 
> that so the tuples *aren't* identical.
>
> 	Paul
>
> Hyttfors, Per wrote:
>> From: Hisham Khartabil [mailto:[email-masked]] Sent: 
>> onsdag den 6 april 2005 19:02
>> To: Hyttfors, Per
>>>> 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
>>>
>>>> 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)
>>>
>>> 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 
>>>>> 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,
>>>
>>>>
>>>> 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
>>>
>>>> to us storing your name and address for above stated purpose, 
>>>> please notify the sender promptly. Also, if you are not the 
>>>> intended
>>>
>>> recipient
>>>