Subject: RE: [Simple] Tuple references and device coupling

From: [email-masked]
Date: Thu, 3 Apr 2003 10:47:50 +0300

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, April 03, 2003 3:59 AM
> To: Ben Campbell
> Cc: Rosen, Brian; Niemi Aki (NMP/Helsinki); [email-masked];
> Sean Olson; Jonathan Rosenberg; Simple WG
> Subject: Re: [Simple] Tuple references and device coupling
> 
> 
> I think I am on the same page with Ben.
> 
> Frankly I am mystified about what a "service" is. From the examples I 
> see people using, it must be something like a medium, such as 
> "voice", 
> or IM.
> 
> But representing things this way causes trouble when a single 
> device can 
> support more than one medium or service. Suppose I have a device that 
> supports voice and video. Do I have:
> - one voice+video service represented as a single
>    tuple with one contact
> - one voice service and one video service,
>    each with a tuple and each with identical contact addresses
> - one voice service and one video service,
>    each with a tuple, and with different contact addresses
> - a voice service, a video service, and a voice+video service
> - ...

A tuple represents a service (communcation medium), the contact address represents the device where that service is running. How does that sound? If I choose not to include a contact, then I'm just publishing that I'm available for that service.

A copositor will have to combine tuples representing the same service (medium) that don't have contact addresses and possibly remove them completely if there is a tuple with a contact.

> 
> I think of a tuple that has a contact as describing a device.

Jonathan's contact proposal suggests that a contact represents a service on a device.

What does a tuple represent when a device does not have any services? 

> In RPIDS we have a way to describe a large number of attributes, 
> including media type, about that device. A device is a tangible thing 
> that is clearly distinguished by its contact address, so this makes 
> sense to me.
> 
> Services seem much less tangible. I think different people 
> will look at 
> the same collection of stuff and view it as services in 
> different ways.

We can stop using the word service and use communication mean (or medium or capability) if that disambiguates things.

Regards,
Hisham

> If all you care about is voice, then all the tuples that 
> support voice 
> represent the voice service of the presentity. If you are 
> interested in 
> video conferencing, then all the tuples supporting 
> voice+video represent 
> a useful service to you. If you are deaf then maybe all the 
> tuples that 
> support voice are of more interest to you as a service.
> 
> If we start imposing arbitrary mappings of capabilities into service 
> groupings then I think we are sure to run into 
> interoperability problems 
> unless we also set out to standardize all the different kinds of 
> services. I think this would be a bad thing.
> 
> 	Paul
> 
> BTW - Sorry I haven't been participating more. I have been both busy 
> with other things and struggling to catch up from the flood of email 
> over the last month. I'm still 400 messages behind and just cherry 
> picking what is there.
> 
> Ben Campbell wrote:
> > 
> > I think you _can_ make this interoperable without too much 
> difficulty.
> > Say your (that is, Brian's) service returns a single tuple, with a
> > single contact URI. That tuple is valid for IM (among other 
> things.). If
> > I want to IM you, I send an IM to the contact in the tuple. 
> Presumably
> > your SIP routing mesh takes care of getting it to the right place.
> > 
> >  Jonathan's service returns a bunch of IM tuples, each one with a
> > different URI. Lets further assume, for the sake of 
> example, that each
> > of these URIs represents a device contact for some device 
> of his. I can
> > send an IM directly to that device without going through a proxy.
> > 
> > Now, lets assume _my_ watcher simply expects one _or_more_ 
> tuples for
> > IM. It doesn't have any idea whether a given tuple 
> represents a single
> > device, or a SIP proxy, or whatever. The only important 
> thing is it can
> > assume that for an open IM tuple, it has a high chance of 
> being able to
> > get an IM to the target user by sending it to the contact URI. It
> > _could_ present multiple choices to me, or it could simply 
> tell me that
> > both Brian and Jonathan are available via IM, and 
> automatically choose
> > the best tuple to use. If there is only one such tuple, 
> that choice is
> > trivial. If there is a bunch of tuples, then it can pick 
> the best one
> > based on some sense of "most present", explicit priority 
> values, or some
> > local policy applied to the RPIDS attributes.
> > 
> > So, here I think I am proposing that a tuple represents a set of
> > availability and communication type attributes 
> _associated_with_a_URI_.
> > Whether that URI represents a service, or a device, or 
> whatever is not
> > relevant to the watcher.
> 
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Apr 2003 22:09:07 -0500

> A tuple represents a service (communcation medium), the contact address represents the device where that service is running. How does that sound? If I choose not to include a contact, then I'm just…

That doesn't sound too good to me. The problem is still with "service". 
You have now slipped in a definition that a service is a communication 
medium. Is that what others think a service is?

As best I can tell, (and this is an inference), a service is a name for 
the complete collection of devices that share some particular collection 
of features that is of interest to you.

You seem to think that medium is an interesting collection of features.

But personally, my interest is in presenting the presence status in a 
way that permits the client to decide where to contact you to achieve 
his ends.

Suppose you have a pc that supports both IM and voice, and you have a 
desk phone that only supports voice. When I look at your presence 
status, I would like to see that. Then I can decide to call you at your 
pc because then I can send you IMs at the same time, in the context of 
the same call. And I can then transfer you to someone else and they can 
continue to use both voice and IM to you.

> A copositor will have to combine tuples representing the same service (medium) that don't have contact addresses and possibly remove them completely if there is a tuple with a contact.

I don't understand this at all. If IM is a service, what is the point in 
reporting the status of IM without providing any way to do it?

(I'm at the corner of 5th avenue and broadway and my voice service is 
open for communication but I don't have any voice device.)

> What does a tuple represent when a device does not have any services? 

By services, I presume you mean media. If it is a sip device, it 
probably means that it is available to respond to sip signalling. 
Perhaps you can send it an OPTIONS message.

You are ignoring all the other RPIDS attributes. The tuple might 
indicate that no media is available because the only supported one is 
voice, and a voice call is currently in progress. Other RPIDS attributes 
may indicate this in more detail.

	Paul