Subject: RE: [Simple] Tuple design team discussion summary

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jul 2003 08:47:10 -0500

Jonathan Rosenberg [mailto:[email-masked]] writes:

> So, I think there is value in having an RPIDS attribute which conveys 
> some kind of information about what the tuple represents. We 
> can start 
> with a basic set of types:
> 
> "cell phone"
> "PDA"
> "wireline phone"
> "IM service"

It's not clear that tuples can always be classified as
something this concrete, though. What if I want to publish
a single tuple that represents an amalgamation of my presence
status, for example? Two tuples, with one representing my
"work" devices, and one representing my "personal" devices?

I think one of the important drivers behind not mandating
a particular binding of a tuple to something like a device
is that doing so provides infinite flexibility in publishing
information. It seems that having a canonical (even if
expandable) set of blessed "types" of tuples will restrict
this flexibility unnecessarily.

/a

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 Jul 2003 03:10:18 -0400

> Unlimited flexibility can also lead to interoperability problems, and 
> this is the essence of what Brian has been complaining about, 
> I think. 
> Its not all or nothing. There is a reasonable point of compromise 
> where we allow some flexibility but introduce some constraints. 
> Finding that right point is what engineering is all about.
> 
> I think that we can standardize a bunch of labels which cover 
> a lot of 
> common cases. If someone wants to send a presence document with a 
> tuple outside of one of those categories - fine. Don't use the label. 
> But, it may not be handled well on a device that can't display 
> anything to the user except an iconic representation of that label.
Yes!

It also works for an aggregator, who may be able to take, say
both device and "service" labeled views and produce a meaningful
composite view.  For example, it could (assuming a reasonable
definition of "service", provide a composite service view,
or my user view.  If the aggregator was asked to provide
a device view, it would not be able to fully comply because it
doesn't have the device views from the service view source. 

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 Jul 2003 03:10:18 -0400

Yes!

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 Jul 2003 06:21:30 -0400

frankly, I think all you need is a device called phone,
the rest is capabilities.  It is the fact that the tuple is a phone
that you can't deduce.  It may actually be possible to just
label it "device".  I would not object to differentiating
PC from phone, and text devices.  There is the PDA,
the problem there is the TREO-like devices, are they
phones or PDAs?

The others are
"service" and I know we need a definition
"user" (or "presentity, if you prefer)
Both of these imply some sort of aggregation.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2003 4:38 AM
> To: Ben Campbell
> Cc: Simple WG
> Subject: Re: [Simple] Tuple design team discussion summary
> 
> 
> Almost none of the labels in RPIDS are exhaustive or claim to 
> be, so a 
> list is better than nothing. To make progress, I would like 
> to call for 
> nominations for such labels. The obvious ones are device-oriented ones
>    cell phone
>    PC
>    landline phone
>    text device (BlackBerry, SMS, TTY, ...)
> other suggestions?
> 
> Ben Campbell wrote:
> 
> > 
> > I think even that can be handled cleanly. Such a device 
> just displays 
> > some default icon that indicates it does not know what type 
> of tuple it
> > has. That is no different from common usage in many other 
> applications.
> > For example, email attachments when your browser does not 
> recognize the
> > mime type, or gets something completely generic like
> > application/octet-stream without any other qualifiers.
> > 
> 
> 
> 
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 Jul 2003 06:21:30 -0400

The others are

---

From: [email-masked]
Date: Tue, 15 Jul 2003 13:41:37 +0300

I agree with Brian. I think we only ever discussed those 3: device, service and user. We don't need to be very explicit, information in the tuple give away the finer details about that thing that the tuple represents. 

Other than those 3, I haven't heard of other things that a tuple can represent, unless we allow a combination of the 3 above (which I believe we don't).

Regards,
Hisham

> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2003 1:22 PM
> To: 'Henning Schulzrinne'; Ben Campbell
> Cc: Simple WG
> Subject: RE: [Simple] Tuple design team discussion summary
> 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 Jul 2003 07:40:21 -0400

For this purpose, a service is a tuple representing a communications
path to a set of devices that have some common characteristics. 
The tuple contains the URI to the service, and the characteristics
(capabilities)
of the service.
 
The service endeavors to deliver a request for communication to an
appropriate
device from the set of devices it controls.  The presence information
presented by the service is represents that of the service as a whole,
rather than that of one of its constituent devices.  It is NOT
necessarily a simple pivot of device presence information.  The service
may have additional information, and it may combine information in
ways not expressible as a pivot of the device data.

A service is differentiated from a device in that the URI explicitly
represents the services, requests for communication will be forwarded
to one of the devices the service controls. 

A service is differentiated from a user in that a user may have
multiple services, each of which may have separate presence tuples.
Normally, a user has a single tuple representing the presence of
the user as a person.

You can think of this as a hierarchy, where a user has a set of
services each of which has a set of devices.  Nothing limits
the hierarchy to two levels (a service could aggregate multiple
services, although I can't think of an example that makes a lot
of sense).  It's also possible to have a user who doesn't have
services.  In that case he has a set of devices that are aggregated
directly to form the user tuple.  The service is equal to device.

Brian

> Sent: Tuesday, July 15, 2003 7:05 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> [email-masked] wrote:
> 
> > I agree with Brian. I think we only ever discussed those 3: device,
> > service and user. We don't need to be very explicit, information in
> > the tuple give away the finer details about that thing that 
> the tuple
> > represents.
> > 
> > Other than those 3, I haven't heard of other things that a tuple can
> > represent, unless we allow a combination of the 3 above (which I
> > believe we don't).
> 
> To beat a horse carcass: While device and 'user' has reasonable 
> definitions, nobody, after a year+, has provided an operational 
> definition of service. Since this label needs to be understandable by 
> people who have not participated in the Tuple Theory 745 
> class (this is 
> graduate-level stuff...), I don't think an elaborate definition helps.
> 
> 'device', 'user' and 'other' seem to work ok, which seems to be close 
> enough. (Earlier versions of RPIDS had an approximation to such an 
> element, with the addition of 'group'.) For those, there are 
> reasonable 
> pictograms, too - phone, stick person and ?.
> 
> Henning
> 
>

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 15 Jul 2003 13:31:35 +0100

Brian,
This structure seems reasonable to me - One question, I understand that a user Tuple would be present with multiple service tuples.  How are the device tuples associated with the correct service tuples (maybe this is clear and I am missing something) - could the class attribute be used?
 
Chris.

	-----Original Message----- 
	From: Rosen, Brian [mailto:[email-masked]] 
	Sent: Tue 15/07/2003 12:40 
	To: 'Henning Schulzrinne'; [email-masked] 
	Cc: [email-masked]; [email-masked] 
	Subject: RE: [Simple] Tuple design team discussion summary

	

	
	Brian

J)��隊X��X��(��W�z��m��?�0�'�~���f��f��X��)ߣ�"��^

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 15 Jul 2003 13:31:35 +0100

Brian,
 
Chris.

	-----Original Message----- 
	From: Rosen, Brian [mailto:[email-masked]] 
	Sent: Tue 15/07/2003 12:40 
	To: 'Henning Schulzrinne'; [email-masked] 
	Cc: [email-masked]; [email-masked] 
	Subject: RE: [Simple] Tuple design team discussion summary

	

	
	Brian

---

From: [email-masked]
Date: Tue, 15 Jul 2003 15:36:11 +0300

I think I mentioned something like this before: Service to me means something that an operator can offer (as part of a package) and charge for. IM, presence and geoloc are some examples.

This is probably not the definition you are looking for since its not technical, but probably its good enough to warrant the inclusion of the term 'service' in the list of what a tuple represents. I don't think having the term 'other' is a good idea since it might confuse implementers in the sense that they would not know what goes into such a tuple.

Brian started some discussion about service definition, perhaps we need to discuss further a technical definition of what a service is. I believe this is better than just saying that we have a 'other' tuple that represents things that are not devices or are not users.

Regards,
Hisham

> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2003 2:05 PM
> To: Khartabil Hisham (NMP/Helsinki)

---

From: [email-masked]
Date: Tue, 15 Jul 2003 15:39:43 +0300

If you have service tuples and device tuples, then you probably have some overlap in the information they provide. I would say either you have device tuples of service tuples but not both concurrently.

Regards,
Hisham

> From: ext Chris Boulton [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2003 3:32 PM
> To: Rosen, Brian; Henning Schulzrinne; Khartabil Hisham (NMP/Helsinki)
> This structure seems reasonable to me - One question, I 
> understand that a user Tuple would be present with multiple 
> service tuples.  How are the device tuples associated with 
> the correct service tuples (maybe this is clear and I am 
> missing something) - could the class attribute be used?
>  
> Chris.
>  
> 
�jezf��)��+-J)��螵�+�m����5��_��?�������+-�w��Ȧ�W

---

From: [email-masked]
Date: Tue, 15 Jul 2003 15:39:43 +0300

Regards,
Hisham

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 Jul 2003 11:07:43 -0400

I think it will be unusual to have both device and service tuples in
a single presence document, but it could happen.

Rather, I see a service provider aggregating a number of separate
device presence documents to produce a single service tuple.
I also then could see another aggregator (a presence aggregator)
aggregating a number of service tuple into a single
user tuple.

In all of these cases, it could be an option for the aggregator
to accept a request to provide lower level information.
Given permissions were available, that could happen.
I actually expect in most cases, permission will NOT be
forthcoming.

If for some reason, you got both device and service
tuples in one document, I don't think there is, in general,
any way to group them, and I don't think that matters.

Brian

> From: Chris Boulton [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2003 8:32 AM
> To: Rosen, Brian; Henning Schulzrinne; [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 Jul 2003 18:05:34 -0400

I think service providers will not allow publishing presence to
anyone but their PA.  How many mobile operators allow you to'
select your own voicemail provider?

I think the only way to provide comprehensive presence will be
to have a 3rd party presence provider that subscribes as a
watcher to all of your service provider's PAs.  I hope that
the SP will allow you to construct rules that allow you to say
that ONLY your presence service can get your device's presence
from each of your service provider's presence services.
Your presence service can then publish your "real" presence
as a composite of all of your service provider's presence data.

I think it will be quite rare to have two devices served by the
same service provider, and I don't think service providers will
make it very easy for other service providers to get
PUBLISH data.  Among other things, the security implications
are too complex (inter provider authentication).

The presence service provider will create a contact for you.
When a call arrives at that contact, it will be forwarded to
the most appropriate device, depending on:
	Who is calling
	Caller Preferences
	Presentity policy

You will only hand out one AOR, a SIP URI.  It will work 
for all of your devices and your presence.  Your business
card has ONE address, your single AOR.

It may be the case that your enterprise is the presence
service provider, and it might have one of the devices
under it's direct control (your desk phone).  However,
your mobile, your wireless PDA, your home phone and
your Blackberry all are served by different SPs, that
all have their own presence service, just like most of
them have their own voicemail now.

Robert, can this be my use case description :)

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2003 4:24 PM
> To: Rosen, Brian
> Cc: 'Chris Boulton'; Henning Schulzrinne; [email-masked];
> [email-masked]; [email-masked]
> Rosen, Brian wrote:
> How do you see that happening? AFAIK, we are talking about a scenario 
> where tuples are PUBLISHed to and AOR, received by an 
> aggregator working 
> on behalf of that AOR, which produces aggregated presence documents 
> which are delivered to subscribers to that same AOR.
> 
> How do you fit another component (a service provider) into 
> this picture? 
> I think you must introduce another AOR for the service, that 
> has its own 
> presence.
> 
> If you do that, you are introducing something closer to 
> Henning's group 
> presentity. I would still assert that you can treat the AOR that 
> corresponds to the service as a device while doing no harm to the 
> ultimate watcher.
> 
> 	Paul
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 Jul 2003 18:05:34 -0400

Brian