One document matched: draft-singh-simple-vehicle-info-00.txt
Network Working Group V. Singh
Internet-Draft H. Schulzrinne
Intended status: Standards Track Columbia U.
Expires: February 2, 2008 P. Boni
Verizon
Aug 2007
Vehicle Info Event Package
draft-singh-simple-vehicle-info-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines a new SIP event package for updating and
retrieving status information of vehicles. The information can
include the vehicle's status and diagnostic information distributed
by vehicle telematics systems. This event package is useful for
fleet management and vehicle tracking applications. The event
package is called as vehicle-info event package and is applicable for
Singh, et al. Expires February 2, 2008 [Page 1]
Internet-Draft Vehicle Info Event Package Aug 2007
all types of vehicles like cars, buses, ships and air crafts.
However, this document focuses on automobiles.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Vehicle-info Event Package Description . . . . . . . . . . . . 4
3.1. Message Flow Diagram . . . . . . . . . . . . . . . . . . . 5
3.2. Vehicle Status Information . . . . . . . . . . . . . . . . 6
3.3. Vehicle Location Information . . . . . . . . . . . . . . . 7
4. Vehicle-info Event Package . . . . . . . . . . . . . . . . . . 7
4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 7
4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 7
4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 7
4.4. Subscription Duration . . . . . . . . . . . . . . . . . . 7
4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8
4.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
4.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 8
4.9. Rate of Notifications . . . . . . . . . . . . . . . . . . 9
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Example of vehicle-info XML . . . . . . . . . . . . . . . 13
6.2. Message Flow Example . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Authorization Considerations . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Singh, et al. Expires February 2, 2008 [Page 2]
Internet-Draft Vehicle Info Event Package Aug 2007
1. Introduction
The Session Initiation Protocol (SIP) events framework [9] defines
subscription-based event distribution mechanism for sending
notification of events. This document defines a new SIP event
package for getting notification about vehicle information.
Today, vehicle information is processed and communicated via vehicle
telematics systems, which employ a multitude of standards and are
used for a number of purposes, including remote diagnostics and
reporting vehicle's mechanical and electronic problems or failures.
Increasingly, navigational and entertainment applications are being
deployed within such frameworks such as ITSA[1], GST [2].
The vehicle information can be used for monitoring and tracking
purposes. For example, location information and movement related
information (speed, acceleration and direction) can be used to to
perform location tracking and to ensure that the vehicle is moving
within acceptable speed limits. Other information useful for
monitoring includes vehicle status information (e.g., ignition
status), vehicle's diagnostic information and connectivity
information. Some of the vehicle's information can be directly used
to infer presence information of users of the vehicle whereas other
information is only useful in vehicle management (e.g., by car-rental
companies).
The vehicle's information can be divided into two parts. Firstly,
the core vehicular information which include vehicle's status and
diagnostic information and secondly, the location and connectivity
related information, already standardized in presence and location
specifications in RFC4119[3].
The vehicle-info event package as described in this document can be
used to distribute core vehicular information. The event package
aggregates vehicle information from telematics systems into an XML-
based data structure. This document specifies the schema of proposed
event package. The schema contains core vehicular information as
well as other information. Some of which can be mapped to device
characteristic as defined in the presence data model. The proposed
schema should be treated as a seed document, open for contributions
from vehicle telematics industry and their standards institutions.
Additionally, this document gives message flow examples which shows
how to obtain and use this information.
For location (RFC4119[3]), dynamic object status [10] and
connectivity information the document proposes to use the presence
event package.
Singh, et al. Expires February 2, 2008 [Page 3]
Internet-Draft Vehicle Info Event Package Aug 2007
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [4].
This document uses GML Moving Vehicle terms as described in GML[5].
It also introduces terminology from the On Board Diagnostics
standard's (OBD-II) [6].
3. Vehicle-info Event Package Description
This event package defines a XML-based schema for information that
can be used to manage vehicles. It also shows how an application can
subscribe to the information related to a vehicle or use this
information to derive presence information of a user. An application
will subscribe to a vehicle either using vehicle-info and/or presence
event package.
If the application is managing a vehicle (e.g., fleet management
application), it sends a SUBSCRIBE request using the vehicle-info
event package and presence event package to the vehicle's presentity.
The application will get the vehicle information in the specified XML
format or in other formats such as PIDF [11], depending on the
application processing functions.
Alternatively, if the application is managing user's (driver or
passenger) presence data, in such a case the application tries to
compose user's presence information with vehicle as a device which
contributes to user's presence. The application sends SUBSCRIBE
request to vehicle's presentity using both vehicle-info and presence
event packages.
A different protocol can be used to dynamically associate and
disassociate drivers/passengers with vehicle identities. If the
association exists, a presence server would compose user's
presentity's PIDF based on the vehicle information provided.
However, the details of such association are beyond the scope of this
document.
The information the vehicle-info event package provides consists of
vehicle static description or characteristics data, internal vehicle
state data and diagnostics.
Singh, et al. Expires February 2, 2008 [Page 4]
Internet-Draft Vehicle Info Event Package Aug 2007
3.1. Message Flow Diagram
+-----------+ +----------------+ +-----------+ +-------+
| | | | | | | |
| Vehicle | |Vehicle Location| |Application| |Watcher|
| VUA | | UA (VLUA) | | (PS) | | |
+-----------+ +----------------+ +-----------+ +-------+
| | | |
| | | |
| | | SUBSCRIBE |
| | |<------------------|
| | | Event:presence |
| | | |
| SUBSCRIBE | | |
|<-------------------------------------| |
| Event: Vehicle-info | |
| | | |
| NOTIFY | | |
|------------------+------------------>| |
| Event: Vehicle-info | |
| | | |
| | SUBSCRIBE | |
| |<------------------| |
| | Event:presence | |
| | | |
| | NOTIFY | |
| |------------------>| |
| | Event:presence | |
| | | NOTIFY |
| | |------------------>|
| | | Event:expanded |
| | | PIDF |
Figure 1: Vehicle-info event package to derive presence information
(driver's PUA not shown)
When an application or a presence server receives a subscription
request for a user currently in a vehicle, the presence server checks
for the user-vehicle association and then generates SUBSCRIBE
requests. These requests are issued to presence agent of user,
vehicle's presence user agent (VLUA), and vehicle's user agent for
vehicle-info (VUA). VUA and VLUA are logical entities and can be
collocated.
Singh, et al. Expires February 2, 2008 [Page 5]
Internet-Draft Vehicle Info Event Package Aug 2007
When NOTIFY messages from VUA and VLUA reach the presence server,
they will be used to compose user's presence state and to send
expanded PIDF to the requesting watcher. For example, the <person>
element in PIDF/RPID might have an <activities> tag that indicates
'driving' if the car is moving. Also, the vehicle location
information, if present, will be included in user's expanded PIDF.
When user presence state already contains location, e.g., from a GPS-
enabled cell phone, then there is a need to reconcile such
information, obtained from two different location sources.
3.2. Vehicle Status Information
Vehicle status information is subdivided into vehicle state
information and diagnostics data.
Vehicle status information is only partially standardized today.
Telematics systems use different specifications to describe vehicle
data. Manufacturers of vehicle control devices provide different
static and dynamic information about the vehicle. In this document,
we have focused on the information provided by OBD-II [6].
OBD-II [6] stands for the On-Board Diagnostics, generation II.
OBD-II [6] is a set of rules and regulations each car manufacturer
has to follow to have their Engine Management System pass the U.S.
federal emissions tests. It also allows to run a set of
comprehensive diagnostics related to the engine and other parts of
the vehicle using OBD-II [6] scan tools. Most modern vehicles are
OBD-II [6] equipped. Diagnostics can be performed locally or
remotely. OBD-II [6] specification uses the Diagnostic Trouble Codes
(DTC), which can be stored in the vehicle's Powertrain Control Module
(PCM) and retrieved or obtained on demand by running a new diagnostic
test.
The DTC is a five byte code. The first byte is an ASCII character
that identifies the part of the vehicle where the fault occurred. It
can assume the values P, B, C or U. For example, "P" refers to the
engine or transmission system. The second byte can take value of
digit "0" for common fault code or "1" for proprietary one. the third
byte indicates the vehicle subsystem at fault and can have values fro
1 to 8. For example, "2" refers to fuel system. the fourth and fifth
byte indicate a specific code number for a given fault. Each DTC has
also a short text associated with it.
Apart from the vehicle state and diagnostic information, the system
can provide some vehicle status information, such as Vehicle
Identification Number (VIN) and the real time data such as engine
coolant temperature, different types of fuel system data, engine RPM
and speed.
Singh, et al. Expires February 2, 2008 [Page 6]
Internet-Draft Vehicle Info Event Package Aug 2007
Example of vehicle information data is presented in Section 6.
3.3. Vehicle Location Information
The vehicle's location and moving status information can be described
using RFC 4119 [3] and moving object status tracking [10] using the
presence event package.
Assuming the vehicle or the agent representing it (e.g., VLUA in
Figure 1) contains the location information about itself, it can
convey this information using PIDF-LO [3], presence event package
[12]. This requires the application (e.g., user's presence server)
to SUBSCRIBE using the presence event package to receive the location
information and its updates.
If there is a user-vehicle association, the location information can
be directly used to determine the user's location. Otherwise,
location information only refers to the position of the vehicle.
4. Vehicle-info Event Package
4.1. Event Package Name
The name of this event package is "vehicle-info". This package name
is carried in the SIP Event and Allow-Events header fields, as
defined in RFC 3265 [9].
4.2. Event Package Parameters
RFC 3265 [9] allows event packages to define additional parameters
carried in the Event header field. This event package does not
define additional parameters.
4.3. SUBSCRIBE Bodies
The SUBSCRIBE bodies may contain the watcher filters (RFC 4660)[13]
to specify triggers of when and what data the watcher is interested
in. The mechanism to specify the filter remains same as specified in
event filter format document [14].
4.4. Subscription Duration
The default expiration time for subscription to vehicle-info event
package will be one day. Normally, a vehicle will be allocated to a
task at a granularity of one day. However, this may change depending
on the usage scenario, in which case the alternative expiration time
will be specified by a subscriber in the Expires header field. .
Singh, et al. Expires February 2, 2008 [Page 7]
Internet-Draft Vehicle Info Event Package Aug 2007
4.5. NOTIFY Bodies
According to RFC 3265, the NOTIFY message will contain bodies in a
format listed in the Accept header field of the SUBSCRIBE request or
a package-specific default if the Accept header field was omitted
from the SUBSCRIBE request. All subscribers and notifiers MUST
support the "application/vehicle-info+xml" data format described in
Section 4. By default, if no Accept header field is specified in a
SUBSCRIBE request, the NOTIFY request will contain a body in the
"application/vehicle-info+xml" data format. If the Accept header
field is present, it MUST include "application/vehicle-info+xml" and
MAY include any other types.
4.6. Notifier Processing of SUBSCRIBE Requests
RFC 3265 specifies that packages should define any package-specific
processing of SUBSCRIBE requests at a notifier, specifically with
regards to authentication and authorization.
Vehicle dynamic state information is a sensitive data. Therefore,
all subscriptions to it SHOULD be authenticated and authorized before
approval. Authentication MAY be performed by the techniques
available through SIP, such as digest, S/MIME, TLS. Authorization
policies for access need to be administered. We assume that in most
cases applications will be subscribers, in which case authorization
policies will be provided ahead of time.
SUBSCRIBE requests are addressed to the vehicle ID, typically
vehicle's VIN, at provider's domain, e.g., 44G44444H4444@avis.com.
The notifier will verify whether vehicle id is in the scope of
Vehicle UA (VUA). The VUA may be collocated with the vehicle or it
can be a network-based entity collocated with other VUA's.
4.7. Notifier Generation of NOTIFY Requests
Once the subscription is accepted, the notifier MAY send NOTIFY with
the body of the most recent vehicle information data it has.
Typically, it will send the NOTIFY when any data item in the vehicle
information data has changed. The body of the NOTIFY MUST be sent
using one of the types listed in the Accept header field in the most
recent SUBSCRIBE request, or using the type "application/
vehicle-info+xml" if no Accept header field was present.
4.8. Subscriber Processing of NOTIFY Requests
The information from the vehicle's VUA sent in the body of NOTIFY to
the watcher conveys the vehicle states, such as ignition or fuel
status. Subscriber processing is described in section 5.2.
Singh, et al. Expires February 2, 2008 [Page 8]
Internet-Draft Vehicle Info Event Package Aug 2007
4.9. Rate of Notifications
A notifier SHOULD NOT generate notifications for a single vehicle at
a rate greater than once every 180 seconds in normal driving
conditions. When the vehicle's engine is turned on or off, several
notifications may be issued over the short period of time (10
seconds). In collision or accident situation, several notifications
may be attempted to be sent within one second.
5. XML Schema
The following is the schema definition of the vehicle-info format:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:vehicle-info"
xmlns:car="urn:ietf:params:xml:ns:vehicle-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:include schemaLocation="vehicle-info-schema.xsd"/>
<xs:element name="vehicle-info" type="car:vehicle-info"/>
<xs:annotation>
<xs:documentation>
Root element for vehicle-info package.
</xs:documentation>
</xs:annotation>
<xs:complexType name="vehicle-info">
<xs:sequence>
<xs:element name="vehicle-description" minOccurs="0"
maxOccurs="1"/>
<xs:element name="vehicle-state" minOccurs="0"
maxOccurs="1"/>
<xs:element name="vehicle-diagnostics" minOccurs="0"
maxOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI" use="required"/>
<xs:attribute name="state" type="xs:string"/>
<xs:attribute name="version" type="xs:unsignedInt"/>
</xs:complexType>
<xs:complexType name="vehicle-description">
Singh, et al. Expires February 2, 2008 [Page 9]
Internet-Draft Vehicle Info Event Package Aug 2007
<xs:sequence>
<xs:element name="description" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>
Type of vehicle: truck, SUV, 4 door sedan.
</xs:documentation>
</xs:annotation>
<xs:element name="make" type="xs:string" minOccurs="0"
maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Manufacturer.
</xs:documentation>
</xs:annotation>
<xs:element name="year" type="xs:Integer"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Year vehicle was made.
</xs:documentation>
</xs:annotation>
<xs:element name="VIN" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>
Vehicle Identification Number.
</xs:documentation>
</xs:annotation>
<xs:element name="color" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Vehicle body color.
</xs:documentation>
</xs:annotation>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="vehicle-state">
<xs:sequence>
<xs:element name="status" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>
Vehicle is powered on (with engine running or not)
or not
</xs:documentation>
</xs:annotation>
Singh, et al. Expires February 2, 2008 [Page 10]
Internet-Draft Vehicle Info Event Package Aug 2007
<xs:element name="ignition" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Engine running or not.
</xs:documentation>
</xs:annotation>
<xs:element name="movement" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Vehicle is moving
or stopped or parked.
</xs:documentation>
</xs:annotation>
<xs:element name="fuel" type="xs:Double"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Fuel in the fuel tank.
</xs:documentation>
</xs:annotation>
<xs:element name="temperature" type="xs:Integer"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Temperature inside the
vehicle.
</xs:documentation>
</xs:annotation>
<xs:element name="passengers"
type="xs:nonNegativeInteger" minOccurs="0"
maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Number of passengers
(driver included).
</xs:documentation>
</xs:annotation>
<xs:element name="ac" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Air Conditioning unit
status.
</xs:documentation>
</xs:annotation>
<xs:element name="radio" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Radio status.
</xs:documentation>
</xs:annotation>
<xs:element name="airbags" type="xs:string"
Singh, et al. Expires February 2, 2008 [Page 11]
Internet-Draft Vehicle Info Event Package Aug 2007
minOccurs="0" maxOccurs="1"/>
<xs:annotation>
<xs:documentation>Airbags status.
</xs:documentation>
</xs:annotation>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:attribute name="unit" type="xs:string"/>
<xs:annotation>
<xs:documentation>Measurement unit.
</xs:documentation>
</xs:annotation>
</xs:sequence>
</xs:complexType>
<xs:complexType name="vehicle-diagnostics">
<xs:sequence>
<xs:element name="obdii" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
<xs:annotation>
<xs:documentation>OBDII diagnostic code
description or value of the Real Time Data measurement.
</xs:documentation>
</xs:annotation>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:attribute name="DTC" type="xs:string"/>
<xs:annotation>
<xs:documentation>Diagnostic Trouble Code.
</xs:documentation>
</xs:annotation>
<xs:attribute name="RTData" type="xs:string"/>
<xs:annotation>
<xs:documentation>Real Time Data measurement.
</xs:documentation>
</xs:annotation>
<xs:attribute name="unit" type="xs:string"/>
<xs:annotation>
<xs:documentation>Measurement unit.
</xs:documentation>
</xs:annotation>
</xs:sequence>
</xs:complexType>
</xs:schema>
Figure 2: XML schema
Singh, et al. Expires February 2, 2008 [Page 12]
Internet-Draft Vehicle Info Event Package Aug 2007
6. Examples
6.1. Example of vehicle-info XML
As mentioned earlier, the vehicle-info XML-based data should be
treated as a data structure, open for contributions from vehicle
telematics industry and standards boides. An example is given below:
<?xml version="1.0" encoding="utf-8" ?>
<vehicle-info xmlns="urn:ietf:params:xml:ns:vehicle-info"
entity="sip:44G44444H4444@avis.com"
state="full"
version="1" >
<vehicle-description>
<description>4 door sedan</description>
<make>Toyota</make>
<model>Camry</model>
<year>2003</year>
<VIN>44G44444H4444</VIN>
<color>silver</color>
</vehicle-description>
<vehicle-state>
<status>open</status>
<ignition>on</ignition>
<movement>moving</movement>
<fuel unit="gallon">3</fuel>
<temperature unit="F">68</temperature>
<passengers>3</passengers>
<ac>on</ac>
<radio>on</radio>
<airbags>closed</airbags>
</vehicle-state>
<vehicle-diagnostics>
<obdii DTC="P0120">Throttle Switch Malfunction</obdii>
<obdii DTC="P1390">Timing Belt Skipped a Tooth</obdii>
<obdii RTData="EngineCoolantTemp" unit="F">20</obdii>
<obdii RTData="VehicleSpeed" unit="Miles">55</obdii>
<obdii RTData="EngineRPM" unit="RPM">3257</obdii>
</vehicle-diagnostics>
</vehicle-info>
Figure 3: XML example
Singh, et al. Expires February 2, 2008 [Page 13]
Internet-Draft Vehicle Info Event Package Aug 2007
6.2. Message Flow Example
The examples below shows SIP message flow for managing a vehicle and
a user as described in section 3. Standard responses are omitted.
Watcher (fleet management application) issues a SUBSCRIBE request,
using the vehicle-info event package, to a vehicle with the VIN
number 44G44444H4444 towards the application server
(app.example.com).
SUBSCRIBE sip:44G44444H4444@avis.com SIP/2.0
Via: SIP/2.0/TCP watcher.app.example.com;branch=z9hG4bKnashds7
To: <sip:44G44444H4444@avis.com >
From: <sip:watcher@example.com>;tag=ght5
Call-ID: 1234@app.example.com
CSeq: 1001 SUBSCRIBE
Max-Forwards: 70
Event: vehicle-info
Accept: application/vehicle-info+xml
Contact: <sip:watcher@example.com>
Expires: 86400
Content-Length: 0
Aplication server at app.example.com sends
SUBSCRIBE using the vehicle-info event package to the
Vehicle UA (VUA) at vua.avis.com.
SUBSCRIBE sip:44G44444H4444@avis.com SIP/2.0
Via: SIP/2.0/TCP app.example.com;branch=z9hG4bKnashds7
To: <sip:44G44444H4444@avis.com >
From: <sip:app.example.com>;tag=xfg9
Call-ID: 1234@app.example.com
CSeq: 1234 SUBSCRIBE
Max-Forwards: 70
Event: vehicle-info
Accept: application/vehicle-info+xml
Contact: <sip:app.example.com>
Expires: 86400
Content-Length: 0
The NOTIFY request sent by the VUA.
NOTIFY sip:app.example.com SIP/2.0
Via: SIP/2.0/TCP vua.avis.com;branch= z9hG4bKnashds7
From: <sip: 44G44444H4444@avis.com>;tag=ffd2
To: <sip:app.example.com>;tag=xfg9
Singh, et al. Expires February 2, 2008 [Page 14]
Internet-Draft Vehicle Info Event Package Aug 2007
Call-ID: 1234@app.example.com
Event: vehicle-info
Subscription-State: active;expires=86660
Max-Forwards: 70
CSeq: 8775 NOTIFY
Contact: <sip:vua.avis.com>
Content-Type: application/vehicle-info+xml
Content-Length: ...
The application server passes on the NOTIFY message
to the watcher.
NOTIFY sip:watcher@example.com SIP/2.0
Via: SIP/2.0/TCP app.example.com;branch=z9hG4bKna998sk
From: <sip:44G44444H4444@avis.com >;tag=ffff
To: <sip:watcher@example.com>;tag=ght5
Call-ID: 1234@app.example.com
Event: vehicle-info
Subscription-State: active;expires=86660
Max-Forwards: 70
CSeq: 1104 NOTIFY
Contact: sip:app.example.com
Content-Type: application/vehicle-info+xml
Content-Length: ...
Watcher issues another SUBSCRIBE request using
the presence event package to the vehicle with the VIN number
44G44444H4444 towards the application server (app.example.com).
Application server sends SUBSCRIBE request to the
Vehicle Location User Agent (VLUA).
SUBSCRIBE sip:44G44444H4444@avis.com SIP/2.0
Via: SIP/2.0/TCP app.example.com;branch=z9hG4bKnashds7
To: <sip:44G44444H4444@avis.com >
From: <sip:app.example.com>;tag=847a
Call-ID: 1234@app.example.com
CSeq: 1887 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml
Contact: <sip:app.example.com>
Expires: 600
Content-Length: 0
The VLUA sends the NOTIFY message.
NOTIFY sip:app.example.com SIP/2.0
Via: SIP/2.0/TCP vlua.avis.com;branch= z9hG4bKnashds7
Singh, et al. Expires February 2, 2008 [Page 15]
Internet-Draft Vehicle Info Event Package Aug 2007
From: <sip: 44G44444H4444@avis.com>;tag=bb45
To: <sip:app.example.com>;tag=847a
Call-ID: 1234@app.example.com
Event: presence
Subscription-State: active;expires=660
Max-Forwards: 70
CSeq: 9103 NOTIFY
Contact: <sip:vua.avis.com>
Content-Type: application/pidf+xml
Content-Length: ...
The body of NOTIFY request sent by VLUA notifier is a
PIDF-LO construct. The application
server passes on the NOTIFY message to the watcher.
NOTIFY sip:watcher@example.com SIP/2.0
Via: SIP/2.0/TCP app.example.com;branch=z9hG4bKna998sk
From: <sip:44G44444H4444@avis.com >;tag=ffff
To: <sip:watcher@example.com>;tag=ght5
Call-ID: 1234@app.exam ple.com
Event: presence
Subscription-State: active;expires=660
Max-Forwards: 70
CSeq: 1104 NOTIFY
Contact: sip:app.example.com
Content-Type: application/pidf+xml
Content-Length: ...
Figure 4: Vehicle-info event package message flow 1
In case of a user's presence data management application, the watcher
issues a SUBSCRIBE request to the user, alice@example.com, towards
the application server (app.example.com). Alice is currently driving
a rented car.
Singh, et al. Expires February 2, 2008 [Page 16]
Internet-Draft Vehicle Info Event Package Aug 2007
SUBSCRIBE sip:44G44444H4444@avis.com SIP/2.0
Via: SIP/2.0/TCP app.example.com;branch=z9hG4bKnashds7
To: <sip:44G44444H4444@avis.com >
From: <sip:alice@example.com>;tag=ght5
Call-ID: 1234@app.example.com
CSeq: 1001 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml
Contact: <sip: alice@example.com >
Expires: 86400
Content-Length: 0
Figure 5: Vehicle-info event package message flow 2
The application server issues a SUBSCRIBE request to the user's
presentity (presence event package). It will get a NOTIFY message
from user's presentity. Application server checks for the user-
vehicle association. If the association exists, it then issues
SUBSCRIBE requests to to the VUA (vehicle-info event package) and
VLUA (presence event package). The format of these SUBSCRIBE and
NOTIFY requests is identical to the one given in message flow 1.
NOTIFY messages from user's presentity, VUA and VLUA will be used to
create user's presence information. This information will be in the
form of expanded PIDF. This expanded PIDF will be sent to the
requesting watcher as a NOTIFY request.
7. Security Considerations
7.1. Authorization Considerations
The vehicle-info information can be sensitive because it can be used
to infer presence information of users in the vehicle. Hence,
vehicle's information must be distributed to watcher's who are
authorized to view user's presence informaion.
8. IANA Considerations
A future version of this document will provide IANA considerations.
9. Acknowledgements
10. References
Singh, et al. Expires February 2, 2008 [Page 17]
Internet-Draft Vehicle Info Event Package Aug 2007
10.1. Normative References
[1] "Intelligent Transportation Society of America, available at:
http://www.itsa.org/", April 2004.
[2] "Global System for Telematics Forum, at:
http://www.gstforum.org/en/home.htm", April 2004.
[3] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[5] "Geographic information - Geography Markup Language (GML),
OpenGIS 03-105r1, available at:
http://portal.opengeospatial.org/files/?artifact_id=4700",
April 2004.
[6] "On Board Diagnostic (OBD), available at: http://obdii.com",
April 2004.
[7] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[8] Schulzrinne, H., "Timed Presence Extensions to the Presence
Information Data Format (PIDF) to Indicate Status Information
for Past and Future Time Intervals", RFC 4481, July 2006.
10.2. Informative References
[9] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[10] Singh, V., "Dynamic Feature Extensions to the Presence
Information Data Format Location Object (PIDF-LO)",
draft-singh-geopriv-pidf-lo-dynamic-00 (work in progress),
September 2006.
[11] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)",
RFC 3863, August 2004.
[12] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[13] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "Functional Description of Event Notification
Singh, et al. Expires February 2, 2008 [Page 18]
Internet-Draft Vehicle Info Event Package Aug 2007
Filtering", RFC 4660, September 2006.
[14] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML)-Based Format for
Event Notification Filtering", RFC 4661, September 2006.
[15] Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in the Presence Information Document
Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-00 (work in progress),
March 2006.
[16] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004.
[17] Polk, J. and B. Rosen, "Session Initiation Protocol Location
Conveyance", draft-ietf-sip-location-conveyance-07 (work in
progress), February 2007.
[18] Thomson, M., "Geodetic Shapes for the Representation of
Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03
(work in progress), December 2006.
[19] Schulzrinne, H., "Common Policy: A Document Format for
Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-11 (work in progress),
August 2006.
[20] Schulzrinne, H., "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-11 (work in progress), February 2007.
Authors' Addresses
Vishal Singh
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Email: vs2140@cs.columbia.edu
URI: http://www.cs.columbia.edu/~vs2140
Singh, et al. Expires February 2, 2008 [Page 19]
Internet-Draft Vehicle Info Event Package Aug 2007
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Piotr Boni
Verizon Communications
Department of Computer Science
40 Sylvan Rd
Waltham, MA 02451
US
Phone: +1 781 466 2903
Email: piotr.boni@verizon.com
Singh, et al. Expires February 2, 2008 [Page 20]
Internet-Draft Vehicle Info Event Package Aug 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Singh, et al. Expires February 2, 2008 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-23 11:21:21 |