Network Working Group V. Singh Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia U. Expires: January 9, 2008 P. Boni Verizon July 8, 2007 Vehicle Info Event Package draft-singh-simple-vehicle-info-01.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 January 9, 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 vehicle-info event package and is applicable to all Singh, et al. Expires January 9, 2008 [Page 1] Internet-Draft Vehicle Info Event Package July 2007 types of vehicles like cars, buses, ships and aircraft. 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. The Vehicle-info Document . . . . . . . . . . . . . . . . . . 9 5.1. Document Description . . . . . . . . . . . . . . . . . . . 9 5.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Example of vehicle-info XML . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.1. Authorization Considerations . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Singh, et al. Expires January 9, 2008 [Page 2] Internet-Draft Vehicle Info Event Package July 2007 1. Introduction The Session Initiation Protocol (SIP) events framework described in RFC3265 [1] defines subscription-based event distribution mechanism for sending notification of events. The RFC 3265 requires the events to be related to the SIP state. However, there are many benefits of using such framework for delivering non-SIP related notifications. Also, there seems to be an interest in the community for application of SIP event mechanism to events not related to SIP [10]. 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 [11], GST [12]. 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 perform location tracking and to ensure that the vehicle is moving within acceptable speed limits. The vehicle's location and moving status information can be described using RFC 4119 [2] and moving object status tracking [13] using the presence event package. Other information useful for monitoring includes vehicle status information containing vehicle's state (e.g., ignition status) and vehicle's diagnostic 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: the core vehicular information, that is a vehicle status, and the location and connectivity-related information, already standardized in presence and location specifications in RFC4119 [2]. 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 the proposed event package. The schema contains core vehicular information as well as other information, some of which can be mapped to device characteristics 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. Singh, et al. Expires January 9, 2008 [Page 3] Internet-Draft Vehicle Info Event Package July 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 [3]. This document uses GML Moving Vehicle terms as described in GML [4]. It also introduces terminology from the On Board Diagnostics standard's (OBD-II) [5]. 3. Vehicle-info Event Package Description This event package defines an 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 using vehicle-info event package. An application may use presence event package to subscribe to the vehicle's location and moving status information. If the application is managing a vehicle (e.g., fleet management application), it sends SUBSCRIBE requests using the vehicle-info event package and presence event package to the vehicle's entity. The application will render the vehicle information in the specified XML format or in other formats such as PIDF [14], depending on the application processing functions. Alternatively, if the application is managing user's (driver or passenger) presence data, it may compose user's presence information with vehicle as a device, which contributes to user's presence. The application sends SUBSCRIBE requests to vehicle's entity using the vehicle-info and presence event package. A membership event package [15] can be used to track changes in membership in groups such as vehicle. If a user is a member of the vehicle group, a presence server would compose user's presentity PIDF based - among others - on the vehicle information provided. User may become a member of the vehicle group when a vehicle sensor discovers user's identity, using - for example - a Bluetooth technology or a smart card readout. However, the details of such person-vehicle association are beyond the scope of this document. The information the vehicle-info event package provides consists of internal vehicle state data and the diagnostics. Singh, et al. Expires January 9, 2008 [Page 4] Internet-Draft Vehicle Info Event Package July 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 uses the membership event package to check if the user is inside the vehicle 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 January 9, 2008 [Page 5] Internet-Draft Vehicle Info Event Package July 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 the vehicle state information and the 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 [5]. The OBD-II data is referred to as the diagnostics data. The vehicle state data may come from other, non OBD-II, systems. OBD-II stands for the On-Board Diagnostics, generation II. OBD-II 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 scan tools. Most modern vehicles are OBD-II equipped. Diagnostics can be performed locally or remotely. OBD-II 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 from 1 to 8. For example, "2" refers to a 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. The OBD-II based system can also provide the real time data such as engine coolant temperature, different types of fuel system data, engine RPM and speed. Singh, et al. Expires January 9, 2008 [Page 6] Internet-Draft Vehicle Info Event Package July 2007 Example of vehicle information data is presented in Section 6. 3.3. Vehicle Location Information 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 [2], presence event package [16]. This requires the application (e.g., user's presence server) to send SUBSCRIBE request using the presence event package to receive the location information and its updates. If the user is a member of the vehicle group, 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 [1]. 4.2. Event Package Parameters RFC 3265 [1] 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) [17] 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 [18]. 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 January 9, 2008 [Page 7] Internet-Draft Vehicle Info Event Package July 2007 4.5. NOTIFY Bodies According to RFC 3265, the NOTIFY message contains 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, for example, 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 a NOTIFY request with the body of the most recent vehicle information data it has. Typically, it will send the NOTIFY request 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 request to the watcher conveys the vehicle states, such as ignition or fuel status. Singh, et al. Expires January 9, 2008 [Page 8] Internet-Draft Vehicle Info Event Package July 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. The Vehicle-info Document A vehicle-info document is an XML document [6] that MUST be well- formed and SHOULD be valid. A vehicle-info document MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying vehicle-info documents. The namespace URI for elements defined by this specification is a URN (RFC 2141) [7], using the namespace identifier 'ietf' defined by RFC 2648 [8] and extended by RFC 3688 [9]. This URN is urn:ietf:params:xml:ns:vehicle-info 5.1. Document Description A vehicle-info document starts with the root element tag . The root element consists of two child elements, and , described below. Other elements from different namespaces MAY be present for extensions; elements or attributes from unknown namespaces MUST be ignored. There are two attributes associated with the element, both of which MUST be present: "version" and "state". The "version" attribute is a timestamp expressed in seconds. It MUST be represented by a 32 bit integer. Synchronization of vehicle-info documents, generated by multiple publishers of the vehicle-related information, will be easier with timestamping. The "state" attribute indicates whether the document contains the full vehicle-info state, or only the information which has recently changed (partial). The element consists of one or more child elements. These elements provide information on the vehicle internal state. Currently, these child elements may include: The element - describing whether the vehicle is accessible ("open") or not ("closed"). The element - describing whether the engine is running ("on/off"). Singh, et al. Expires January 9, 2008 [Page 9] Internet-Draft Vehicle Info Event Package July 2007 The and elements - providing the data on fuel in the tank and the temperature. The temperature may be reported as the vehicle's inside temperature or engine temperature or other. The temperature information may be specified in more detailed form in the future. There is the "unit" attribute associated with these two elements, which MUST be present. It specifies the measurement unit. The element - describing how many passengers are in the car. The element - describing the status of the airbags ("open/closed"). The element MAY contain other elements and attributes from different namespaces for extensions; elements or attributes from unknown namespaces MUST be ignored. The element consists of one or more child elements described in detail in section 3.2 . There is a "DTC" attribute associated with the element. The attribute contains a five-byte Diagnostic Trouble Code (DTC) from the Powertrain Control Module. The element contains a short text related to a specific DTC. Alternatively, the element may have a pair of the "RTData" and the "unit" attributes, which provide the description of the monitored real-time activity and the measurement unit. The element MAY contain other elements and attributes from different namespaces for extensions; elements or attributes from unknown namespaces MUST be ignored. 5.2. XML Schema The following is the schema definition of the vehicle-info format: Singh, et al. Expires January 9, 2008 [Page 10] Internet-Draft Vehicle Info Event Package July 2007 Root element for vehicle-info package. Vehicle is powered on (with engine running or not) or not Engine running or not. Fuel in the fuel tank. Temperature inside the vehicle. Number of passengers (driver included). Airbags status. Measurement unit. OBD-II diagnostic code description or value of the Real Time Data measurement. Diagnostic Trouble Code. Real Time Data measurement. Measurement unit. Singh, et al. Expires January 9, 2008 [Page 12] Internet-Draft Vehicle Info Event Package July 2007 Figure 2: XML schema 6. 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 bodies. An example is given below: open on 3.0 68 3 closed Throttle Switch Malfunction Timing Belt Skipped a Tooth 20 55 3257 Figure 3: XML example 7. Security Considerations Singh, et al. Expires January 9, 2008 [Page 13] Internet-Draft Vehicle Info Event Package July 2007 7.1. Authorization Considerations There are obvious similarities between this section and the Security Considerations section of the membership event package document [15]. The group vehicle-info data contains privacy sensitive information as it can be used to deduce more detailed presence information of the user from multiple event packages of different entities. Consequently, access to the vehicle-info data and to the extended presence information MUST be controlled and be unavailable to unauthorized entities. A vehicle management company may be authorized to obtain the vehicle information using vehicle-info event package. A vehicle management server may allow the vehicle-info data to be passed to a user presentity only if the user is inside ths vehicle. In the car rental scenario example, apart from car rental company, only the presentity associated with the car is authorized by the car rental company to get vehicle-info data for the car. The same applies to the vehicle location data. The presentity may have this data aggregated into its extended presence information. In many cases, other users may get the vehicle-info data indirectly. Watchers, who want to get presentity's extended presence information can obtain it by subscribing to presentity using the presence event package. The PA would send presence information based on presentity's privacy preferences as described in the common policy specification [19]. 8. IANA Considerations A future version of this document will provide IANA considerations. 9. Acknowledgements 10. References 10.1. Normative References [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. Singh, et al. Expires January 9, 2008 [Page 14] Internet-Draft Vehicle Info Event Package July 2007 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [4] "Geographic information - Geography Markup Language (GML), OpenGIS 03-105r1, available at: http://portal.opengeospatial.org/files/?artifact_id=4700", April 2004. [5] "On Board Diagnostic (OBD), available at: http://obdii.com", April 2004. [6] "Extensible Markup Language (XML) 1.0 (Second Edition), World Wide Web Consortium FirstEdition REC-xml-20001006, available at: http://www.w3.org/TR/2000/REC-xml-20001006", October 2000. [7] Moats, R., "URN Syntax", RFC 2141, May 1997. [8] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [9] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. 10.2. Informative References [10] Garcia-Martin, M. and H. Schulzrinne, "Notification of General Events Using the Session Initiation Protocol (SIP) Event Notification Framework", draft-garcia-sipping-general-events-00 (work in progress), May 2007. [11] "Intelligent Transportation Society of America, available at: http://www.itsa.org/", April 2004. [12] "Global System for Telematics Forum, at: http://www.gstforum.org/en/home.htm", April 2004. [13] Singh, V., "Dynamic Feature Extensions to the Presence Information Data Format Location Object (PIDF-LO)", draft-singh-geopriv-pidf-lo-dynamic-01 (work in progress), March 2007. [14] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [15] Singh, V., "Membership Event Package", draft-singh-simple-membership-00 (work in progress), July 2007. Singh, et al. Expires January 9, 2008 [Page 15] Internet-Draft Vehicle Info Event Package July 2007 [16] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [17] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- Requena, "Functional Description of Event Notification Filtering", RFC 4660, September 2006. [18] 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. [19] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. [20] 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-01 (work in progress), March 2007. [21] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. [22] 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. [23] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [24] Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", draft-ietf-sip-location-conveyance-07 (work in progress), February 2007. [25] Thomson, M., "Geodetic Shapes for the Representation of Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-03 (work in progress), December 2006. [26] Schulzrinne, H., "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", draft-ietf-geopriv-policy-12 (work in progress), May 2007. Singh, et al. Expires January 9, 2008 [Page 16] Internet-Draft Vehicle Info Event Package July 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 Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Piotr Boni Verizon Communications 40 Sylvan Rd Waltham, MA 02451 US Phone: +1 781 466 2903 Email: piotr.boni@verizon.com Singh, et al. Expires January 9, 2008 [Page 17] Internet-Draft Vehicle Info Event Package July 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 January 9, 2008 [Page 18]