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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 1 Apr 2003 15:45:02 -0500

You aren't helping :)

Do you see a useful distinction between a "user" and a "service"
in the context of presence?  By that do you see a need for
one person to have multiple services where there is a need show,
for a single presentity each of the services?

I'm having trouble here.  I don't like showing devices, but too
many people think there is value in having a single presence system
that implements a presentity that publishes presence for each of
the devices.  Here I want to ask if there is need to show presence
for separate applications/services?

Brian

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, April 01, 2003 3:33 PM
> To: Cnaan Oded
> Cc: 'Sean Olson'; Rosen, Brian; Jonathan Rosenberg; Simple WG
> Subject: RE: [Simple] Tuple references and device coupling
> 
> 
> As I think about this, I come to the conclusion that the distinction
> between services and devices is not entirely clear in this context.
> Brian modeled as devices running one or more services, but I think
> others may be thinking of a service as something that may run 
> on one or
> more devices.
> 
> Is the distinction that a device is something we can represent with a
> URI, and a service is not? That seems a little unnatural. Applications
> running on a device typically _can_ be represented by URIs, 
> at least if
> we are expected to talk to them. Even in your email example, there may
> not be a clear device, but there _is_ an addressable entity; 
> that is, I
> could get a mailto: URL in a tuple contact, and do something 
> useful with
> it. 
> 
> If we are thinking in terms of multiple addressable entities 
> being part
> of a service, that would seem to impy a way to assign a value 
> to a group
> of tuples.
> 
> 
> 
> 
> 
> On Tue, 2003-04-01 at 01:02, Cnaan Oded wrote:
> > I think that forcing all tuples to represent devices would be too
> > limiting in the real world. As I mentioned in my previous 
> email, there
> > are also services without devices (e.g., email) and cases where the
> > service is using an unknown device. A more general solution would be
> > to allow a tuple to represent either a service or a device.
> > 
> > I believe that solving the problem of relationship between 
> tuples and
> > tuple context would not be enough. The issue of how a service
> > (application) reports on which device it is running is 
> crucial for the
> > completeness of the solution.
> > 
> >  
> > Oded Cnaan
> > 
> > 
> > > -----Original Message-----
> > > From: Sean Olson [mailto:[email-masked]]
> > > Sent: Tuesday, April 01, 2003 4:25 AM
> > > To: Rosen, Brian; Jonathan Rosenberg
> > > Cc: Cnaan Oded; [email-masked]
> > > Subject: RE: [Simple] Tuple references and device coupling
> > > 
> > > 
> > > 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?
> > > 
> > > 
> > > 
> > > --- "Rosen, Brian" <[email-masked]> wrote:
> > > > 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
> > > > 
> > > === 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

---

From: Ben Campbell <[email-masked]>
Date: 01 Apr 2003 15:15:25 -0600

> You aren't helping :)

Sorry, I am having some difficulty expressing the concept.

> for a single presentity each of the services?

So, what does the word "service" mean in this context? Is IM in general
a service, where I might have multiple URIs at which I can accept IMs at
some time or another? Or is a "service" something that runs on a
particular address and port (i.e., on a device), If you mean the second,
then I can construct a URI that refers to the service, which I think
makes the distinction between service and device irrelevant. 

But I _think_ we mean the first. So, I _think_ your question refers to,
for example, the idea that I might have a voice service and an IM
service, each of which has several possible contact addresses. Further,
I might want to assert something about the IM service, that applies to
_all_ IM contacts. I think this idea has some use, but could be modeled
by simply applying the same attribute to each IM related tuple, rather
than having some special "service" tuple. 

Sorry if this continues to not help, but I honestly think that not
everyone participating in this tread shares the same definition of the
term "service"