Subject: AW: [Simple] reachibility information for services in current pre sence data mo del

From: Boehmer Bernhard Com Berlin <[email-masked]>
Date: Tue, 5 Apr 2005 08:36:58 +0200

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

> -----Ursprüngliche Nachricht-----
> Von: Henning Schulzrinne [mailto:[email-masked]] 
> Gesendet: Freitag, 1. April 2005 15:36
> An: Boehmer Bernhard Com Berlin
> Cc: [email-masked]'
> Betreff: Re: [Simple] reachibility information for services 
> in current presence data mo del
> 
> 
> I doubt that anybody has the desire at this point to change PIDF in a 
> non-backward-compatible way. Can you spell out what kind of 
> information 
> you see as being duplicated unnecessarily across several <tuple> 
> elements? In the cases I can picture, things like prescaps 
> would likely 
> differ for each contact.
> 
> Boehmer Bernhard Com Berlin wrote:
> > Hi,
> > the current presence data model discusses nicely reachability
> > information. Maximum openess concerning the definition of
> > a service is maintained. However, in the actual definition 
> > of the <tuple> - being the legacy of pidf - reachability information
> > is restricted to one entry, the <contact> element. Thus, within
> > one <tuple> element the possibility that a service may be reachable
> > via different, e.g., addresses cannot be reflected. The only way I
> > see currently is to send two <tuple> elements with 
> basically the same
> > information but the <contact>/reachability information.
> > 
> >>From my perspective this introduces quite some redundancy 
> in the presence
> > doc (a point which is especially relevant for mobile networks) and 
> > is furthermore asymmetric to possibility to introduce 
> several device ids
> > into one <tuple> element (the latter, however, not being 
> made explicit
> > by the XML schema).
> > 
> > So, my question is: Have you once considered to add more 
> than one piece
> > of reachability information and you have rejected this 
> possibility or
> > do you share the view that this means should be introduced?
> > 			Regards Bernhard
> > 
> > ___________________________
> >  Dr. Bernhard Böhmer
> >  Systems Engineering
> >  Siemens AG Communications,
> >  Mobile Networks AS BD C
> >  Siemensdamm 50, Berlin
> >  Fon: +49-30-386-22756
> >  Mobile: +49-178-7700119
> > 
> > _______________________________________________
> > 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: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Apr 2005 09:02:27 -0400

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.