Subject: AW: [Simple] reachibility information for services in current pr esence data model

From: Boehmer Bernhard Com Berlin <[email-masked]>
Date: Thu, 21 Apr 2005 10:11:42 +0200

Hi Paul,
the discussion convinced me that one would mess up the 
semantics of presence elements by such an approach. Concerning 
the verbosity of the XML I think sigcomp helps by ~60% and
hopefully this will convince mobile operators! 
			Thanks Bernhard

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Mittwoch, 20. April 2005 15:36
> An: Boehmer Bernhard Com Berlin
> Cc: Hyttfors, Per; [email-masked]'; [email-masked]
> Betreff: Re: [Simple] reachibility information for services 
> in current presence data model
> 
> 
> 
> 
> Boehmer Bernhard Com Berlin wrote:
> > 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".
> 
> 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 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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
> 
> > 		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