Subject: [Simple] Single / multiple tuples

From: Cnaan Oded <[email-masked]>
Date: Mon, 23 Jun 2003 09:29:06 +0300

Multiple tuples
---------------------
The problems mentioned in my previous email can be facilitated if separate
tuples are used to describe each service on the device, however, this causes
data duplication as the device information needs to repeat several times.
This problem can be solved by allowing a tuple to reference another tuple.
In this case, the service tuples would reference the device tuple so that
information is not repeated.
 
<presence>
  <!-- this tuple represents the device itself -->
  <!-- voice may also be considered as a separate service in a separate
tuple -->
  <tuple id="A1">
    <status>
      <basic>online</basic>
      <ext:voice-call>meeting</ext:voice-call> 
    </status>
    <contact>tel:+44-254-54462211</contact>
  </tuple>
 
  <tuple id="A2" device-ref="A1">
    <status>
      <im:im>busy</im:im>
    </status>
    <contact>im:[email-masked]</contact> 
  </tuple>
 
  <tuple id="A3" device-ref="A1">
    <status>
       <ext:ptt>offline</ext:ptt>
    </status>
    <contact>sip:[email-masked]</contact>
  </tuple>
</presence>
 
Note that most of the problems mentioned in the previous email (in
particular 2-5) are not solved by this new structuring and the solutions
suggested for a single tuple are still required.
 
Oded

---

From: [email-masked]
Date: Mon, 23 Jun 2003 17:01:10 +0300

Is geoloc considered device or media? It is a service, but not a device nor media.

/Hisham

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, June 23, 2003 4:50 PM
> To: Cnaan Oded
> Cc: [email-masked]
> Subject: Re: [Simple] Single / multiple tuples
> 
> 
> Oded,
> 
> As I commented in an earlier reply, you can't use multiple 
> contacts in a 
> single tuple, so your examples require some rework. However 
> you do bring 
> up something I want to ask about:
> 
> You talk about "IM, PTT and voice services". This concept of 
> "service" 
> has been bandied about here, but I have never been able to 
> get a clear 
> understanding of what it means. Can you define what you mean by 
> "service"? How is it different from "device" or "media"?
> 
> 	Paul
> 
> Cnaan Oded wrote:
> > Single tuple
> > ----------------
> > There are cases, where a PS would prefer using a single tuple to 
> > represent each device (or service) and specify all the services 
> > (devices) associated with it. For example, a tuple that 
> represents a 
> > mobile phone that has an IM, PTT and voice services.
> >  
> > This structure can be achieved using PIDF but the result 
> would be very 
> > hard to manage or even understand. Following the above example, the 
> > tuple may look like that:
> >  
> > <presence>
> >   <tuple id="A1">
> >     <status>
> >       <basic>online</basic>
> >       <im:im>busy</im:im>
> > There are several problem with this representation:
> > 1. There is no way to associate each of the services with 
> its matching 
> > contact. In other words, a UA cannot determine that the 
> second contact 
> > element should be used for PTT.
> > 2. There is no specification of a service name/ID. If a UA 
> is running 2 
> > IM clients (e.g., MSN and AOL), there is no way to 
> determine which one 
> > is specified by the im:im element. Moreover, any additional 
> information 
> > within the tuple cannot be associated with a specific service since 
> > there is no sufficient internal structuring.
> > 3. The PS and UA must have a-priori agreed on the 
> _extended_ elements 
> > and their meaning
> > 4. There is no way to determine if the tuple represents a 
> device or a 
> > service.
> > 5. There is no way to specify, when a tuple represents a 
> device, the 
> > device type (e.g., mobile phone)
> >  
> > Note that RPIDS, which adds some information elements to the PIDF 
> > structure, does not provide any solutions to these problems as well.
> >  
> > Several steps can be taken to fix these problems:
> > 1. The first problem can be solved in several ways. One alternative 
> > would be to create an internal tuple format that structures 
> the elements 
> > for each services.
> > 2. A collection of elements (representing a device/service) 
> would be 
> > given a name/ID that will be used for both UI 
> representation (e.g., "MSN 
> > Messenger") and parsing.
> > 3. This problem will probably not be completely solved and 
> integration 
> > will be required.
> > 4. Add an attribute to the tuple element that specifies what it 
> > represents. I understand that there is a big discussion on 
> "what a tuple 
> > is" but we can also define 2-3 values and leave it to 
> implementers to 
> > add their own.
> >  5. Add an attribute to the tuple element specifying the 
> device type. 
> > Again, some obvious values can be determined, leaving 
> implementers to 
> > add their own in the future.
> >  
> > Oded
> 
> 
> _______________________________________________
> 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: [email-masked]
Date: Tue, 24 Jun 2003 12:55:53 +0300

Service to me means something that an operator can offer (as part of a package) and charge for. This is what I meant when I suggested that geoloc is a service.

In technical terms, I don't know what a service is either.

One comment inline...

> Sent: Tuesday, June 24, 2003 1:32 AM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]; [email-masked]
> [email-masked] wrote:
> I agree it probably isn't either a device or media, but it is an 
> attribute. It happens that "device" and "media" are 
> attributes that some 
> people find especially interesting and want to single out as 
> important 
> for deriving views. Geoloc probably isn't of as great special 
> interest.
> 
> In principle, I suppose you might consider clustering or 
> "pivoting" data 
> by geoloc, 

Geoloc could be a tuple on its own, just identifying the location of the principal (principal is a more appropriate word here than presentity). Nothing to do with clustering.

Regards,
Hisham

> in the same sense that you might do so by media. 
> But it would 
> be less useful. If I cluster by media I can at least decide if it is 
> useful to attempt to contact using that media (with the AOR as 
> communication address). With luck, the devices that support 
> that media 
> will be tried. But if I cluster by geoloc, while I can decide to call 
> you based on the reported location, it will only be effective 
> if there 
> is a unique contact address for each reported location. If 
> you have two 
> geoloc entries, one saying you are in Boston, and another 
> saying you are 
> in Paris, both giving only your AOR, what should I do if I 
> only want to 
> talk to you in Boston?
> 
> I'm still trying to find out what a service is. You suggest 
> that geoloc 
> is a service. What do you mean by that? Is it something that is 
> available because the user that owns the presentity 
> contracted specially 
> for it? Or is it some kind of application a watcher uses that cares 
> about this information?
> 
> 	Paul
> 
>

---

From: [email-masked]
Date: Tue, 24 Jun 2003 12:55:53 +0300

One comment inline...

Regards,
Hisham