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

From: Boehmer Bernhard Com Berlin <[email-masked]>
Date: Wed, 20 Apr 2005 09:05:47 +0200

Hi,
wasn't able to join the thread for a while...
I cannot follow the view that the described use case is poor.
For me it's quite plausible that a user wants to select a subset of
his/her devices being available for a specific service. So, if I'm in 
a meeting I would like to make clear to the world that my device I'm
carrying in the meeting is available for IM but not for voice. So, one
way to do that would be to publish the tuple for IM indicating "open"
and the tuple for voice (what ever this means in IETF SIMPLE terms) indicating
"closed". The PS then may have to handle voice tuples from different sources 
all indicating "open" or "closed" for this service. For IM the same. But 
merging all voice tuples with "open" by using an AOR obviously isn't possible.
This means that all voice tuples with value "open" have to be concatenated in 
the raw presence doc and hence in some of the notified ones. This is certainly
possible but for mobile networks there are already quite heavy discussions on the
resulting traffic in terms of number of messages and of number of bytes.
So, a more effective way to combine this information would be helpful. Using 
compression helps a bit but a too generous handling of data redundancy may outweight
the effects of compression.
		Regards Bernhard

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Im Auftrag von Paul Kyzivat
> Gesendet: Donnerstag, 7. April 2005 16:58
> An: Hyttfors, Per
> Cc: [email-masked]
> Betreff: Re: AW: [Simple] reachibility information for 
> services in current presence data model
> 
> 
> 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
> 
> Hyttfors, Per wrote:
> > 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
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Apr 2005 09:36:11 -0400

Boehmer Bernhard Com Berlin wrote:
> "closed".

There is your problem. You are immediately faced with having multiple 
tuples with the same contact address. And semantically its complicated too.

A better way to do this is to have each device publish a single tuple 
describing the capabilities it has available. So your portable device 
sometimes indicates it is available for both voice and IM, but when in a 
meeting it changes this to indicate it is still available, but only for IM.

> The PS then may have to handle voice tuples from different sources 

You shouldn't be merging them unless you want the watcher to perceive 
them as one thing, which includes having one address. If there are 
multiple addresses then it isn't one thing.

> the effects of compression.

I don't agree with screwing up the semantics in the name of providing a 
questionable form of compression.

Simple partial notification will probably resolve most of the problem in 
this case, and sigcomp can help a lot too.

	Paul