Subject: RE: [Simple] Presence data model: devices

From: [email-masked]
Date: Wed, 21 Jul 2004 10:40:55 +0300

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 20.July.2004 21:39
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Simple] Presence data model: devices
> 
> 
> 
> 
> [email-masked] wrote:
> > 
> >>- A particular service maps to multiple devices, 
> >>forking-style. In that 
> >>case, the only advantage of having device tuples is that it 
> >>allows you 
> >>to enumerate the possible end points where your call might 
> >>end up. You 
> >>don't get a choice (although caller preferences might give 
> >>you input), 
> >>but you might get a hint. This, I believe, is however, much 
> >>better coded 
> >>as an enumeration of service capabilities as they are as 
> likely to be 
> >>constrained by the service offering as by the piece of plastic.
> > 
> > A GRUU guarantees where a request will end up.
>  > You are making the assumption that tuples for the same service
>  > will get merged.
> 
> Henning was enumerating the cases. This one case assumes the service 
> forks to multiple devices. If there is indeed to be presence 
> information 
> from each of those then yes, presumably it is being merged.
> 
> He covered the other cases as well.
> 
>  > I'm not making that assumption.
>  > My watchers will see 2 tuples for the same service if they get
>  > published by different PUAs. Each tuple will have a GRUU.
> 
> Then by the terminology we are using here, they are two different 
> services, not one.

I don't agree here. They are the same service. You can communicate with me in exactly the same fassion. Are you telling me that the IM on one device is not the same service as IM on another?

A service does not equal a device.

/Hisham

> 
>  > It will then be helpful to have device characteristics for that
>  > service and the GRUU will get you to that device.
> 
> Because they are separate services, we are back at the 
> degenerate case 
> where service = device, and "device characteristics" can be 
> associated 
> with the service.
> 
> 	Paul
> 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Jul 2004 14:08:24 -0400

[email-masked] wrote:
> I don't agree here. They are the same service.
 > You can communicate with me in exactly the same fassion.
 > Are you telling me that the IM on one device is not the
 > same service as IM on another?

Yes. You don't communicate in exactly the same fashion - you use a 
different address for one than the other.

Jonathan't data model explicitly states that the contact address serves 
as a UID for each service.

> A service does not equal a device.

Agreed.

As Jonathan has described, there can be a many:many relationship between 
services and devices. But when a service is associated with multiple 
devices it still must have a single address. Behind the scenes it may 
fork to one or the other of those devices, but to the watcher, to be a 
single service, it must have a single address.

If this were not the case, then either a tuple describing a service 
would require multiple contacts (not permitted) or else it would be 
necessary to have multiple tuples describing (aspects of) the same 
service. Jonathan's data model explicitly jetisons that approach.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Jul 2004 23:11:53 -0400

[email-masked] wrote:

> I don't agree here. They are the same service. You can communicate
> with me in exactly the same fassion. Are you telling me that the IM
> on one device is not the same service as IM on another?
> 

There may be yet another terminology confusion. Some of us (and I think 
the Data Model) use 'service' to refer to what one might also call a 
service instance, i.e., a particular reachable URI of a particular 
service type. Thus, the service [class] 'IM' might have many service 
instances, located on some varying number of devices, however defined. 
(Multiple instances could be on one device.)