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 element in PIDF/RPID might have an 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: Root element for vehicle-info package. Singh, et al. Expires February 2, 2008 [Page 9] Internet-Draft Vehicle Info Event Package Aug 2007 Type of vehicle: truck, SUV, 4 door sedan. Manufacturer. Year vehicle was made. Vehicle Identification Number. Vehicle body color. Vehicle is powered on (with engine running or not) or not Singh, et al. Expires February 2, 2008 [Page 10] Internet-Draft Vehicle Info Event Package Aug 2007 Engine running or not. Vehicle is moving or stopped or parked. Fuel in the fuel tank. Temperature inside the vehicle. Number of passengers (driver included). Air Conditioning unit status. Radio status. Airbags status. Measurement unit. OBDII diagnostic code description or value of the Real Time Data measurement. Diagnostic Trouble Code. Real Time Data measurement. Measurement unit. 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: 4 door sedan Toyota Camry 2003 44G44444H4444 silver open on moving 3 68 3 on on closed Throttle Switch Malfunction Timing Belt Skipped a Tooth 20 55 3257 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: From: ;tag=ght5 Call-ID: 1234@app.example.com CSeq: 1001 SUBSCRIBE Max-Forwards: 70 Event: vehicle-info Accept: application/vehicle-info+xml Contact: 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: From: ;tag=xfg9 Call-ID: 1234@app.example.com CSeq: 1234 SUBSCRIBE Max-Forwards: 70 Event: vehicle-info Accept: application/vehicle-info+xml Contact: 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: ;tag=ffd2 To: ;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: 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: ;tag=ffff To: ;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: From: ;tag=847a Call-ID: 1234@app.example.com CSeq: 1887 SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Contact: 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: ;tag=bb45 To: ;tag=847a Call-ID: 1234@app.example.com Event: presence Subscription-State: active;expires=660 Max-Forwards: 70 CSeq: 9103 NOTIFY Contact: 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: ;tag=ffff To: ;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: From: ;tag=ght5 Call-ID: 1234@app.example.com CSeq: 1001 SUBSCRIBE Max-Forwards: 70 Event: presence Accept: application/pidf+xml Contact: 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]