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

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

> -----Original Message-----
> From: Chris Boulton [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2003 8:32 AM
> To: Rosen, Brian; Henning Schulzrinne; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Simple] Tuple design team discussion summary
> 
> 
> 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
> 	
> 	
> 
> 	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
> 	
> 	> -----Original Message-----
> 	> From: Henning Schulzrinne [mailto:[email-masked]]
> 	> Sent: Tuesday, July 15, 2003 7:05 AM
> 	> To: [email-masked]
> 	> Cc: [email-masked]; [email-masked];
> 	> [email-masked]
> 	> Subject: Re: [Simple] Tuple design team discussion summary
> 	>
> 	>
> 	> [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
> 	>
> 	>
> 	> _______________________________________________
> 	> Simple mailing list
> 	> [email-masked]
> 	> https://www1.ietf.org/mailman/listinfo/simple
> 	>
> 	
> 	_______________________________________________
> 	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: Tue, 15 Jul 2003 16:24:26 -0400

> aggregating a number of service tuple into a single

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: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jul 2003 16:24:26 -0400

Paul