idnits 2.17.00 (12 Aug 2021) /tmp/idnits36540/draft-singh-simple-vehicle-info-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 777. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 801. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2007) is 5431 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '20' is defined on line 702, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 708, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 712, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 716, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 719, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 723, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 727, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '1') (Obsoleted by RFC 6665) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2141 (ref. '7') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '8') == Outdated reference: draft-singh-geopriv-pidf-lo-dynamic has been published as RFC 5962 == Outdated reference: A later version (-01) exists of draft-singh-simple-membership-00 == Outdated reference: draft-ietf-geopriv-loc-filters has been published as RFC 6447 -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '21') (Obsoleted by RFC 6225) == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-07 == Outdated reference: draft-ietf-geopriv-policy has been published as RFC 6772 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Singh 3 Internet-Draft H. Schulzrinne 4 Intended status: Standards Track Columbia U. 5 Expires: January 9, 2008 P. Boni 6 Verizon 7 July 8, 2007 9 Vehicle Info Event Package 10 draft-singh-simple-vehicle-info-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 9, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines a new SIP event package for updating and 44 retrieving status information of vehicles. The information can 45 include the vehicle's status and diagnostic information distributed 46 by vehicle telematics systems. This event package is useful for 47 fleet management and vehicle tracking applications. The event 48 package is called vehicle-info event package and is applicable to all 49 types of vehicles like cars, buses, ships and aircraft. However, 50 this document focuses on automobiles. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Vehicle-info Event Package Description . . . . . . . . . . . . 4 57 3.1. Message Flow Diagram . . . . . . . . . . . . . . . . . . . 5 58 3.2. Vehicle Status Information . . . . . . . . . . . . . . . . 6 59 3.3. Vehicle Location Information . . . . . . . . . . . . . . . 7 60 4. Vehicle-info Event Package . . . . . . . . . . . . . . . . . . 7 61 4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 7 62 4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 7 63 4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 7 64 4.4. Subscription Duration . . . . . . . . . . . . . . . . . . 7 65 4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8 66 4.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8 67 4.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8 68 4.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 8 69 4.9. Rate of Notifications . . . . . . . . . . . . . . . . . . 9 70 5. The Vehicle-info Document . . . . . . . . . . . . . . . . . . 9 71 5.1. Document Description . . . . . . . . . . . . . . . . . . . 9 72 5.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Example of vehicle-info XML . . . . . . . . . . . . . . . . . 13 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 7.1. Authorization Considerations . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 82 Intellectual Property and Copyright Statements . . . . . . . . . . 18 84 1. Introduction 86 The Session Initiation Protocol (SIP) events framework described in 87 RFC3265 [1] defines subscription-based event distribution mechanism 88 for sending notification of events. The RFC 3265 requires the events 89 to be related to the SIP state. However, there are many benefits of 90 using such framework for delivering non-SIP related notifications. 91 Also, there seems to be an interest in the community for application 92 of SIP event mechanism to events not related to SIP [10]. 94 Today, vehicle information is processed and communicated via vehicle 95 telematics systems, which employ a multitude of standards and are 96 used for a number of purposes, including remote diagnostics and 97 reporting vehicle's mechanical and electronic problems or failures. 98 Increasingly, navigational and entertainment applications are being 99 deployed within such frameworks such as ITSA [11], GST [12]. 101 The vehicle information can be used for monitoring and tracking 102 purposes. For example, location information and movement related 103 information (speed, acceleration and direction) can be used to 104 perform location tracking and to ensure that the vehicle is moving 105 within acceptable speed limits. The vehicle's location and moving 106 status information can be described using RFC 4119 [2] and moving 107 object status tracking [13] using the presence event package. 109 Other information useful for monitoring includes vehicle status 110 information containing vehicle's state (e.g., ignition status) and 111 vehicle's diagnostic information. Some of the vehicle's information 112 can be directly used to infer presence information of users of the 113 vehicle whereas other information is only useful in vehicle 114 management (e.g., by car-rental companies). 116 The vehicle's information can be divided into two parts: the core 117 vehicular information, that is a vehicle status, and the location and 118 connectivity-related information, already standardized in presence 119 and location specifications in RFC4119 [2]. 121 The vehicle-info event package as described in this document can be 122 used to distribute core vehicular information. The event package 123 aggregates vehicle information from telematics systems into an XML- 124 based data structure. This document specifies the schema of the 125 proposed event package. The schema contains core vehicular 126 information as well as other information, some of which can be mapped 127 to device characteristics as defined in the presence data model. The 128 proposed schema should be treated as a seed document, open for 129 contributions from vehicle telematics industry and their standards 130 institutions. 132 2. Terminology 134 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 135 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 136 and "OPTIONAL" are to be interpreted as described in RFC 2119 [3]. 138 This document uses GML Moving Vehicle terms as described in GML [4]. 139 It also introduces terminology from the On Board Diagnostics 140 standard's (OBD-II) [5]. 142 3. Vehicle-info Event Package Description 144 This event package defines an XML-based schema for information that 145 can be used to manage vehicles. It also shows how an application can 146 subscribe to the information related to a vehicle or use this 147 information to derive presence information of a user. An application 148 will subscribe to a vehicle using vehicle-info event package. 150 An application may use presence event package to subscribe to the 151 vehicle's location and moving status information. 153 If the application is managing a vehicle (e.g., fleet management 154 application), it sends SUBSCRIBE requests using the vehicle-info 155 event package and presence event package to the vehicle's entity. 156 The application will render the vehicle information in the specified 157 XML format or in other formats such as PIDF [14], depending on the 158 application processing functions. 160 Alternatively, if the application is managing user's (driver or 161 passenger) presence data, it may compose user's presence information 162 with vehicle as a device, which contributes to user's presence. The 163 application sends SUBSCRIBE requests to vehicle's entity using the 164 vehicle-info and presence event package. 166 A membership event package [15] can be used to track changes in 167 membership in groups such as vehicle. If a user is a member of the 168 vehicle group, a presence server would compose user's presentity PIDF 169 based - among others - on the vehicle information provided. User may 170 become a member of the vehicle group when a vehicle sensor discovers 171 user's identity, using - for example - a Bluetooth technology or a 172 smart card readout. However, the details of such person-vehicle 173 association are beyond the scope of this document. 175 The information the vehicle-info event package provides consists of 176 internal vehicle state data and the diagnostics. 178 3.1. Message Flow Diagram 180 +-----------+ +----------------+ +-----------+ +-------+ 181 | | | | | | | | 182 | Vehicle | |Vehicle Location| |Application| |Watcher| 183 | VUA | | UA (VLUA) | | (PS) | | | 184 +-----------+ +----------------+ +-----------+ +-------+ 185 | | | | 186 | | | | 187 | | | SUBSCRIBE | 188 | | |<------------------| 189 | | | Event:presence | 190 | | | | 191 | SUBSCRIBE | | | 192 |<-------------------------------------| | 193 | Event: vehicle-info | | 194 | | | | 195 | NOTIFY | | | 196 |------------------+------------------>| | 197 | Event: vehicle-info | | 198 | | | | 199 | | SUBSCRIBE | | 200 | |<------------------| | 201 | | Event:presence | | 202 | | | | 203 | | NOTIFY | | 204 | |------------------>| | 205 | | Event:presence | | 206 | | | NOTIFY | 207 | | |------------------>| 208 | | | Event:expanded | 209 | | | PIDF | 211 Figure 1: Vehicle-info event package to derive presence information 212 (driver's PUA not shown) 214 When an application or a presence server receives a subscription 215 request for a user currently in a vehicle, the presence server uses 216 the membership event package to check if the user is inside the 217 vehicle and then generates SUBSCRIBE requests. These requests are 218 issued to presence agent of user, vehicle's presence user agent 219 (VLUA), and vehicle's user agent for vehicle-info (VUA). VUA and 220 VLUA are logical entities and can be collocated. 222 When NOTIFY messages from VUA and VLUA reach the presence server, 223 they will be used to compose user's presence state and to send 224 expanded PIDF to the requesting watcher. For example, the 225 element in PIDF/RPID might have an tag that indicates 226 'driving' if the car is moving. Also, the vehicle location 227 information, if present, will be included in user's expanded PIDF. 228 When user presence state already contains location, e.g., from a GPS- 229 enabled cell phone, then there is a need to reconcile such 230 information, obtained from two different location sources. 232 3.2. Vehicle Status Information 234 Vehicle status information is subdivided into the vehicle state 235 information and the diagnostics data. 237 Vehicle status information is only partially standardized today. 238 Telematics systems use different specifications to describe vehicle 239 data. Manufacturers of vehicle control devices provide different 240 static and dynamic information about the vehicle. In this document, 241 we have focused on the information provided by OBD-II [5]. The 242 OBD-II data is referred to as the diagnostics data. The vehicle 243 state data may come from other, non OBD-II, systems. 245 OBD-II stands for the On-Board Diagnostics, generation II. OBD-II is 246 a set of rules and regulations each car manufacturer has to follow to 247 have their Engine Management System pass the U.S. federal emissions 248 tests. It also allows to run a set of comprehensive diagnostics 249 related to the engine and other parts of the vehicle using OBD-II 250 scan tools. Most modern vehicles are OBD-II equipped. Diagnostics 251 can be performed locally or remotely. OBD-II specification uses the 252 Diagnostic Trouble Codes (DTC), which can be stored in the vehicle's 253 Powertrain Control Module (PCM) and retrieved or obtained on demand 254 by running a new diagnostic test. 256 The DTC is a five-byte code. The first byte is an ASCII character 257 that identifies the part of the vehicle where the fault occurred. It 258 can assume the values P, B, C or U. For example, "P" refers to the 259 engine or transmission system. The second byte can take value of 260 digit "0" for common fault code or "1" for proprietary one. The 261 third byte indicates the vehicle subsystem at fault and can have 262 values from 1 to 8. For example, "2" refers to a fuel system. The 263 fourth and fifth byte indicate a specific code number for a given 264 fault. Each DTC has also a short text associated with it. 266 The OBD-II based system can also provide the real time data such as 267 engine coolant temperature, different types of fuel system data, 268 engine RPM and speed. 270 Example of vehicle information data is presented in Section 6. 272 3.3. Vehicle Location Information 274 Assuming the vehicle or the agent representing it (e.g., VLUA in 275 Figure 1) contains the location information about itself, it can 276 convey this information using PIDF-LO [2], presence event package 277 [16]. This requires the application (e.g., user's presence server) 278 to send SUBSCRIBE request using the presence event package to receive 279 the location information and its updates. 281 If the user is a member of the vehicle group, the location 282 information can be directly used to determine the user's location. 283 Otherwise, location information only refers to the position of the 284 vehicle. 286 4. Vehicle-info Event Package 288 4.1. Event Package Name 290 The name of this event package is "vehicle-info". This package name 291 is carried in the SIP Event and Allow-Events header fields, as 292 defined in RFC 3265 [1]. 294 4.2. Event Package Parameters 296 RFC 3265 [1] allows event packages to define additional parameters 297 carried in the Event header field. This event package does not 298 define additional parameters. 300 4.3. SUBSCRIBE Bodies 302 The SUBSCRIBE bodies may contain the watcher filters (RFC 4660) [17] 303 to specify triggers of when and what data the watcher is interested 304 in. The mechanism to specify the filter remains same as specified in 305 event filter format document [18]. 307 4.4. Subscription Duration 309 The default expiration time for subscription to vehicle-info event 310 package will be one day. Normally, a vehicle will be allocated to a 311 task at a granularity of one day. However, this may change depending 312 on the usage scenario, in which case the alternative expiration time 313 will be specified by a subscriber in the Expires header field. 315 4.5. NOTIFY Bodies 317 According to RFC 3265, the NOTIFY message contains bodies in a format 318 listed in the Accept header field of the SUBSCRIBE request or a 319 package-specific default if the Accept header field was omitted from 320 the SUBSCRIBE request. All subscribers and notifiers MUST support 321 the "application/vehicle-info+xml" data format described in Section 322 4. By default, if no Accept header field is specified in a SUBSCRIBE 323 request, the NOTIFY request will contain a body in the "application/ 324 vehicle-info+xml" data format. If the Accept header field is 325 present, it MUST include "application/vehicle-info+xml" and MAY 326 include any other types. 328 4.6. Notifier Processing of SUBSCRIBE Requests 330 RFC 3265 specifies that packages should define any package-specific 331 processing of SUBSCRIBE requests at a notifier, specifically with 332 regards to authentication and authorization. 334 Vehicle dynamic state information is a sensitive data. Therefore, 335 all subscriptions to it SHOULD be authenticated and authorized before 336 approval. Authentication MAY be performed by the techniques 337 available through SIP, such as digest, S/MIME, TLS. Authorization 338 policies for access need to be administered. We assume that in most 339 cases applications will be subscribers, in which case authorization 340 policies will be provided ahead of time. 342 SUBSCRIBE requests are addressed to the vehicle ID, typically 343 vehicle's VIN, for example, 44G44444H4444@avis.com. The notifier 344 will verify whether vehicle id is in the scope of Vehicle UA (VUA). 345 The VUA may be collocated with the vehicle or it can be a network- 346 based entity collocated with other VUA's. 348 4.7. Notifier Generation of NOTIFY Requests 350 Once the subscription is accepted, the notifier MAY send a NOTIFY 351 request with the body of the most recent vehicle information data it 352 has. Typically, it will send the NOTIFY request when any data item 353 in the vehicle information data has changed. The body of the NOTIFY 354 MUST be sent using one of the types listed in the Accept header field 355 in the most recent SUBSCRIBE request, or using the type "application/ 356 vehicle-info+xml" if no Accept header field was present. 358 4.8. Subscriber Processing of NOTIFY Requests 360 The information from the vehicle's VUA sent in the body of NOTIFY 361 request to the watcher conveys the vehicle states, such as ignition 362 or fuel status. 364 4.9. Rate of Notifications 366 A notifier SHOULD NOT generate notifications for a single vehicle at 367 a rate greater than once every 180 seconds in normal driving 368 conditions. When the vehicle's engine is turned on or off, several 369 notifications may be issued over the short period of time (10 370 seconds). In collision or accident situation, several notifications 371 may be attempted to be sent within one second. 373 5. The Vehicle-info Document 375 A vehicle-info document is an XML document [6] that MUST be well- 376 formed and SHOULD be valid. A vehicle-info document MUST be based on 377 XML 1.0 and MUST be encoded using UTF-8. This specification makes 378 use of XML namespaces for identifying vehicle-info documents. The 379 namespace URI for elements defined by this specification is a URN 380 (RFC 2141) [7], using the namespace identifier 'ietf' defined by RFC 381 2648 [8] and extended by RFC 3688 [9]. This URN is 382 urn:ietf:params:xml:ns:vehicle-info 384 5.1. Document Description 386 A vehicle-info document starts with the root element tag . The root element consists of two child elements, and , described below. Other elements 389 from different namespaces MAY be present for extensions; elements or 390 attributes from unknown namespaces MUST be ignored. 392 There are two attributes associated with the element, 393 both of which MUST be present: "version" and "state". The "version" 394 attribute is a timestamp expressed in seconds. It MUST be 395 represented by a 32 bit integer. Synchronization of vehicle-info 396 documents, generated by multiple publishers of the vehicle-related 397 information, will be easier with timestamping. The "state" attribute 398 indicates whether the document contains the full vehicle-info state, 399 or only the information which has recently changed (partial). 401 The element consists of one or more child elements. 402 These elements provide information on the vehicle internal state. 403 Currently, these child elements may include: 405 The element - describing whether the vehicle is 406 accessible ("open") or not ("closed"). 408 The element - describing whether the engine is 409 running ("on/off"). 411 The and elements - providing the data on 412 fuel in the tank and the temperature. The temperature may be 413 reported as the vehicle's inside temperature or engine temperature or 414 other. The temperature information may be specified in more detailed 415 form in the future. There is the "unit" attribute associated with 416 these two elements, which MUST be present. It specifies the 417 measurement unit. 419 The element - describing how many passengers are 420 in the car. 422 The element - describing the status of the airbags 423 ("open/closed"). 425 The element MAY contain other elements and attributes 426 from different namespaces for extensions; elements or attributes from 427 unknown namespaces MUST be ignored. 429 The element consists of one or more child 430 elements described in detail in section 3.2 . There is a 431 "DTC" attribute associated with the element. The attribute contains 432 a five-byte Diagnostic Trouble Code (DTC) from the Powertrain Control 433 Module. The element contains a short text related to a specific DTC. 434 Alternatively, the element may have a pair of the "RTData" 435 and the "unit" attributes, which provide the description of the 436 monitored real-time activity and the measurement unit. 438 The element MAY contain other elements and 439 attributes from different namespaces for extensions; elements or 440 attributes from unknown namespaces MUST be ignored. 442 5.2. XML Schema 444 The following is the schema definition of the vehicle-info format: 446 447 453 455 456 457 458 Root element for vehicle-info package. 459 460 462 463 464 466 468 470 471 472 473 475 476 477 478 480 481 482 Vehicle is powered on (with engine running or not) 483 or not 484 485 486 488 489 Engine running or not. 490 491 492 494 495 Fuel in the fuel tank. 496 497 498 500 501 Temperature inside the 502 vehicle. 503 504 505 508 509 Number of passengers 510 (driver included). 511 512 513 515 516 Airbags status. 517 518 519 521 522 523 Measurement unit. 524 525 526 527 528 529 530 532 533 OBD-II diagnostic code 534 description or value of the Real Time Data measurement. 535 536 537 539 540 541 Diagnostic Trouble Code. 542 543 544 545 546 Real Time Data measurement. 547 548 549 550 551 Measurement unit. 552 553 555 556 558 560 Figure 2: XML schema 562 6. Example of vehicle-info XML 564 As mentioned earlier, the vehicle-info XML-based data should be 565 treated as a data structure, open for contributions from vehicle 566 telematics industry and standards bodies. An example is given below: 568 569 573 574 open 575 on 576 3.0 577 68 578 3 579 closed 580 581 582 Throttle Switch Malfunction 583 Timing Belt Skipped a Tooth 584 20 585 55 586 3257 587 588 590 Figure 3: XML example 592 7. Security Considerations 593 7.1. Authorization Considerations 595 There are obvious similarities between this section and the Security 596 Considerations section of the membership event package document [15]. 598 The group vehicle-info data contains privacy sensitive information as 599 it can be used to deduce more detailed presence information of the 600 user from multiple event packages of different entities. 601 Consequently, access to the vehicle-info data and to the extended 602 presence information MUST be controlled and be unavailable to 603 unauthorized entities. 605 A vehicle management company may be authorized to obtain the vehicle 606 information using vehicle-info event package. A vehicle management 607 server may allow the vehicle-info data to be passed to a user 608 presentity only if the user is inside ths vehicle. 610 In the car rental scenario example, apart from car rental company, 611 only the presentity associated with the car is authorized by the car 612 rental company to get vehicle-info data for the car. The same 613 applies to the vehicle location data. The presentity may have this 614 data aggregated into its extended presence information. 616 In many cases, other users may get the vehicle-info data indirectly. 617 Watchers, who want to get presentity's extended presence information 618 can obtain it by subscribing to presentity using the presence event 619 package. The PA would send presence information based on 620 presentity's privacy preferences as described in the common policy 621 specification [19]. 623 8. IANA Considerations 625 A future version of this document will provide IANA considerations. 627 9. Acknowledgements 629 10. References 631 10.1. Normative References 633 [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 634 Notification", RFC 3265, June 2002. 636 [2] Peterson, J., "A Presence-based GEOPRIV Location Object 637 Format", RFC 4119, December 2005. 639 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 640 Levels", RFC 2119, BCP 14, March 1997. 642 [4] "Geographic information - Geography Markup Language (GML), 643 OpenGIS 03-105r1, available at: 644 http://portal.opengeospatial.org/files/?artifact_id=4700", 645 April 2004. 647 [5] "On Board Diagnostic (OBD), available at: http://obdii.com", 648 April 2004. 650 [6] "Extensible Markup Language (XML) 1.0 (Second Edition), World 651 Wide Web Consortium FirstEdition REC-xml-20001006, available 652 at: http://www.w3.org/TR/2000/REC-xml-20001006", October 2000. 654 [7] Moats, R., "URN Syntax", RFC 2141, May 1997. 656 [8] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 657 August 1999. 659 [9] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 660 January 2004. 662 10.2. Informative References 664 [10] Garcia-Martin, M. and H. Schulzrinne, "Notification of General 665 Events Using the Session Initiation Protocol (SIP) Event 666 Notification Framework", draft-garcia-sipping-general-events-00 667 (work in progress), May 2007. 669 [11] "Intelligent Transportation Society of America, available at: 670 http://www.itsa.org/", April 2004. 672 [12] "Global System for Telematics Forum, at: 673 http://www.gstforum.org/en/home.htm", April 2004. 675 [13] Singh, V., "Dynamic Feature Extensions to the Presence 676 Information Data Format Location Object (PIDF-LO)", 677 draft-singh-geopriv-pidf-lo-dynamic-01 (work in progress), 678 March 2007. 680 [14] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 681 J. Peterson, "Presence Information Data Format (PIDF)", 682 RFC 3863, August 2004. 684 [15] Singh, V., "Membership Event Package", 685 draft-singh-simple-membership-00 (work in progress), July 2007. 687 [16] Rosenberg, J., "A Presence Event Package for the Session 688 Initiation Protocol (SIP)", RFC 3856, August 2004. 690 [17] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 691 Requena, "Functional Description of Event Notification 692 Filtering", RFC 4660, September 2006. 694 [18] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 695 Requena, "An Extensible Markup Language (XML)-Based Format for 696 Event Notification Filtering", RFC 4661, September 2006. 698 [19] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 699 J., and J. Rosenberg, "Common Policy: A Document Format for 700 Expressing Privacy Preferences", RFC 4745, February 2007. 702 [20] Mahy, R., "A Document Format for Filtering and Reporting 703 Location Notications in the Presence Information Document 704 Format Location Object (PIDF-LO)", 705 draft-ietf-geopriv-loc-filters-01 (work in progress), 706 March 2007. 708 [21] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 709 Configuration Protocol Option for Coordinate-based Location 710 Configuration Information", RFC 3825, July 2004. 712 [22] Schulzrinne, H., "Timed Presence Extensions to the Presence 713 Information Data Format (PIDF) to Indicate Status Information 714 for Past and Future Time Intervals", RFC 4481, July 2006. 716 [23] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 717 Polk, "Geopriv Requirements", RFC 3693, February 2004. 719 [24] Polk, J. and B. Rosen, "Session Initiation Protocol Location 720 Conveyance", draft-ietf-sip-location-conveyance-07 (work in 721 progress), February 2007. 723 [25] Thomson, M., "Geodetic Shapes for the Representation of 724 Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03 725 (work in progress), December 2006. 727 [26] Schulzrinne, H., "Geolocation Policy: A Document Format for 728 Expressing Privacy Preferences for Location Information", 729 draft-ietf-geopriv-policy-12 (work in progress), May 2007. 731 Authors' Addresses 733 Vishal Singh 734 Columbia University 735 Department of Computer Science 736 450 Computer Science Building 737 New York, NY 10027 738 US 740 Email: vs2140@cs.columbia.edu 741 URI: http://www.cs.columbia.edu/~vs2140 743 Henning Schulzrinne 744 Columbia University 745 Department of Computer Science 746 450 Computer Science Building 747 New York, NY 10027 748 US 750 Phone: +1 212 939 7004 751 Email: hgs@cs.columbia.edu 752 URI: http://www.cs.columbia.edu/~hgs 754 Piotr Boni 755 Verizon Communications 756 40 Sylvan Rd 757 Waltham, MA 02451 758 US 760 Phone: +1 781 466 2903 761 Email: piotr.boni@verizon.com 763 Full Copyright Statement 765 Copyright (C) The IETF Trust (2007). 767 This document is subject to the rights, licenses and restrictions 768 contained in BCP 78, and except as set forth therein, the authors 769 retain all their rights. 771 This document and the information contained herein are provided on an 772 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 773 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 774 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 775 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 776 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 777 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 779 Intellectual Property 781 The IETF takes no position regarding the validity or scope of any 782 Intellectual Property Rights or other rights that might be claimed to 783 pertain to the implementation or use of the technology described in 784 this document or the extent to which any license under such rights 785 might or might not be available; nor does it represent that it has 786 made any independent effort to identify any such rights. Information 787 on the procedures with respect to rights in RFC documents can be 788 found in BCP 78 and BCP 79. 790 Copies of IPR disclosures made to the IETF Secretariat and any 791 assurances of licenses to be made available, or the result of an 792 attempt made to obtain a general license or permission for the use of 793 such proprietary rights by implementers or users of this 794 specification can be obtained from the IETF on-line IPR repository at 795 http://www.ietf.org/ipr. 797 The IETF invites any interested party to bring to its attention any 798 copyrights, patents or patent applications, or other proprietary 799 rights that may cover technology that may be required to implement 800 this standard. Please address the information to the IETF at 801 ietf-ipr@ietf.org. 803 Acknowledgment 805 Funding for the RFC Editor function is provided by the IETF 806 Administrative Support Activity (IASA).