Subject: Re: [Simple] Question on Presence Data Model draft

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 1 Jun 2006 17:30:05 -0400

[Chiming in since Vishal's project is in my lab.]

On May 31, 2006, at 7:01 PM, Rohan Mahy wrote:

> Hi Vishal,
>
> I'm assuming that the vehicle is a tuple for a human presentity--that
> the car doesn't have its own resource/presentity name.
>

Indeed; it's used as an adjunct to a person (in our case repair  
technicians in a truck).

The basic question is whether this should be treated as:

- person-associated information (under <person>)
- a <device> (although it is not necessarily a communication device)

Maybe a combination would be best, depending on the nature of the  
information.

> I don't think ignition is really orthogonal to movement status.  I
> think you want a rich presence indicator of movement within the tuple
> representing the vehicle.  The lock status might be relevant here as
> well.  What you are probably trying to determine is 1) a state of
> occupancy, and 2) a state of distraction. Keep in mind that many
> hybrids don't require use of an ignition switch.  I think these work
> for automobiles and trucks, but not for other types of vehicles:
>
> - parked locked (vehicle off)
> - parked unlocked (vehicle off)
> - standing (vehicle ready - idling/enabled)
> - stopped (vehicle not moving, but in a driving "gear")
> - under-way (vehicle in motion)
>
> You probably don't want fuel status.  Projected range is probably more
> interesting.  1 liter of fuel in a Prius vs. 1 liter in a Hummer makes
> a big difference in range.

It's just a lot harder to estimate this. I think at least for  
published information, having raw information seems more useful,  
maybe along with information about the vehicle type. (I'm actually  
not quite sure what this information might be used for, but maybe it  
is useful for OnStar-style systems if a guy with a gas canister needs  
to be dispatched.)

>
> The car stereo is often an interesting contributor to presence.  Some
> cars even allow you to turn on the stereo with the ignition off. As a
> student I used to sit in my car while studying, because the stereo was
> better there.  Be aware that many car stereos are easily heard (and
> listened to) outside the vehicle.

There are IM/presence systems that display what song you're currently  
listening to.

>
> Finally, if one or more of the seat belts are on this is probably a
> pretty reliable indicator of the presence of a human.  Unfortunately,
> not having seat belts on is not a reliable indicator that there are
> *not* humans in the car.

Most modern cars have weight sensors at least in their front seats,  
to tune the behavior of air bags. While absence of passengers in the  
front seat does not indicate an empty car, it might indicate a  
situation where the occupants are looking for privacy.

It would be interesting to find out what information standard vehicle  
monitoring systems expose.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Jun 2006 18:02:36 -0400

I may be missing how this is supposed to be used.

- Does the car know who (which presentities) are present within, so that 
it can report presence status about them?

- or does some independent element associated with a known presentity 
query the attributes of the car and then report that as presence status 
of the associated presentity? (E.g. when I use the car I dock my cell 
phone. It then picks up and reports the car status as part of my presence.)

- or is there a unique presentity associated with the car, regardless of 
who is within? (This would seem to be the case with OnStar.)

	Paul

Henning Schulzrinne wrote:
> It's just a lot harder to estimate this. I think at least for published 
> information, having raw information seems more useful, maybe along with 
> information about the vehicle type. (I'm actually not quite sure what 
> this information might be used for, but maybe it is useful for 
> OnStar-style systems if a guy with a gas canister needs to be dispatched.)
> 
>>
> Most modern cars have weight sensors at least in their front seats, to 
> tune the behavior of air bags. While absence of passengers in the front 
> seat does not indicate an empty car, it might indicate a situation where 
> the occupants are looking for privacy.
>

---

From: "Gadigeppa Malagund" <[email-masked]>
Date: Fri, 2 Jun 2006 10:52:22 +0530

Here is user of presentity is car, so information can be placed under
<person>.
This also indicates location of the presence source, a part of the
information can also be included in <device>.

Regards,
Gadi

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 2 Jun 2006 14:52:59 -0400

On Jun 1, 2006, at 6:02 PM, Paul Kyzivat wrote:

> - Does the car know who (which presentities) are present within, so  
> that it can report presence status about them?

The transmitter box in the car may not know, but the server that  
generates the NOTIFYs does, by a sign-in mechanism. (Currently, only  
the  subscription side, not the "black-box-to-server" link, uses  
SIMPLE.)

>
> - or does some independent element associated with a known  
> presentity query the attributes of the car and then report that as  
> presence status of the associated presentity? (E.g. when I use the  
> car I dock my cell phone. It then picks up and reports the car  
> status as part of my presence.)

Kind of. The in-vehicle box reports status to a server.

>
> - or is there a unique presentity associated with the car,  
> regardless of who is within? (This would seem to be the case with  
> OnStar.)
>

I agree that for an OnStar-like system using SIMPLE between the car  
and the telematics service, the car would be its own presentity. In  
that case, would we treat the car like a <person>?

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Jun 2006 17:59:29 -0400

Henning Schulzrinne wrote:
> the  subscription side, not the "black-box-to-server" link, uses SIMPLE.)

You mean I have to "log in" to my car???

Some keys now contain an RFID (at least so I surmise), that is different 
for each key, the car can know which key is being used. If keys are 1:1 
with people (sometimes true) then that may be sufficient, at least for 
the driver.

	Paul

>> query the attributes of the car and then report that as presence 
>> status of the associated presentity? (E.g. when I use the car I dock 
>> my cell phone. It then picks up and reports the car status as part of 
>> my presence.)
> 
>> - or is there a unique presentity associated with the car, regardless 
>> of who is within? (This would seem to be the case with OnStar.)
>>
> 
> I agree that for an OnStar-like system using SIMPLE between the car and 
> the telematics service, the car would be its own presentity. In that 
> case, would we treat the car like a <person>?
> 
> Henning
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 05 Jun 2006 12:43:24 -0400

Paul Kyzivat wrote:
> Some keys now contain an RFID (at least so I surmise), that is 
> different for each key, the car can know which key is being used. If 
> keys are 1:1 with people (sometimes true) then that may be sufficient, 
> at least for the driver.

I'm not sure what the Columbia folks are up to, but I can imagine a 
couple of use cases where it wouldn't be such a big deal to create a 
person-car association:

Situation 1, Rental cars: When I rent a car, I provide my identity to 
the rental car company, and I am the only person authorized to operate 
that car.  So in this case, either I, the rental company, or the car 
could register an association between me and the car.

Situation 2, Bluetooth: Many cars now come with integrated Bluetooth 
capabilities to enable hand-free calling.  It's entirely conceivable 
that when I hop into a car, my phone could ask for the car's presence 
information and register an association between itself and the car.  The 
opposite situation also seems possible (where the car recognizes its 
occupants' phones), but this would seem to pose privacy and 
authentication issues.

Cheers,
--Richard

---

From: "Winsor, Gerry" <[email-masked]>
Date: Mon, 5 Jun 2006 10:03:35 -0700

Hi Richard,

I agree with your Situation 1 use case, and yes the rental car company
will want to see a Driver Id for identity however wouldn't this also
play into the Federated Identity space where the Service Provider
maintaining Presence would use federated identity to authenticate &
identify you with the rental car company ... assuming that they have a
relationship in place? Federated Identity obviously complicates things
somewhat but could establish and maintain the relationship between you
and the car?

Just a thought ...
Gerry

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Monday, June 05, 2006 9:43 AM
To: Paul Kyzivat
Cc: [email-masked]; Henning Schulzrinne
Subject: Re: [Simple] Question on Presence Data Model draft

Cheers,
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 05 Jun 2006 14:52:07 -0400

Hi Gerry,

There are two issues here
1. Demonstrating to the Presence Service Provider that the request for a 
car-person association is authorized by the renter/subscriber.
2. Demonstrating to the Rental Car Company that a request (from a 
Presence Service Provider) for car information is relevant to an actual 
rental by the renter/subscriber.

What I understand from your email is that using federated identities 
could help with issue 2, where the identity provided by the Presence 
Service Provider has to match up with the identity held by the Rental 
Car Company.  I agree that this is true -- federated identity is 
intended to make identities on different systems comparable.

On the other hand, federation doesn't really seem relevant to issue 1, 
and issue 2 may not even arise: For instance, the renter/subscriber 
could use a device at the rental counter to (1) instruct his Service 
Provider to subscribe to his car's presence, and (2) instruct the Rental 
Company's presence facility to accept a subscription from his Service 
Provider to that car.  In this way, the renter/subscriber would only 
need to authenticate to the Presence Server and the Rental Company 
individually.

Cheers,
--Richard

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 08 Jun 2006 16:31:36 -0400

The model I have in my head from Hennings comments is this:

  Please view in a fixed-width font such as
                  Courier.

           +---------+         +---------+
           |         |         |         |
           |         |SIMPLE   |         |
           |Watcher  |-------->|Presence |
           |         |         |Server   |
           |         |         |         |
           +---------+         +---------+
                                    ^
                                    |
                                    |  i/f A
                                    |
                                    |
                               +---------+
                               |         |
                               |         |
                               |  Car    |
                               |         |
                               |         |
                               +---------+

The watcher talks to the presence server with SIMPLE. The presence 
server is receiving information from the car, such as whether the car is 
on/off, moving, and so on. The presence server uses this information to 
generate presence information to the watcher. Consequently, I think you 
need to consider the two interfaces in the diagram separately.

In the interface from the watcher to the presence server, I don't think 
the documents published from the presence server would say very much at 
all about the state of the car. Rather, since we're talking about 
*presence*, which is about human-centric communications, the information 
from the car would have been used to derive presence states. For 
example, the <person> element might have an <activities> that indicates
driving' if the car is moving, and if the car detects that there are no 
other passengers, might add the <privacy> element.

However, the information from the car to the presence server would be 
'raw' - that is, it directly conveys the car states, such as ignition 
status, fuel status, moghtmail-Tracker: AAAAAA==
Date: Thu, 08 Jun 2006 16:31:36 -0400
From: Jonathan Rosenberg <[email-masked]>
To: Paul Kyzivat <[email-masked]>
Subject: Re: [Simple] Question on Presence Data Model draft
Cc: [email-masked], Henning Schulzrinne <[email-masked]>

The model I have in my head from Hennings comments is this:

  Please view in a fixed-width font such as
                  Courier.

           +---------+         +---------+
           |         |         |         |
           |         |SIMPLE   |         |
           |Watcher  |-------->|Presence |
           |         |         |Server   |
           |         |         |         |
           +---------+         +---------+
                                    ^
                                    |
                                    |  i/f A
                                    |
                                    |
                               +---------+
                               |         |
                               |         |
                               |  Car    |
                               |         |
                               |         |
                               +---------+

The watcher talks to the presence server with SIMPLE. The presence 
server is receiving information from the car, such as whether the car is 
on/off, moving, and so on. The presence server uses this information to 
generate presence information to the watcher. Consequently, I think you 
need to consider the two interfaces in the diagram separately.

In the interface from the watcher to the presence server, I don't think 
the documents published from the presence server would say very much at 
all about the state of the car. Rather, since we're talking about 
*presence*, which is about human-centric communications, the information 
from the car would have been used to derive presence states. For 
example, the <person> element might have an <activities> that indicates
driving' if the car is moving, and if the car detects that there are no 
other passengers, might add the <privacy> element.

However, the information from the car to the presence server would be 
'raw' - that is, it directly conveys the car states, such as ignition 
status, fuel status, mohe
>>document should be applied to the presentity URI sip:[email-masked]
> 
> as
> 
>>well. Consequently, a SUBSCRIBE request for sip:[email-masked] would
>>return a presence document whose entity attribute is
> 
> sip:[email-masked].
> 
> I guess there is typo - it should say:
> ...applied to the presentity URI pres:[email-masked] as well...
> Am I right?

Yes, sorry.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Jun 2006 23:30:44 -0400

>  Please view in a fixed-width font such as

That works for me. I was initially imagining "i/f A" being PUBLISH, and 
wondering how the car would know who to publish to.

	Paul

> status, fuel status, movement status, and so on. I would assert that 
> this is not presence at all, but rather is other type of state that is 
> useful for composing presence. Consequently, I'd suggest defining a new 
> event package to appropriately represent this information.
> 
> This concept - of using data from other event packages (or non-SIP 
> sources as the case may be) to derive presence states - is one of the 
> things that needs to be described in presence-processing-model IMHO.
> 
> Thanks,
> Jonathan R.
> 
> Paul Kyzivat wrote:
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 09 Jun 2006 10:39:51 -0400

inline.

Paul Kyzivat wrote:

>> server is receiving information from the car, such as whether the car 
>> is on/off, moving, and so on. The presence server uses this 
>> information to generate presence information to the watcher. 
>> Consequently, I think you need to consider the two interfaces in the 
>> diagram separately.
> 
> 

It can still be a PUBLISH (the alternative being a back end subscription 
from the presence server to the car), but it wouldn't be for the 
presence event package.

-Jonathan R.