Subject: RE: [Simple] RPID: what does tuple-type really mean?

From: [email-masked]
Date: Tue, 1 Jun 2004 11:09:07 +0300

Some comments inline

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 01.June.2004 08:30
> To: Paul Kyzivat
> Cc: Simple WG; Niemi Aki (Nokia-M/Espoo); Henning Schulzrinne
> Subject: Re: [Simple] RPID: what does tuple-type really mean?
> 
> 
> 
> 
> Paul Kyzivat wrote:
> 
> > Jonathan,
> > 
> > I'm having misgivings about this change now. Devices have 
> somehow become 
> > 2nd class citizens.
> 
> Thats a fair characterization.
> 
> > Representing location information now becomes 
> > incredibly complicated. Either you have to replicate it in 
> each service 
> > that shares the device, or as you suggested to me, you put 
> it in one 
> > service tuple and cross reference it from others. But the 
> latter makes a 
> > mess of filtering - what if I filter out the tuple that 
> holds the device 
> > attributes and keep the one that cross references them?
> 
> A better solution would be to define <device> as a peer of 
> tuple. PIDF 
> allows the document to have things besides tuples. So, we could add 
> <device> and then have each <tuple> (which represent 
> services) refer to 
> that <device>. I think this would work well with filtering.

I don't see a big deal in duplicating location information here (for simplicity), but if it is for some, then what would be the properties (attributes and sub-elements) of the <device> element under the root <presence> element?

For filtering, we can either say that anything that is cross referenced is also selected by a filter that selects the element that is cross referencing, or mandate that a filter must explicitly select the <device> elements. I prefer the former.

> 
> > 
> > You say that a device has an address, a service doesn't. But from a 
> > practical perspective, a service that is hosted on only one 
> device has a 
> > location too - it is only distributed services that don't have well 
> > defined locations.
> 
> In the case you are talking about, its still the device that has the 
> property of location; its just that the device happens to 
> host a single 
> service. Whether or not a service is hosted on one device or 
> many doesnt 
> change the fact that location is a fundamental property of a device.

Agreed.

> 
> > 
> > If you want to make this kind of distinction, then I think 
> we must still 
> > have both device and service tuples, with cross references 
> between them. 
> > And while we are at it, it would then be convenient to 
> permit a single 
> > tuple to represent both when they are 1:1.
> 
> I think that introducing more options on how to represent things will 
> only further worsen our current situation.

I agree with Jonathan here and vote for service tuples with <device> elements inside, and forbidding the converse. I'm on the fence on cross referencing a <device> element that is directly under the root element. Are there any other properties of a device that needs to be shared amongst service tuples besides location information? If so, then it might be worth while cross referencing.

Regards,
Hisham

> 
>   Then, service tuples would
> > have contacts while device tuples wouldn't. And a device 
> tuple would 
> > have a location while a service tuple doesn't. But a device 
> with only 
> > one service can be represented with a combined tuple that 
> both a contact 
> > and a location.
> 
> This is not far from what I am proposing above, excepting I'm 
> using an 
> explicitly named <device> element and not introducing the 
> special case 
> for 1-1 mappings. We've already said that contact-less tuples are 
> presentities/in-person. How would we differentiate that from device?
> 
> Thanks,
> Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> 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, 01 Jun 2004 14:57:44 -0400

It might help to provide some examples for concreteness. Am I correct 
that there are two proposals on the table:

Proposal 1 - tuples only, with <device> label to hint at spatial 
correlation:

<presence>
   <tuple>
     <contact>sip:[email-masked]</contact>
     <device>17</device>
     <location>123 Main Street</location> (laptop, running some SIP client)
   </tuple>
   <tuple>
     <contact>h323:@laptop.my-domain.com</contact>
     <location>123 Main Street</location>
     <device>17</device> (same laptop, running NetMeeting)
   </tuple>
   <tuple>
     <contact>sip:[email-masked]</contact>
     <location>5 Elm Street</location> (home)
     <device>42</device>
   </tuple>
   <tuple>
     <contact>sip:[email-masked]</contact> (my proxy that hides all 
services; location could be either Elm or Main)
   </tuple>
</presence>

This seems pretty clear. If I dial the h323 URL, I can be pretty sure 
that I reach Alice at her Main Street location. The only drawback is 
that location information is replicated across tuples.

The other model would be similar, except that we pull out the location 
information into a <device> element:

<device id=17>
   <location>123 Main</location>
</device>