idnits 2.17.1 draft-ietf-geopriv-http-location-delivery-06.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 1885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1909. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (April 9, 2008) is 5859 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: 'RFC2827' is defined on line 1575, but no explicit reference was found in the text == Unused Reference: 'RFC4119' is defined on line 1588, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 3693 == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-11 == Outdated reference: A later version (-15) exists of draft-ietf-geopriv-lis-discovery-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-07 == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-02 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-10 == Outdated reference: A later version (-05) exists of draft-winterbottom-geopriv-deref-protocol-00 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV WG M. Barnes, Ed. 3 Internet-Draft Nortel 4 Intended status: Standards Track 5 Expires: October 11, 2008 7 April 9, 2008 9 HTTP Enabled Location Delivery (HELD) 10 draft-ietf-geopriv-http-location-delivery-06.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 October 11, 2008. 37 Abstract 39 A Layer 7 Location Configuration Protocol (L7 LCP) is described that 40 is used for retrieving location information from a server within an 41 access network. The protocol includes options for retrieving 42 location information in two forms: by value and by reference. The 43 protocol is an extensible application-layer protocol that is 44 independent of session-layer. This document describes the use of 45 Hypertext Transfer Protocol (HTTP) as a transport for the protocol. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 51 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 52 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 53 4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7 54 4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7 55 4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 56 4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8 57 4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 58 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 59 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9 60 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10 61 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 62 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 63 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 64 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 65 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 66 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13 67 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13 68 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14 69 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14 70 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14 71 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 14 72 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 15 73 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 8. HELDS: URI Definition . . . . . . . . . . . . . . . . . . . . 18 75 9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 10.1. Assuring that the proper LIS has been contacted . . . . . 21 78 10.2. Protecting responses from modification . . . . . . . . . . 21 79 10.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22 80 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 11.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 23 82 11.2. Simple Location Request Example . . . . . . . . . . . . . 26 83 11.3. Location Request Example for Multiple Location Types . . . 27 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 85 12.1. URN Sub-Namespace Registration for 86 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28 87 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29 88 12.3. MIME Media Type Registration for 'application/held+xml' . 29 89 12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30 90 12.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 31 91 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 92 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 93 15. Changes since last Version . . . . . . . . . . . . . . . . . . 32 94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 95 16.1. Normative References . . . . . . . . . . . . . . . . . . . 36 96 16.2. Informative References . . . . . . . . . . . . . . . . . . 37 97 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 38 98 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 39 99 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 39 100 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 39 101 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 40 102 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 40 103 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 41 104 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 41 105 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 41 106 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 41 107 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 42 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 109 Intellectual Property and Copyright Statements . . . . . . . . . . 44 111 1. Introduction 113 The location of a Device is information that is useful for a number 114 of applications. The L7 Location Configuration Protocol (LCP) 115 problem statement and requirements document 116 [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which the 117 Device might rely on its access network to provide location 118 information. The LIS service applies to access networks employing 119 both wired technology (e.g. DSL, Cable) and wireless technology 120 (e.g. WiMAX) with varying degrees of Device mobility. This document 121 describes a protocol that can be used to acquire Location Information 122 (LI) from a Location Information Server (LIS) within an access 123 network. 125 This specification identifies two types of location information that 126 may be retrieved from the LIS. Location may be retrieved from the 127 LIS by value, that is, the Device may acquire a literal location 128 object describing the location of the Device. The Device may also 129 request that the LIS provide a location reference in the form of a 130 location URI or set of location URIs, allowing the Device to 131 distribute its LI by reference. Both of these methods can be 132 provided concurrently from the same LIS to accommodate application 133 requirements for different types of location information. 135 This specification defines an extensible XML-based protocol that 136 enables the retrieval of LI from a LIS by a Device. This protocol 137 can be bound to any session-layer protocol, particularly those 138 capable of MIME transport. This document describes the use of 139 Hypertext Transfer Protocol (HTTP) as a transport for the protocol. 141 2. Conventions & Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 This document uses the terms (and their acronym forms) Access 148 Provider (AP), Location Information (LI), Location Object (LO), 149 Device, Target, Location Generator (LG), Location Recipient (LR), 150 Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV 151 Requirements [RFC3693] . The terms Location Information Server 152 (LIS), Access Network, Access Provider (AP) and Access Network 153 Provider are used in the same context as defined in the L7 LCP 154 Problem statement and Requirements document 155 [I-D.ietf-geopriv-l7-lcp-ps]. The usage of the terms, Civic 156 Location/Address and Geodetic Location follows the usage in many of 157 the referenced documents. 159 In describing the protocol, the terms "attribute" and "element" are 160 used according to their context in XML. The term "parameter" is used 161 in a more general protocol context and can refer to either an XML 162 "attribute" or "element". 164 3. Overview and Scope 166 This document describes an interface between a Device and a Location 167 Information Server (LIS). This document assumes that the LIS is 168 present within the same administrative domain as the Device (e.g., 169 the access network). An Access Provider (AP) operates the LIS so 170 that Devices (and Targets) can retrieve their LI. The LIS exists 171 because not all Devices are capable of determining LI, and because, 172 even if a device is able to determine its own LI, it may be more 173 efficient with assistance. This document does not specify how LI is 174 determined. 176 This document is based on the attribution of the LI to a Device and 177 not specifically a person (end user) or Target, based on the premise 178 that location determination technologies are generally designed to 179 locate a device and not a person. It is expected that, for most 180 applications, LI for the device can be used as an adequate substitute 181 for the end user's LI. Since revealing the location of the device 182 almost invariably reveals some information about the location of the 183 user of the device, the same level of privacy protection demanded by 184 a user is required for the device. This approach may require either 185 some additional assurances about the link between device and target, 186 or an acceptance of the limitation that unless the device requires 187 active user authentication, there is no guarantee that any particular 188 individual is using the device at that instant. 190 The following diagram shows the logical configuration of some of the 191 functional elements identified in [RFC3693] and the LIS defined in 192 [I-D.ietf-geopriv-l7-lcp-ps] and where this protocol applies, with 193 the Rule Maker and Target represented by the role of the Device. 194 Note that only the interfaces relevant to the Device are identified 195 in the diagram. 197 +---------------------------------------------+ 198 | Access Network Provider | 199 | | 200 | +--------------------------------------+ | 201 | | Location Information Server | | 202 | | | | 203 | | | | 204 | | | | 205 | | | | 206 | +------|-------------------------------+ | 207 +----------|----------------------------------+ 208 | 209 | 210 HELD 211 | 212 Rule Maker - _ +-----------+ +-----------+ 213 o - - | Device | | Location | 214 645 653 654 655 This document (RFC xxxx) defines HELD messages. 656 658 659 661 662 663 664 665 666 667 669 670 672 673 674 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 693 694 695 696 697 698 699 700 701 703 704 705 706 707 708 709 711 712 713 714 715 717 718 719 720 722 723 724 726 727 728 729 730 731 733 734 735 736 738 739 740 741 742 744 746 747 748 749 751 753 754 755 756 757 758 761 763 764 765 766 768 771 773 774 775 776 777 780 782 783 784 785 787 790 792 8. HELDS: URI Definition 794 This section defines the schema for a helds: URI. This URI schema is 795 one possible URI scheme for the "locationURI" element, described in 796 Section 6.5.1, in a HELD "locationResponse " message. In this case, 797 the helds: URI indicates to the Device where to obtain the actual 798 location information for a Target. In addition, the helds: URI can 799 be the result of the LIS discovery process 800 [I-D.ietf-geopriv-lis-discovery] and indicates to the Device the LIS 801 from which LI should be requested. 803 The helds: URI is defined using a subset of the URI schema specified 804 in Appendix A. of RFC3986 [RFC3986] and the associated URI 805 Guidelines [RFC4395] per the following ABNF syntax: 807 HELD-URI = "helds" ":" "//" host [":" port] [ path-absolute ] [? query] 809 The following summarizes the primary elements comprising the HELD- 810 URI: 812 host: As defined in RFC3986 [RFC3986] 813 port: As defined in RFC3986 [RFC3986]. There is no unique port 814 associated with location URIs. 815 path-absolute As defined in RFC3986 [RFC3986]. 816 query: As defined in RFC3986 [RFC3986]. This allows for additional 817 information associated with the URIs such as a unique anonymous 818 identifier for the Device associated with the target location. 820 The helds: URI is not intended to be human-readable text, therefore 821 it is encoded entirely in US-ASCII. The following are examples of 822 helds: URIs: 824 helds://ls.example.com:49152/thisLocation?token=xyz987 825 helds://ls.example.com:5432/THISLOCATION?foobar=abc123 826 helds://ls.example.com:5432/THISlocation?foobar=ABC123 827 helds://ls.example.com:9876/civic 829 Other than the "host" portion, URIs are case sensitive and exact 830 equivalency is required for HELD-URI comparisons. For example, in 831 the above examples, although similar in information, the 2nd and 3rd 832 URIs are not considered equivalent. 834 In the case where the helds: URI is contained in a "locationURI" 835 element in a HELD locationResponse message, it is important to note 836 that the URI is only valid for the length of time indicated by the 837 "expires" attribute. 839 9. HTTP Binding 841 This section describes the use of HTTP [RFC2616] as a transport 842 mechanism for this protocol, which all conforming implementations 843 MUST support. 845 The request is carried in the body of an HTTP POST request. The MIME 846 type of both request and response bodies should be 847 "application/held+xml". This should be reflected in the HTTP 848 Content-Type and Accept header fields. 850 The LIS populates the HTTP headers so that they are consistent with 851 the contents of the message. In particular, the cache control header 852 SHOULD be set to disable the HTTP caching of any PIDF-LO document or 853 Location URIs. Otherwise, there is the risk of stale locations 854 and/or the unauthorized disclosure of the LI. This also allows the 855 LIS to control any caching with the "expires" parameter. The HTTP 856 status code MUST indicate a 2xx series response for all HELD 857 locationResponse and error messages. 859 The use of HTTP also includes a default behaviour, which is triggered 860 by a GET request, or a POST with no request body. If either of these 861 queries are received, the LIS MUST attempt to provide either a 862 PIDF-LO document or a Location URI, as if the request was a location 863 request. 865 The implementation of HTTP as a transport mechanism MUST implement 866 TLS as described in [RFC2818]. TLS provides message integrity and 867 privacy between Device and LIS. The LIS MUST use the server 868 authentication method described in [RFC2818]; the Device MUST fail a 869 request if server authentication fails, except in the event of an 870 emergency. 872 10. Security Considerations 874 HELD is a location acquisition protocol whereby the a client requests 875 its location from a LIS. Specific requirements and security 876 considerations for location acquisition protocols are provided in 877 [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security 878 considerations applicable to the use of Location URIs and by 879 reference provision of LI is included in 880 [I-D.ietf-geopriv-lbyr-requirements]. 882 By using the HELD protocol, the client and the LIS expose themselves 883 to two types of risk: 885 Accuracy: Client receives incorrect location information 886 Privacy: An unauthorized entity receives location information 888 The provision of an accurate and privacy/confidentiality protected 889 location to the requestor depends on the success of five steps: 891 1. The client must determine the proper LIS. 892 2. The client must connect to the proper LIS. 893 3. The LIS must be able to identify the device by its identifier 894 (IP Address). 895 4. The LIS must be able to return the desired location. 896 5. HELD messages must be transmitted unmodified between the LIS 897 and the client. 899 Of these, only the second, third and the fifth are within the scope 900 of this document. The first step is based on either manual 901 configuration or on the LIS discovery defined in 902 [I-D.ietf-geopriv-lis-discovery], in which appropriate security 903 considerations are already discussed. The fourth step is dependent 904 on the specific positioning capabilities of the LIS, and is thus 905 outside the scope of this document. 907 10.1. Assuring that the proper LIS has been contacted 909 This document assumes that the LIS to be contacted is identified 910 either by an IP address or a domain name, as is the case for a LIS 911 discovered as described in LIS Discovery 912 [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is 913 conducted using TLS [RFC4346], the LIS can authenticate its identity, 914 either as a domain name or as an IP address, to the client by 915 presenting a certificate containing that identifier as a 916 subjectAltName (i.e., as an iPAddress or dNSName, respectively). In 917 the case of the HTTP binding described above, this is exactly the 918 authentication described by TLS [RFC2818]. Any binding of HELD MUST 919 be capable of being transacted over TLS so that the client can 920 request the above authentication, and a LIS implementation for a 921 binding MUST include this feature. Note that in order for the 922 presented certificate to be valid at the client, the client must be 923 able to validate the certificate. In particular, the validation path 924 of the certificate must end in one of the client's trust anchors, 925 even if that trust anchor is the LIS certificate itself. 927 10.2. Protecting responses from modification 929 In order to prevent that response from being modified en route, 930 messages must be transmitted over an integrity-protected channel. 931 When the transaction is being conducted over TLS (a required feature 932 per Section 10.1), the channel will be integrity protected by 933 appropriate ciphersuites. When TLS is not used, this protection will 934 vary depending on the binding; in most cases, without protection from 935 TLS, the response will not be protected from modification en route. 937 10.3. Privacy and Confidentiality 939 Location information returned by the LIS must be protected from 940 access by unauthorized parties, whether those parties request the 941 location from the LIS or intercept it en route. As in section 942 Section 10.2, transactions conducted over TLS with appropriate 943 ciphersuites are protected from access by unauthorized parties en 944 route. Conversely, in most cases, when not conducted over TLS, the 945 response will be accessible while en route from the LIS to the 946 requestor. 948 Because HELD is an LCP and identifies clients and targets by IP 949 addresses, a requestor is authorized to access location for an IP 950 address only if it is the holder of that IP address. The LIS MUST 951 verify that the client is the target of the returned location, i.e., 952 the LIS MUST NOT provide location to other entities than the target. 953 Note that this is a necessary, but not sufficient criterion for 954 authorization. A LIS MAY deny requests according to any local 955 policy. 957 A prerequisite for meeting this requirement is that the LIS must have 958 some assurance of the identity of the client. Since the target of 959 the returned location is identified by an IP address, simply sending 960 the response to this IP address will provide sufficient assurance in 961 many cases. This is the default mechanism in HELD for assuring that 962 location is given only to authorized clients; LIS implementations 963 MUST support a mode of operation in which this is the only client 964 authentication. 966 Using IP return routability as an authenticator means that location 967 information is vulnerable to exposure through IP address spoofing 968 attacks. A temporary spoofing of IP address could mean that a device 969 could request a Location Object or Location URI that would result in 970 another Device's location. In addition, in cases where a Device 971 drops off the network for various reasons, the re-use of the Device's 972 IP address could result in another Device receiving the original 973 Device's location rather than its own location. One or more of the 974 following approaches are RECOMMENDED to limit these exposures: 976 o Location URIs SHOULD have a limited lifetime, as reflected by the 977 value for the expires element in Section 6.5.2. 978 o The network SHOULD have mechanisms that protect against IP address 979 spoofing, such as those defined in [RFC3704]. 980 o The LIS and network SHOULD be configured so that the LIS is made 981 aware of Device movement within the network and addressing 982 changes. If the LIS detects a change in the network that results 983 in it no longer being able to determine the location of the 984 Device, then all location URIs for that Device SHOULD be 985 invalidated. 987 The above measures are dependent on network configuration, which 988 SHOULD be considered. For instance, in a fixed internet access, 989 providers may be able to restrict the allocation of IP addresses to a 990 single physical line, ensuring that spoofing is not possible; in such 991 an environment, other measures may not be necessary. 993 When there are further mechanisms available to authenticate ownership 994 of the IP address, the LIS SHOULD use them to authenticate that the 995 client is the owner of the target IP address. For example, in a TLS 996 transaction, the client could present a certificate with a public key 997 bound to an IPv6 Cryptographically Generated Address, and the LIS 998 could verify this binding. 1000 11. Examples 1002 The following sections provide basic HTTP examples, a simple location 1003 request example and a location request for multiple location types 1004 example along with the relevant location responses. To focus on 1005 important portions of messages, the examples in Section 11.2 and 1006 Section 11.3 do not show HTTP headers or the XML prologue. In 1007 addition, sections of XML not relevant to the example are replaced 1008 with comments. 1010 11.1. HTTP Example Messages 1012 The examples in this section show a complete HTTP message that 1013 includes the HELD request or response document. 1015 This example shows the most basic request for a LO. This uses the 1016 GET feature described by the HTTP binding. This example assumes that 1017 the LIS service exists at the URL "https://lis.example.com/location". 1019 GET /location HTTP/1.1 1020 Host: lis.example.com 1021 Accept:application/held+xml, 1022 application/xml;q=0.8, 1023 text/xml;q=0.7 1024 Accept-Charset: UTF-8,* 1026 The GET request is exactly identical to a minimal POST request that 1027 includes an empty "locationRequest" element. 1029 POST /location HTTP/1.1 1030 Host: lis.example.com 1031 Accept: application/held+xml, 1032 application/xml;q=0.8, 1033 text/xml;q=0.7 1034 Accept-Charset: UTF-8,* 1035 Content-Type: application/held+xml 1036 Content-Length: 87 1038 1039 1041 Since neither of these requests includes a "locationType" element, 1042 the successful response to either of these requests may contain any 1043 type of location. The following shows a response containing a 1044 minimal PIDF-LO. 1046 HTTP/1.x 200 OK 1047 Server: Example LIS 1048 Date: Tue, 10 Jan 2006 03:42:29 GMT 1049 Expires: Tue, 10 Jan 2006 03:42:29 GMT 1050 Cache-control: private 1051 Content-Type: application/held+xml 1052 Content-Length: 594 1054 1055 1056 1058 1059 1060 1061 1062 1064 -34.407 150.88001 1065 1066 1067 1068 1069 2006-01-11T03:42:28+00:00 1070 1071 Wiremap 1072 1073 1074 2006-01-10T03:42:28+00:00 1075 1076 1077 1079 The error response to either of these requests is an error document. 1080 The following response shows an example error response. 1082 HTTP/1.x 200 OK 1083 Server: Example LIS 1084 Expires: Tue, 10 Jan 2006 03:49:20 GMT 1085 Cache-control: private 1086 Content-Type: application/held+xml 1087 Content-Length: 135 1089 1090 1094 11.2. Simple Location Request Example 1096 The location request shown below doesn't specify any location types 1097 or response time. 1099 1101 The example response to this location request contains a list of 1102 Location URIs. 1104 1105 1106 helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1107 1108 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 1109 1110 1111 1113 An error response to this location request is shown below: 1115 1119 11.3. Location Request Example for Multiple Location Types 1121 The following Location Request message includes a request for 1122 geodetic, civic and any Location URIs. 1124 1125 1126 geodetic 1127 civic 1128 locationURI 1129 1130 1132 The corresponding Location Response message includes the requested 1133 location information, including two location URIs. 1135 1136 1137 helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1138 1139 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 1140 1141 1142 1144 1145 1146 1147 1148 1152 -34.407242 150.882518 1153 30 1154 1156 1157 1160 AU 1161 NSW 1162 Wollongong 1163 Gwynneville 1164 Northfield Avenue 1165 University of Wollongong 1166 2 1167 Andrew Corporation 1168 2500 1169 39 1170 WS-183 1171 U40 1172 1173 1174 1175 false 1176 2007-05-25T12:35:02+10:00 1177 1178 1179 Wiremap 1180 1181 1182 2007-05-24T12:35:02+10:00 1183 1184 1185 1187 12. IANA Considerations 1189 This document requires several IANA registrations detailed in the 1190 following sections. 1192 12.1. URN Sub-Namespace Registration for 1193 urn:ietf:params:xml:ns:geopriv:held 1195 This section registers a new XML namespace, 1196 "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in 1197 [RFC3688]. 1199 URI: urn:ietf:params:xml:ns:geopriv:held 1200 Registrant Contact: IETF, GEOPRIV working group, 1201 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1202 XML: 1204 BEGIN 1205 1206 1208 1209 1210 HELD Messages 1211 1212 1213

Namespace for HELD Messages

1214

urn:ietf:params:xml:ns:geopriv:held

1215 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1216 with the RFC number for this specification.] 1217

See RFCXXXX

1218 1219 1220 END 1222 12.2. XML Schema Registration 1224 This section registers an XML schema as per the guidelines in 1225 [RFC3688]. 1227 URI: urn:ietf:params:xml:schema:geopriv:held 1228 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1229 Mary Barnes (mary.barnes@nortel.com). 1230 Schema: The XML for this schema can be found as the entirety of 1231 Section 7 of this document. 1233 12.3. MIME Media Type Registration for 'application/held+xml' 1235 This section registers the "application/held+xml" MIME type. 1237 To: ietf-types@iana.org 1238 Subject: Registration of MIME media type application/held+xml 1239 MIME media type name: application 1240 MIME subtype name: held+xml 1241 Required parameters: (none) 1242 Optional parameters: charset 1243 Indicates the character encoding of enclosed XML. Default is 1244 UTF-8. 1246 Encoding considerations: Uses XML, which can employ 8-bit 1247 characters, depending on the character encoding used. See RFC 1248 3023 [RFC3023], section 3.2. 1249 Security considerations: This content type is designed to carry 1250 protocol data related to the location of an entity, which could 1251 include information that is considered private. Appropriate 1252 precautions should be taken to limit disclosure of this 1253 information. 1254 Interoperability considerations: This content type provides a basis 1255 for a protocol 1256 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please 1257 replace XXXX with the RFC number for this specification.] 1258 Applications which use this media type: Location information 1259 providers and consumers. 1260 Additional Information: Magic Number(s): (none) 1261 File extension(s): .xml 1262 Macintosh File Type Code(s): (none) 1263 Person & email address to contact for further information: Mary 1264 Barnes 1265 Intended usage: LIMITED USE 1266 Author/Change controller: The IETF 1267 Other information: This media type is a specialization of 1268 application/xml [RFC3023], and many of the considerations 1269 described there also apply to application/held+xml. 1271 12.4. Error code Registry 1273 This document requests that the IANA create a new registry for the 1274 HELD protocol including an initial registry for error codes. The 1275 error codes are included in HELD error messages as described in 1276 Section 6.3 and defined in the schema in the 'codeType' token in the 1277 XML schema in (Section 7) 1279 The following summarizes the requested registry: 1281 Related Registry: Geopriv HELD Registries, Error codes for HELD 1282 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1283 with the RFC number for this specification.] 1284 Registration/Assignment Procedures: Following the policies outlined 1285 in [I-D.narten-iana-considerations-rfc2434bis], the IANA policy 1286 for assigning new values for the Error codes for HELD shall be 1287 Specification Required: values and their meanings must be 1288 documented in an RFC or in some other permanent and readily 1289 available reference, in sufficient detail that interoperability 1290 between independent implementations is possible. 1292 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1293 Mary Barnes (mary.barnes@nortel.com). 1295 This section pre-registers the following seven initial error codes as 1296 described above in Section 6.3: 1298 requestError: This code indicates that the request was badly formed 1299 in some fashion. 1300 xmlError: This code indicates that the XML content of the request 1301 was either badly formed or invalid. 1302 generalLisError: This code indicates that an unspecified error 1303 occurred at the LIS. 1304 locationUnknown: This code indicates that the LIS could not 1305 determine the location of the Device. 1306 unsupportedMessage: This code indicates that the request was not 1307 supported or understood by the LIS. 1308 timeout: This code indicates that the LIS could not satisfy the 1309 request within the time specified in the "responseTime" parameter. 1310 cannotProvideLiType: This code indicates that the LIS was unable to 1311 provide LI of the type or types requested. This code is used when 1312 the "exact" attribute on the "locationType" parameter is set to 1313 "true". 1315 12.5. URI Registration 1317 The following summarizes the information necessary to register the 1318 helds: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the 1319 RFC number for this specification in the following list.] 1321 URI Scheme Name: helds 1322 Status: permanent 1323 URI Scheme syntax: See section 1324 URI Scheme Semantics: The helds: URI is intended to be used as a 1325 reference to a location object or a location information server. 1326 Further detail is provided in Section 8 of RFC XXXX. 1327 Encoding Considerations: The HELDS: URI is not intended to be human- 1328 readable text, therefore they are encoded entirely in US-ASCII. 1329 Applications/protocols that use this URI scheme: The HELD protocol 1330 described in RFC XXXX, the GEOPRIV Location De-reference Protocol 1331 [I-D.winterbottom-geopriv-deref-protocol] and GEOPRIV Location 1332 Information Server Discovery [I-D.ietf-geopriv-lis-discovery]. 1333 Interoperability considerations: This URI may be used as a parameter 1334 for the HELD protocol in the locationResponse message. This URI 1335 is also used as an input parameter for the GEOPRIV Location De- 1336 reference Protocol [I-D.winterbottom-geopriv-deref-protocol]. 1337 This URI may also be a result of the GEOPRIV Location Information 1338 Server Discovery [I-D.ietf-geopriv-lis-discovery] and thus used as 1339 the target for the HELD protocol request messages. Refer to 1340 Section 8 in RFC XXXX for further detail and a particular example 1341 on the lack of permanence of a specific HELDS: URI and thus the 1342 importance of using these URIs only within the specific contexts 1343 outlined in the references. 1344 Security considerations: Section 10 in RFC XXXX addresses the 1345 necessary security associated with the transport of location 1346 information between a Device and the LIS to ensure the privacy and 1347 integrity of the helds: URI. Section 6.5.1 in RFC XXXX also 1348 recommends that the URI be allocated such that it does not reveal 1349 any detail at all about the content of the PIDF-LO that it may 1350 indirectly reference. 1351 Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary 1352 Barnes (mary.barnes@nortel.com). 1353 Author/Change controller: This scheme is registered under the IETF 1354 tree. As such, IETF maintains change control. 1355 References: RFC XXXX, GEOPRIV Location De-reference Protocol 1356 [I-D.winterbottom-geopriv-deref-protocol], GEOPRIV Location 1357 Information Server Discovery [I-D.ietf-geopriv-lis-discovery] 1359 13. Contributors 1361 James Winterbottom, Martin Thomson and Barbara Stark are the authors 1362 of the original document, from which this WG document was derived. 1363 Their contact information is included in the Author's address 1364 section. In addition, they also contributed to the WG document, 1365 including the XML schema. 1367 14. Acknowledgements 1369 The author/contributors would like to thank the participants in the 1370 GEOPRIV WG and the following people for their constructive input and 1371 feedback on this document (in alphabetical order): Nadine Abbott, 1372 Eric Arolick, Richard Barnes (in particular the security section), 1373 Peter Blatherwick, Guy Caron, Martin Dawson, Lisa Dusseault, Jerome 1374 Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc 1375 Linsner, Patti McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed, 1376 Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed 1377 Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf. 1379 15. Changes since last Version 1381 NOTE TO THE RFC-Editor: Please remove this section prior to 1382 publication as an RFC. 1384 Changes from WG 05 to 06 (2nd WGLC comments): 1386 1) Updated security section based on WG feedback, including 1387 condensing section 10.1.1 (Assuring the proper LIS has been 1388 contacted), restructuring sections by flattening, adding an 1389 additional step to the list that had been in the Accuracy section and 1390 removing summary section. 1392 2) Changed URI schema to "helds" to address concerns over referential 1393 integrity and for consistency with mandate of TLS for HELD. 1395 3) Editorial clarifications including fixing examples to match HELD 1396 URI definition (e.g., adding port, adding randomness to URI examples, 1397 etc.) 1399 4) Updated references removing unused references and moving 1400 requirements docs to Informational Reference section to avoid 1401 downrefs. 1403 Changes from WG 04 to 05 (WGLC comments): 1405 1) Totally replaced the security section with the details provided by 1406 Richard Barnes so that we don't need a reference to the location 1407 security document. 1409 2) Fixed error codes in schema to allow extensibility. Change the 1410 IANA registration to be "specification required". 1412 3) Cleaned up the HELD: URI description, per comments from Martin and 1413 James and partially addressing HELD-04 Issue 1. Put the definition 1414 in a separate section and clarified the applicability (to also 1415 include being a results of the discovery process) and fixed examples. 1417 4) Updated the LocationURI section to be more accurate, address 1418 HELD-04 Issue 3, and include the reference to the new HELD:URI 1419 section. Also, fixed an error in the doc in that the top level parm 1420 in the locationResponse is actually locationUriSet, which contains 1421 any number of locationURI elements and the "expires" parameter. So, 1422 Table 1 was also updated and a new section for the LocationURISet was 1423 added that includes the subsections for the "locationURI" and 1424 "expires". And, then clarified that "expires" applies to 1425 "locationURISet" and not per "locationURI". 1427 5) Editorial nits: pointed out offline by Richard (e.g., by-value -> 1428 by value, by-reference -> by reference, etc.) and onlist by James and 1429 Martin. Please refer to the diff for a complete view of editorial 1430 changes. 1432 6) Added text in HTTP binding section to disable HTTP caching 1433 (HELD-04 Issue 5 on the list). 1435 Changes from WG 03 to 04: 1437 1) Terminology: clarified in terminology section that "attribute" and 1438 "element" are used in the strict XML sense and "parameter" is used as 1439 a general protocol term Replaced term "HTTP delivery" with "HTTP 1440 transport". Still have two terms "HTTP transport" and "HTTP 1441 binding", but those are consistent with general uses of HTTP. 1443 2) Editorial changes and clarifications: per Roger Marshall's and 1444 Eric Arolick's comments and subsequent WG mailing list discussion. 1446 3) Changed normative language for describing expected and recommended 1447 LIS behaviors to be non-normative recommendations in cases where the 1448 protocol parameters were not the target of the discussion (e.g., we 1449 can't prescribe to the LIS how it determines location or what it 1450 defines to be an "accurate" location). 1452 4) Clarified responseTime attribute (section 6.1). Changed type from 1453 "decimal" to "nonNegativeInteger" in XML schema (section 7) 1455 5) Updated Table 1 in section 6 to only include top-level parameters 1456 and fixed some errors in that table (i.e., code for locationResponse) 1457 and adding PIDF-LO to the table. Added a detailed section describing 1458 PIDF-LO (section 6.6), moving some of the normative text in the 1459 Protocol Overview to this section. 1461 6) Added schema and description for locationURI to section 6.5. 1462 Added IANA registration for HELD: URI schema. 1464 7) Added IANA registry for error codes. 1466 Changes from WG 02 to 03: 1468 1) Added text to address concern over use of IP address as device 1469 identifier, per long email thread - changes to section 3 (overview) 1470 and section 4 (protocol overview). 1472 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed) 1474 3) Added extensibility to baseRequestType in the schema (an oversight 1475 from previous edits), along with fixing some other nits in schema 1476 (section 7) 1478 4) Moved discussion of Location URI from section 5.3 (Location 1479 Response) to where it rightly belonged in Section 6.5 (Location URI 1480 Parameter). 1482 5) Clarified text for "expires" parameter (6.5.1) - it's an optional 1483 parm, but required for LocationURIs 1485 6) Clarified responseTime parameter: when missing, then the LCS 1486 provides most precise LI, with the time required being implementation 1487 specific. 1489 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST 1490 implement. 1492 8) Updated references (removed unused/added new). 1494 Changes from WG 01 to 02: 1496 1) Updated Terminology to be consistent with WG agreements and other 1497 documents (e.g., LCS -> LIS and removed duplicate terms). In the 1498 end, there are no new terms defined in this document. 1500 2) Modified definition of responseTime to reflect WG consensus. 1502 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving 1503 just "civic"). 1505 4) Clarified text that locationType is optional. Fixed table 1 and 1506 text in section 5.2 (locationRequest description). Text in section 1507 6.2 (description of locationType element) already defined the default 1508 to be "any". 1510 5) Simplified error responses. Separated the definition of error 1511 response type from the locationResponse type thus no need for 1512 defining an error code of "success". This simplifies the schema and 1513 processing. 1515 6) Updated schema/examples for the above. 1517 7) Updated Appendix A based on updates to requirements document, 1518 specifically changes to A.1, A.3 and adding A.10. 1520 8) Miscellaneous editorial clarifications. 1522 Changes from WG 00 to 01: 1524 1) heldResponse renamed to locationResponse. 1526 2) Changed namespace references for the PIDF-LO geoShape in the 1527 schema to match the agreed GML PIDF-LO Geometry Shape Application 1528 Schema. 1530 3) Removed "options" element - leaving optionality/extensibility to 1531 XML mechanisms. 1533 4) Changed error codes to be enumerations and not redefinitions of 1534 HTTP response codes. 1536 5) Updated schema/examples for the above and removed some remnants of 1537 the context element. 1539 6) Clarified the definition of "Location Information (LI)" to include 1540 a reference to the location (to match the XML schema and provide 1541 consistency of usage throughout the document). Added an additional 1542 statement in section 7.2 (locationType) to clarify that LCS MAY also 1543 return a Location URI. 1545 7) Modifed the definition of "Location Configuration Server (LCS)" to 1546 be consistent with the current definiton in the requirements 1547 document. 1549 8) Updated Location Response (section 6.3) to remove reference to 1550 context and discuss the used of a local identifier or unlinked 1551 pseudonym in providing privacy/security. 1553 9) Clarified that the source IP address in the request is used as the 1554 identifier for the target/device for the HELD protocol as defined in 1555 this document. 1557 10) Miscellaneous editorial clarifications. 1559 16. References 1561 16.1. Normative References 1563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1564 Requirement Levels", BCP 14, RFC 2119, March 1997. 1566 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1567 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1569 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1570 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1571 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1573 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1575 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1576 Defeating Denial of Service Attacks which employ IP Source 1577 Address Spoofing", BCP 38, RFC 2827, May 2000. 1579 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1580 January 2004. 1582 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1583 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1585 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1586 Networks", BCP 84, RFC 3704, March 2004. 1588 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1589 Format", RFC 4119, December 2005. 1591 [I-D.ietf-geopriv-pdif-lo-profile] 1592 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1593 PIDF-LO Usage Clarification, Considerations and 1594 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 1595 (work in progress), February 2008. 1597 [W3C.REC-xmlschema-1-20041028] 1598 Maloney, M., Thompson, H., Beech, D., and N. Mendelsohn, 1599 "XML Schema Part 1: Structures Second Edition", World Wide 1600 Web Consortium Recommendation REC-xmlschema-1-20041028, 1601 October 2004, 1602 . 1604 [W3C.REC-xmlschema-2-20041028] 1605 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1606 Second Edition", World Wide Web Consortium 1607 Recommendation REC-xmlschema-2-20041028, October 2004, 1608 . 1610 [I-D.ietf-geopriv-lis-discovery] 1611 Thomson, M. and J. Winterbottom, "Discovering the Local 1612 Location Information Server (LIS)", 1613 draft-ietf-geopriv-lis-discovery-00 (work in progress), 1614 December 2007. 1616 16.2. Informative References 1618 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1619 RFC 793, September 1981. 1621 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1622 Types", RFC 3023, January 2001. 1624 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1625 Resource Identifier (URI): Generic Syntax", STD 66, 1626 RFC 3986, January 2005. 1628 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1629 Configuration Protocol Option for Coordinate-based 1630 Location Configuration Information", RFC 3825, July 2004. 1632 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 1633 Registration Procedures for New URI Schemes", BCP 115, 1634 RFC 4395, February 2006. 1636 [I-D.narten-iana-considerations-rfc2434bis] 1637 Narten, T. and H. Alvestrand, "Guidelines for Writing an 1638 IANA Considerations Section in RFCs", 1639 draft-narten-iana-considerations-rfc2434bis-09 (work in 1640 progress), March 2008. 1642 [I-D.ietf-geopriv-l7-lcp-ps] 1643 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 1644 Location Configuration Protocol; Problem Statement and 1645 Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in 1646 progress), March 2008. 1648 [I-D.ietf-geopriv-lbyr-requirements] 1649 Marshall, R., "Requirements for a Location-by-Reference 1650 Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work 1651 in progress), February 2008. 1653 [I-D.ietf-sip-location-conveyance] 1654 Polk, J. and B. Rosen, "Location Conveyance for the 1655 Session Initiation Protocol", 1656 draft-ietf-sip-location-conveyance-10 (work in progress), 1657 February 2008. 1659 [I-D.winterbottom-geopriv-deref-protocol] 1660 Winterbottom, J., Tschofenig, H., Schulzrinne, H., 1661 Thomson, M., and M. Dawson, "An HTTPS Location 1662 Dereferencing Protocol Using HELD", 1663 draft-winterbottom-geopriv-deref-protocol-00 (work in 1664 progress), November 2007. 1666 [LLDP-MED] 1667 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1668 Endpoint Discovery". 1670 Appendix A. HELD Compliance to IETF LCP requirements 1672 This appendix describes HELD's compliance to the requirements 1673 specified in the [I-D.ietf-geopriv-l7-lcp-ps]. 1675 A.1. L7-1: Identifier Choice 1677 "The L7 LCP MUST be able to carry different identifiers or MUST 1678 define an identifier that is mandatory to implement. Regarding the 1679 latter aspect, such an identifier is only appropriate if it is from 1680 the same realm as the one for which the location information service 1681 maintains identifier to location mapping." 1683 COMPLY 1685 HELD uses the IP address of the location request message as the 1686 primary source of identity for the requesting device or target. This 1687 identity can be used with other contextual network information to 1688 provide a physical location for the Target for many network 1689 deployments. There may be network deployments where an IP address 1690 alone is insufficient to identify a Target in a network. However, 1691 any necessary identity extensions for these networks is beyond the 1692 scope of this document. 1694 A.2. L7-2: Mobility Support 1696 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 1697 broad range of mobility from devices that can only move between 1698 reboots, to devices that can change attachment points with the impact 1699 that their IP address is changed, to devices that do not change their 1700 IP address while roaming, to devices that continuously move by being 1701 attached to the same network attachment point." 1703 COMPLY 1705 Mobility support is inherently a characteristic of the access network 1706 technology and HELD is designed to be access network agnostic. 1707 Consequently HELD complies with this requirement. In addition HELD 1708 provides specific support for mobile environments by providing an 1709 optional responseTime attribute in location request messages. 1710 Wireless networks often have several different mechanisms at their 1711 disposal for position determination (e.g. Assisted GPS versus 1712 location based on serving base station identity), each providing 1713 different degrees of accuracy and taking different amounts of time to 1714 yield a result. The responseTime parameter provides the LIS with a 1715 criterion which it can use to select a location determination 1716 technique. 1718 A.3. L7-3: ASP and Access Network Provider Relationship 1720 "The design of the L7 LCP MUST NOT assume a business or trust 1721 relationship between the Application Service Provider (ASP) and the 1722 Access Network Provider. Requirements for resolving a reference to 1723 location information are not discussed in this document." 1725 COMPLY 1727 HELD describes a location acquisition protocol and has no 1728 dependencies on the business or trust relationship between the ASP 1729 and the Access Network Provider. Location acquisition using HELD is 1730 subject to the restrictions described in Section 10. 1732 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship 1734 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1735 MUST assume that there is a trust and business relationship between 1736 the L2 and the L3 provider. The L3 provider operates the LIS and 1737 needs to obtain location information from the L2 provider since this 1738 one is closest to the end host. If the L2 and L3 provider for the 1739 same host are different entities, they cooperate for the purposes 1740 needed to determine end system locations." 1742 COMPLY 1744 HELD was specifically designed with this model in mind and readily 1745 allows itself to chaining requests between operators without a change 1746 in protocol being required. HELD is a webservices protocol it can be 1747 bound to transports other than HTTP. Using o offers the option of 1748 high request throughput over a dedicated connection between an L3 1749 provider and an L2 provider without incurring the serial restriction 1750 imposed by HTTP. This is less easy to do with protocols that do not 1751 decouple themselves from the transport. 1753 A.5. L7-5: Legacy Device Considerations 1755 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1756 MUST consider legacy residential NAT devices and NTEs in an DSL 1757 environment that cannot be upgraded to support additional protocols, 1758 for example to pass additional information through DHCP." 1760 COMPLY 1762 HELD is an application protocol and operates on top of IP. A HELD 1763 request from a host behind a residential NAT will traverse the NAT 1764 acquiring the external address of the home router. The location 1765 provided to the host therefore will be the address of the home router 1766 in this circumstance. No changes are required to the home router in 1767 order to support this function, HELD was designed specifically to 1768 address this deployment scenario. 1770 A.6. L7-6: VPN Awareness 1772 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1773 MUST assume that at least one end of a VPN is aware of the VPN 1774 functionality. In an enterprise scenario, the enterprise side will 1775 provide the LIS used by the client and can thereby detect whether the 1776 LIS request was initiated through a VPN tunnel." 1778 COMPLY 1780 HELD does not preclude a LIS on the far end of a VPN tunnel being 1781 aware that the client request is occurring over that tunnel. It also 1782 does not preclude a client device from accessing a LIS serving the 1783 local physical network and subsequently using the location 1784 information with an application that is accessed over a VPN tunnel. 1786 A.7. L7-7: Network Access Authentication 1788 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1789 MUST NOT assume prior network access authentication." 1791 COMPLY 1793 HELD makes no assumptions about prior network access authentication. 1794 HELD strongly recommends the use of TLS with server-side certificates 1795 for communication between the end-point and the LIS. There is no 1796 requirement for the end-point to authenticate with the LIS. 1798 A.8. L7-8: Network Topology Unawareness 1800 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1801 MUST NOT assume end systems being aware of the access network 1802 topology. End systems are, however, able to determine their public 1803 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." 1805 COMPLY 1807 HELD makes no assumption about the network topology. HELD doesn't 1808 require that the device know its external IP address, except where 1809 that is required for discovery of the LIS. 1811 A.9. L7-9: Discovery Mechanism 1813 "The L7 LCP MUST define a single mandatory to implement discovery 1814 mechanism." 1816 COMPLY 1817 HELD uses the discovery mechanism in 1818 [I-D.ietf-geopriv-lis-discovery]. 1820 A.10. L7-10: PIDF-LO Creation 1822 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the 1823 element into the element of the presence document 1824 (see RFC 4479). This ensures that the resulting PIDF-LO document, 1825 which is subsequently distributed to other entities, conforms to the 1826 rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile] 1828 COMPLY 1830 HELD protocol overview (Section 4 ) describes the requirements on the 1831 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated 1832 by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile]. 1834 Authors' Addresses 1836 Mary Barnes (editor) 1837 Nortel 1838 2201 Lakeside Blvd 1839 Richardson, TX 1841 Email: mary.barnes@nortel.com 1843 James Winterbottom 1844 Andrew 1845 PO Box U40 1846 Wollongong University Campus, NSW 2500 1847 AU 1849 Phone: +61 2 4221 2938 1850 Email: james.winterbottom@andrew.com 1851 URI: http://www.andrew.com/ 1852 Martin Thomson 1853 Andrew 1854 PO Box U40 1855 Wollongong University Campus, NSW 2500 1856 AU 1858 Phone: +61 2 4221 2915 1859 Email: martin.thomson@andrew.com 1860 URI: http://www.andrew.com/ 1862 Barbara Stark 1863 BellSouth 1864 Room 7A41 1865 725 W Peachtree St. 1866 Atlanta, GA 30308 1867 US 1869 Email: barbara.stark@bellsouth.com 1871 Full Copyright Statement 1873 Copyright (C) The IETF Trust (2008). 1875 This document is subject to the rights, licenses and restrictions 1876 contained in BCP 78, and except as set forth therein, the authors 1877 retain all their rights. 1879 This document and the information contained herein are provided on an 1880 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1881 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1882 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1883 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1884 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1885 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1887 Intellectual Property 1889 The IETF takes no position regarding the validity or scope of any 1890 Intellectual Property Rights or other rights that might be claimed to 1891 pertain to the implementation or use of the technology described in 1892 this document or the extent to which any license under such rights 1893 might or might not be available; nor does it represent that it has 1894 made any independent effort to identify any such rights. Information 1895 on the procedures with respect to rights in RFC documents can be 1896 found in BCP 78 and BCP 79. 1898 Copies of IPR disclosures made to the IETF Secretariat and any 1899 assurances of licenses to be made available, or the result of an 1900 attempt made to obtain a general license or permission for the use of 1901 such proprietary rights by implementers or users of this 1902 specification can be obtained from the IETF on-line IPR repository at 1903 http://www.ietf.org/ipr. 1905 The IETF invites any interested party to bring to its attention any 1906 copyrights, patents or patent applications, or other proprietary 1907 rights that may cover technology that may be required to implement 1908 this standard. Please address the information to the IETF at 1909 ietf-ipr@ietf.org.