GEOPRIV M. Thomson Internet-Draft J. Winterbottom Expires: December 30, 2006 Andrew June 28, 2006 Device Capability Negotiation for Device-Based Location Determination and Location Measurements in HELD draft-thomson-geopriv-held-capabilities-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 December 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract A framework for the exchange of capabilities in HELD is described. A device is able to use this framework to notify a LIS of its location determination or location measurement capabilities. A method based on this framework where the LIS can use the location determination capability of the device is described. Guidelines for diverse location measurement technologies are included. Thomson & Winterbottom Expires December 30, 2006 [Page 1] Internet-Draft HELD Capabilities June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Capabilities Exchange . . . . . . . . . . . . . . . . . . . . 5 4. The Capability Indication . . . . . . . . . . . . . . . . . . 7 5. Capability Definitions . . . . . . . . . . . . . . . . . . . . 9 6. The Location Capability . . . . . . . . . . . . . . . . . . . 10 6.1. LIS Capabilities . . . . . . . . . . . . . . . . . . . . . 10 6.2. Location Capability Summary . . . . . . . . . . . . . . . 11 7. Application Schema . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:cap . . . . . . . . . . . . . 15 9.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:cap:location . . . . . . . . . 15 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 16 Appendix A. Capabilities and SUPL (Informational) . . . . . . . 17 Appendix A.1. SUPL Overview . . . . . . . . . . . . . . . . . . . 17 Appendix A.2. Using SUPL with HELD . . . . . . . . . . . . . . . . 19 Appendix A.3. Capabilities for HELD and SUPL . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Thomson & Winterbottom Expires December 30, 2006 [Page 2] Internet-Draft HELD Capabilities June 2006 1. Introduction A device is a good source of information about its location. Even where a device is unable to independently determine its location, it can often make observations about its environment and network attachment that are of use in determining its position. Making this information available to the Location Information Server (LIS) in the access network can improve the quality of location estimates for the device. Having more information available to the LIS also improves yield, or the rate of success in determining location. Acquiring location measurements or information from a device is made difficult by the nature of the relationship between the LIS, or access network, and the device. The relationship between a Location Information Server (LIS) and the devices that it serves is often transient. A device is not necessarily a permanent part of an access network. HELD [I-D.winterbottom-http-location-delivery] provides a basis for the relationship between device and LIS, including discovery and session establishment. This document relies on the concept of a HELD context and provides a means for the LIS to acquire information from the device. A device provides the LIS with a capabilities indication when it creates or updates its context data. The LIS responds with a reciprocal indication, that includes which of these capabilities it might use. Depending on the specific capabilities that were shared, the LIS is able to use some means to retrieve location information or location measurements from the device. This memo includes a sample capability that indicates that the device is able to determine its own location. This is included because it is a unique and universal capability and it can be specified generically. Further capabilities and their associated protocols need to be defined independently. Thomson & Winterbottom Expires December 30, 2006 [Page 3] Internet-Draft HELD Capabilities June 2006 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The following terms are used in this document: LIS: Location Information Server. A server, or service responsible for providing location information within an access network. Device: The Device is defined in [RFC3693]. The Device is also considered to be the Target of location determination; no reliable assertions about the location of a particular person can be made by a network that is only peripherally aware of the existence of a Device's user. Location Measurement: An observation about the physical properties of a particular device's network access. A location measurement can be used to determine the location of a device. A location measurement does not necessarily contain location information but it can be used in combination with contextual knowledge of the network, or algorithms to derive location information. Examples of location measurements: radio signal strength or timing measurements, Ethernet switch and port identifiers. Location Determination: The process of finding the location of a Device, either by calculation or correlation. The many-varied processes for location determination are outside the scope of this document. Location Estimate: The result of location determination, a location estimate is an approximation of where the Device is located. Location estimates are subject to uncertainty, which arise from measurement innaccuracy and reduce the precision of location information. Yield: Yield is a qualitative measure of how likely that location determination technology is able to produce a result. Yield is determined statistically and is expressed as a probability. GNSS: Global Navigation Satellite System. A satellite-based system that provides positioning and time information. For example, the US Global Positioning System (GPS). The terms Precision, Accuracy, Target and Context are used as defined in [RFC3693] and [I-D.winterbottom-http-location-delivery]. Thomson & Winterbottom Expires December 30, 2006 [Page 4] Internet-Draft HELD Capabilities June 2006 3. Capabilities Exchange When a device attaches to an access network, it establishes a transient relationship with the Access Network LIS. This relationship is established by first identifying the LIS, which requires a discovery process. A device that only requires location information is then able to make a request for a PIDF-LO [RFC4119] and the relationship ends. However, it is possible that this relationship is maintained over a longer period. Devices can establish state information at the LIS in the form of a context, which is required if the LIS provides a location URI. This document describes how the context can be used as the basis for cooperative location determination. Additional parameters are defined for use in context-related messages that permit the device and LIS to share information about their capabilities. Device capabilities include the ability to generate or acquire location information, or the ability to make observations about the mode of network attachment or environment. For instance, a device with GNSS- capable hardware can determine its own position by taking a set of measurements and performing a calculation, or it can provide the raw measurement data. At its core, the capabilities exchange is simple. The device sends a set of capabilities, each identified by a URN, to the LIS inside a HELD "createContext" request. The LIS selects those capabilities that it is able to make use of and includes those in the "contextResponse" message. +--------+ +-------+ | Device | | LIS | +--------+ +-------+ | | | createContext | |--(capabilities = A, B, C)-->| | | | updateContext | |<---(capabilities = A, C)----| | | Figure 1: Capabilities Exchange The set of capabilities that the LIS chooses to include in the response are a subset of the capabilities advertised by the Device, except as described in Section 6.1. Once a common set of capabilities are agreed upon, the LIS is able to make use of these capabilities to generate location information. Thomson & Winterbottom Expires December 30, 2006 [Page 5] Internet-Draft HELD Capabilities June 2006 This might be an ability to generate geodetic location information at the device, or the device might be able provide the LIS with location measurements. Each different capability is exercised in a different fashion, using a protocol that is selected when the capability is defined. The LIS invokes this capability in response to a request for location information, which can be initiated by either the device, or a Location Recipient (LR). +--------+ +-------+ +---------+ | Device | | LIS | | LR | +--------+ +-------+ +---------+ | | | | | | | |<--locationRequest--| | acquire | | |<---measurements----| | | | | | location | | |----measurements--->| | | | | | |------PIDF-LO------>| | | | Figure 2: Exercising Capabilities A capabilities exchange may contain additional information that is specific to the associated measurement acquisition method. This additional information also enables more complex negotiation between the Device and LIS. Capability exchanges that use more than two messages can use these two messages to bootstrap a separate capability exchange. Agreed capabilities are stored in the context created for the device at the LIS for later use. Thomson & Winterbottom Expires December 30, 2006 [Page 6] Internet-Draft HELD Capabilities June 2006 4. The Capability Indication A "capabilities" element is added to the extension part of a HELD request. The device initiates the exchange, including the "capabilities" element in either the "createContext" or "updateContext" requests. The "contextResponse" from the LIS indicates which of these capabilities might be used. A "capabilities" element contains a set of capability indications. A single capability is represented by a "capind" element. Each "capind" element has a mandatory "type" attribute that contains the URI that identifies the capability. The "capind" element may also contain arbitrary content, which means that the element is able to carry supplementary information that is specific to the capability. This supplementary information could include addressing information, protocol selection, authentication details, or any data necessary for the successful retrieval of information. Different supplementary information is provided by the Device and LIS. The "capind" element has an additional optional parameter that indicates the maximum expected time that exercising that particular capability takes. This information assists the LIS in a decision on whether or not to use this particular capability. Note that the Device is only able to quantify the time for its own involvement in the process; additional delays from network transmission and LIS processing need to be included in any decision to exercise a device capability. The "responseTime" attribute includes this information as either a time in seconds, or a duration type as defined in [W3C.REC-xmlschema-2-20041028]. The "responseTime" attribute should not be specified in a response from a LIS. The following figure shows a capabilities indication that might be made by a device with GNSS capabilities. This uses the location capability defined in Section 6, as well as a second capability that includes additional parameters. GPS Thomson & Winterbottom Expires December 30, 2006 [Page 7] Internet-Draft HELD Capabilities June 2006 !!Alternative: A possible alternative to the above configuration doesn't include an enclosing element for each capability indication. This acknowledges that there are rarely more than one capability to express. Thomson & Winterbottom Expires December 30, 2006 [Page 8] Internet-Draft HELD Capabilities June 2006 5. Capability Definitions Capabilities can be defined for access network or location measurement technologies as required. No special registration is required to define a capability; each capability is identified by a namespace URI. When describing a capability, the definition should include the following information: URI: A capability is identified by a URI, which need only be unique and persistent. Common practice is to use an "http:" URI for a domain that is under the author's control. An IETF document should use a URN [RFC2141] that is registered with the IANA. Capability Parameters: Each capability may require additional information to be passed between LIS and device in order for it to be exercised. This information must be described and defined as XML elements for inclusion in the "capind" element. Separate descriptions and definitions should be provided for the Device to LIS indications and LIS to Device responses. Procedures for Exercising Capabilities: Each capability must also include a description of how it can be exercised. This includes the protocol that is used for any network exchanges, the impact of each parameter. Security and Privacy Implications: A discussion of the security and the privacy implications associated with using the capability must be included with each definition. Author Contact: Details on how to contact the individual or organization responsible for the capability definition should be available. Thomson & Winterbottom Expires December 30, 2006 [Page 9] Internet-Draft HELD Capabilities June 2006 6. The Location Capability The ability to locate itself is a trait that is applicable to devices in a range of networks. This includes automated location determination, like Global Navigation Satellite Systems (GNSS), user input, or a range of location techniques. Because the device produces complete location information, there is no need for technology- or network-specific features in messages. Therefore, this section describes how a device may advertise its capability to source its own location. This section defines a location capability, identified by the URN "urn:ietf:params:xml:ns:geopriv:held:cap:location". This capability indicates that the device is able to provide location information to the LIS. The location capability includes a URI parameter that is passed in the request from Device to LIS. This URI indicates where the LIS can retrieve location information. Any URI scheme that can be trivially resolved may be used when expressing this capability. It is recommended that this be an "https:" URI. The Device should authenticate the LIS based on its X.509 certificate; the TLS [RFC2246] cipher suite "TLS_RSA_WITH_3DES_EDE_CBC_SHA" is recommended. The LIS is then able to retrieve location information from this URI when it needs it. Due to varying network configurations and the existence of NAPT and firewalls within some access networks, this capability is not universally viable. The LIS might not be able to resolve a URI provided by the Device. This limits the applicability of this, and possibly other capabilities, however this might be able to be addressed in a number of ways. Such workarounds are dependent on specific network configurations, but might be considered where device capabilities are important to the provision of precise location information. 6.1. LIS Capabilities A Device that is able to determine its own location might benefit from assistance from the LIS when it is generating location information. If the Device indicates that it is capable of determining its own location, a LIS can provide additional capabilities in the response for the benefit of the device. The LIS advertises these capabilities without any need for feedback from the Device. The Device is able to then utilize the capabilities provided by the LIS when it is determing its own location. This is useful where the Device is not able (or willing) to respond to Thomson & Winterbottom Expires December 30, 2006 [Page 10] Internet-Draft HELD Capabilities June 2006 requests for location measurements, but still wishes to benefit from network-based assistance. One possible use of this is for the LIS to indicate where the Device can acquire GNSS assistance data. 6.2. Location Capability Summary The following summarizes the location capability following the outline of Section 5: URI: urn:ietf:params:xml:ns:geopriv:held:cap:location Capability Parameters: This capability has a single parameter, a URI that is included in a "uri" element. The "uri" element is only used in the Device to LIS capabilities indication. Procedures for Exercising Capabilities: This capability is exercised by resolving a URI. Security and Privacy Implications: See Section 8 of this document. Author Contact: The authors of this document. Thomson & Winterbottom Expires December 30, 2006 [Page 11] Internet-Draft HELD Capabilities June 2006 7. Application Schema HELD Capabilities This schema defines a framework for capabilities negotiation in HELD. Thomson & Winterbottom Expires December 30, 2006 [Page 12] Internet-Draft HELD Capabilities June 2006 Thomson & Winterbottom Expires December 30, 2006 [Page 13] Internet-Draft HELD Capabilities June 2006 8. Security Considerations Giving the LIS additional information about the location of a Device might consititute a compromise of privacy. The LIS is able to resolve the location of the Device to a greater precision that would be otherwise possible without this assistance. Information about the capabilities of a Device could also be considered sensitive. A Device should offer a user the option to suppress the capability exchange and all associated functions. Any information that is provided to the LIS by the Device increases the impact of LIS impersonation. Measures that mitigate the possibility of impersonation, as outlined in the appropriate discovery drafts [I-D.winterbottom-geopriv-held-dhcp-discovery], are more important for a Device that provides capability information to a LIS. Protocols used for the exchange of location information or location measurements should also provide protection from eavesdropping. The LIS is responsible for the accuracy of location information it provides, even when it relies on information that comes from the Device. This is especially true when digital signatures are employed. However, the LIS is not able to establish grounds for trust in this information. A Device could provide erroneous measurements in an attempt to make the LIS provide certified, fraudulent location information. The LIS should take measures to verify the information that is provided to it. The LIS can use information from the network, or other trusted sources, to check that information provided by the Device is valid. Thomson & Winterbottom Expires December 30, 2006 [Page 14] Internet-Draft HELD Capabilities June 2006 9. IANA Considerations 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:cap This section registers a new XML namespace, "urn:ietf:params:xml:ns:held:cap", as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:held:cap Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). XML: BEGIN HELD Capabilities Indication

Namespace for HELD Capabilities Indication

urn:ietf:params:xml:ns:held:cap

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 9.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:held:cap:location This section registers a new XML namespace, "urn:ietf:params:xml:ns:held:cap:location", as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:held:cap Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). XML: Thomson & Winterbottom Expires December 30, 2006 [Page 15] Internet-Draft HELD Capabilities June 2006 BEGIN HELD Capabilities - Location Capability

Namespace for HELD Capabilities - Location Capability

urn:ietf:params:xml:ns:held:cap:location

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 9.3. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:held:cap Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). Schema: The XML for this schema can be found as the entirety of Section 7 of this document. Thomson & Winterbottom Expires December 30, 2006 [Page 16] Internet-Draft HELD Capabilities June 2006 Appendix A. Capabilities and SUPL (Informational) This appendix is provided as an example only, to demonstrate how capabilities could be applied. A formal specification of this capability is forthcoming. The Secure User Plane Location (SUPL) standard [OMA-LOC-SUPL-1.0] describes an architecture for location in cellular networks. SUPL differentiates itself from the tightly integrated cellular location architectures (termed control plane) by using the IP network for the bulk of its messaging. The primary advantage of SUPL is that it provides support for Assisted-GNSS. This appendix describes how the Assisted-GNSS feature of SUPL can be initiated using HELD capabilities. The cellular-specific aspects of SUPL, such as network roaming, are specifically excluded. This appendix is provided as an example only; the chosen namespace, "http://example.org/ns/held/supl" is used as a placeholder only. Appendix A.1. SUPL Overview How SUPL operates is particularly pertinent in discussing how to use capabilities to describe SUPL. SUPL requires that a SUPL Enabled Terminal (SET) - the SUPL Device - establish a connection for the positioning procedure. If the network requires a position, it can use a network-specific methods to trigger this; a Short Message Service (SMS) message, or Wireless Application Protocol (WAP) Push message are the available methods. This limitation is introduced because a cellular device cannot be guaranteed to have IP connectivity all the time. Each SET is also effectively hard-wired with a _Home_ server, or SUPL Location Platform (SLP) that it contacts. Thomson & Winterbottom Expires December 30, 2006 [Page 17] Internet-Draft HELD Capabilities June 2006 In Network Initiated mode, the network triggers the positioning procedure with a SUPL INIT message over SMS or WAP Push. The positioning procedure proper is started by the SET with a SUPL POS INIT. The core of the message exchange comprises of SUPL POS messages, which include GNSS assistance data, measurement information, and location information. The SUPL END is sent to signify the end of the transaction. +-------+ +-------+ | SET | | SLP | +-------+ +-------+ | | |<------SUPL INIT--------| | | |-----SUPL POS INIT----->| | | +-+------------------------+-+ | <-- SUPL POS --> | | Positioning Messages | +-+------------------------+-+ | | |-------SUPL END-------->| | | Figure 7: Network Initiated SUPL A SET that wishes to locate itself, can initiate the positioning procedure directly. The positioning procedure is identical for both methods. +-------+ +-------+ | SET | | SLP | +-------+ +-------+ | | |------SUPL START------->| | | |<----SUPL RESPONSE------| | | |-----SUPL POS INIT----->| | | +-+------------------------+-+ | <-- SUPL POS --> | | Positioning Messages | +-+------------------------+-+ | | |-------SUPL END-------->| | | Thomson & Winterbottom Expires December 30, 2006 [Page 18] Internet-Draft HELD Capabilities June 2006 Figure 8: SET Initiated SUPL Appendix A.2. Using SUPL with HELD The core set of messages in the above scenarios comprises of a SUPL POS INIT, one or more SUPL POS messages, and a SUPL END. The initial messages are only used to establish a common set of capabilities and to trigger the entire procedure. Two options exist for using the SUPL positioning procedure. The first uses the location capability described in Section 6; this requires no changes - a device can independently contact its Home SLP and perform the standard SUPL SET initiated procedure to determine its own location. The limitation with this is that the local network needs to provide an SLP; the local (or Visited) SLP needs to be able to communicate with the Home SLP, which implies a pre-arranged trust relationship. The second option provides additional flexibility in how the LIS operates, and makes the raw measurement data available. In this configuration, the device exchanges SLP messages with the local LIS. This increases the location determination options available to the LIS and helps protect against location fraud. In order to use this positioning procedure, a number of changes are made to the SUPL procedures. o The SET needs to be triggered using a TCP or UDP message. The SUPL INIT from the Network Initiated procedure is sent over an IP network, since there is no support for SMS or WAP Push. Note: A TCP-based SUPL INIT has been considered a number of times for SUPL, and is likely to be included in SUPL 2.0. o The SET needs to be able to contact an arbitrary SLP. The LIS includes an SLP address in its capability response. Note that this requires a different TLS cipher suite to the pre- shared key scheme recommended in [OMA-LOC-SUPL-1.0] because there is no prior trust arrangement between the SET and SLP. The standard "TLS_RSA_WITH_3DES_EDE_CBC_SHA" cipher suite is suggested with client authentication for when the SLP contacts the SET. Appendix A.3. Capabilities for HELD and SUPL The SUPL Network Initiated procedure is used as the basis of a new capability. Thomson & Winterbottom Expires December 30, 2006 [Page 19] Internet-Draft HELD Capabilities June 2006 For Device capabilities, the SET might need to indicate a port number, if this is different from that in the SUPL standard (59910). The capabilities indication from the SET does not need to include any additional parameters; the SUPL messaging can include all of the necessary information. However, the SET capabilities information can be used by the LIS to make more intelligent decisions about when to request SUPL positioning. Therefore, SET capabilities are included as optional parameters. A Device capabilities indication then look like the following: xmlns:supl="http://www.example.org/ns/held/supl"> 17332 SET-assisted_A-GNSS SET-based_A-GNSS SET-assisted_A-GNSS RRLP In the response from a LIS, the capabilities include the SLP name, as a Fully Qualified Domain Name: xmlns:supl="http://www.example.org/ns/held/supl"> slp.local.example.net Thomson & Winterbottom Expires December 30, 2006 [Page 20] Internet-Draft HELD Capabilities June 2006 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [I-D.winterbottom-http-location-delivery] Winterbottom, J., "HTTP Enabled Location Delivery (HELD)", draft-winterbottom-http-location-delivery-03 (work in progress), May 2006. [I-D.winterbottom-geopriv-held-dhcp-discovery] Winterbottom, J., "HELD Service Discovery using DHCP", draft-winterbottom-geopriv-held-dhcp-discovery-00 (work in progress), February 2004. [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation http://www.w3.org/TR/2004/REC-xmlschema-2-20041028, October 2004. 10.2. Informative References [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [OMA-LOC-SUPL-1.0] OMA, "Secure User Plane Location (SUPL) 1.0", SUPL Enabler 1.0, Jan 2006. Thomson & Winterbottom Expires December 30, 2006 [Page 21] Internet-Draft HELD Capabilities June 2006 Authors' Addresses Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2915 Email: martin.thomson@andrew.com URI: http://www.andrew.com/ James Winterbottom Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2938 Email: james.winterbottom@andrew.com URI: http://www.andrew.com/ Thomson & Winterbottom Expires December 30, 2006 [Page 22] Internet-Draft HELD Capabilities June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Thomson & Winterbottom Expires December 30, 2006 [Page 23]