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

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 31 Mar 2003 14:07:49 -0500

Perhaps the time has come to take this particular bull by the horns
and make it EXPLICIT what the tuple represents.  We've had
too many disagreements on mechanisms where the parties want the
tuple to represent different things.  Our solutions thus far
usually mean widening options to make all things possible.

Pehaps we can make an explicit tree shaped hierarchy where a
	User may have a series of 
		Devices, each one of which 	may have a number of 
			Applications
Each of these can provide presence.

If we were to go this far, I'd like links between them (parent/sibling)
so that in a real world mixed environment, you have a chance to
figure out what is happening.

Brian

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Monday, March 31, 2003 1:11 PM
> To: Jonathan Rosenberg
> Cc: Cnaan Oded; [email-masked]
> Subject: Re: [Simple] Tuple references and device coupling
> 
> 
> Understood... now the next immediate question is:
> 
> Does the syntax provided by PIDF contain the 
> semantics of device, application, and user?
> 
> Of course you can build this with the syntax of 
> a tuple. The problem is that you can build this
> in more than one way and there is no clear 
> standard way to do this.
> 
> I was hoping that RPIDS would solve this, at 
> least for the SIMPLE community. 
> 
> Am I wrong?
> 
> --- Jonathan Rosenberg <[email-masked]>
> wrote:
> > It all comes back to the same problem - what does a
> > tuple represent?
> > 
> > Ultimately, tuples (and in general, a presence
> > document) are tools for 
> > modeling real-world systems that have components
> > like people, devices, 
> > applications, and so on. We NEED to have agreed-upon
> > definitions of what 
> > a tuple is, and how it is used to model real-world
> > systems, or these 
> > problems will continue to plague us.
> > 
> > What Oded is saying is that the presence document
> > has to take into 
> > account the fact that there are relationships
> > between devices and 
> > applications in the real world, and the model needs
> > to take that into 
> > account.
> > 
> > -Jonathan R.
> > 
> > Sean Olson wrote:
> > > There seems to be a third option which is popular
> > > as well. The tuple ID is just an ordering
> > mechanism
> > > within an XML document to determine when tuples
> > are
> > > added and removed. Additional syntax is then
> > required
> > > to achieve the semantics of device/service that
> > you
> > > mention below. This appears to be the approach 
> > > adopted in the RPIDS draft. Perhaps Henning or
> > Paul
> > > can comment?
> > > 
> > > Regards,
> > > Sean
> > > 
> > > --- Cnaan Oded <[email-masked]> wrote:
> > > 
> > >>Although the question "what a tuple represents"
> > has
> > >>not been discussed in
> > >>depth yet, it seems that most implementation have
> > >>chosen to either represent
> > >>devices or services. For example, a tuple may
> > >>represent a cell phone but can
> > >>also represent an IM client running on a mobile
> > >>phone.
> > >> 
> > >>Here is a simple example of 2 such tuples:
> > >> 
> > >><?xml version="1.0" encoding="UTF-8"?>
> > >><presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
> > >>  entity="pres:[email-masked]">
> > >>
> > >>   <tuple id="phone">
> > >>      <status>
> > >>         <basic>open</basic>
> > >>      </status>
> > >>      <contact>tel:09012345678</contact>
> > >>    </tuple>
> > >> 
> > >>   <tuple id="mobile-im">
> > >>      <status>
> > >>         <basic>open</basic>
> > >>         <im:im>busy</im:im>
> > >>      </status>
> > >>      <contact>sip:[email-masked]</contact>
> > >>    </tuple>
> > >> 
> > >></presence>
> > >>
> > >>
> > >>There are cases where there is a relationship
> > >>between these tuples. For
> > >>example, in the above example, the IM client is
> > >>running on the same device
> > >>described by the first tuple, meaning that there
> > >>might be some information
> > >>(e.g., location) that is related to both tuples.
> > >> 
> > >>One approach to handle it would be to duplicate
> > this
> > >>information. Having
> > >>'Location' described in the tuple representing the
> > >>device as well as the one
> > >>representing the service. This approach is not
> > >>efficient in terms of volume
> > >>as many tuples might relate to the same
> > information.
> > >> 
> > >>Another possible solution would be to create a
> > >>reference between tuples, in
> > >>this example between a "service tuple" and a
> > "device
> > >>tuple". In this case,
> > >>the information is described only once but is
> > >>referenced from other tuples.
> > >>For example:
> > >> 
> > >>   <tuple id="mobile-im" ref="phone">
> > >>      <status>
> > >>         <basic>open</basic>
> > >>         <im:im>busy</im:im>
> > >>      </status>
> > >>      <contact>sip:[email-masked]</contact>
> > >>    </tuple>
> > >> 
> > >>Following the latter option, the device status,
> > >>location, LCD resolution or
> > >>any other attributes associated with the device
> > may
> > >>be picked up from the
> > >>"phone" tuple so that the "mobile-im" tuple
> > >>represents only the service
> > >>characteristics.
> > >> 
> > >>Following the above example, if the user is on a
> > >>call, and his device state
> > >>changes from "open" to "call" (assuming this is a
> > >>valid value), the "phone"
> > >>tuple is the only one that changes (and will be
> > >>included in the NOTIFY). The
> > >>IM watcher would be able to deduce on which device
> > >>the client is running and
> > >>therefore its state (and location...).
> > >> 
> > >>Although IM was used in the example, it may imply
> > to
> > >>any other service such
> > >>as Voicemail, Calendar, PTT, Address book, MMS
> > etc.
> > >> 
> > >>Note that not all services are associated with
> > >>devices. An email service,
> > >>for example, may be self sufficient as there is no
> > >>real meaning to instant
> > >>or direct communications and since the session is
> > >>transient.
> > >> 
> > >>Another related issue that calls for attention is
> > >>the ability to create
> > >>coupling between services and the device they are
> > >>currently using. For
> > >>example, assuming a user that has 2 phones, only
> > one
> > >>with a PTT client,
> > >>turns on both phones, the PTT service needs to be
> > >>able to inform the
> > >>presence server not only that it is active but
> > also
> > >>on which of the devices
> > >>(of course that this info is subject to privacy
> > >>policy as any other
> > >>information element).
> > >> 
> > >>Having the ability to tie a service to a device
> > >>allows the PS to perform
> > >>advanced compositions. For example, in the
> > previous
> > >>example, the PS may
> > >>automatically change the PTT state to busy when
> > the
> > >>user is on a voice call
> > >>without having the client to publish anything
> > (using
> > >>network agents). This
> > >>may also be useful when aggregating additional
> > >>presence info that is not
> > >>intrinsic to the service (e.g., location).
> > >> 
> > >> 
> > >>Oded Cnaan
> > >> 
> > >>
> > > 
> > > 
> > > 
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Platinum - Watch CBS' NCAA March Madness,
> > live on your desktop!
> > > http://platinum.yahoo.com
> > > _______________________________________________
> > > Simple mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/simple
> > > 
> > 
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                600
> > Lanidex Plaza
> > Chief Scientist                            
> > Parsippany, NJ 07054-2711
> > dynamicsoft
> > [email-masked]                     FAX:  
> > (973) 952-5050
> > 
> === message truncated ===
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.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: Sean Olson <[email-masked]>
Date: Mon, 31 Mar 2003 17:24:55 -0800 (PST)

Sounds like a reasonable way forward. My only
comment is that we might wish to model applications
independent of a device, but that could be a future
improvement. 

Based on this understanding, it would seem that 
tuple == device?