idnits 2.17.1 draft-ietf-geopriv-http-location-delivery-09.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 1930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1954. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack 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 (September 8, 2008) is 5710 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: 'RFC4395' is defined on line 1681, 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) == 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-02 -- 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-08 == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-03 == 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-02 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 12 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: March 12, 2009 7 September 8, 2008 9 HTTP Enabled Location Delivery (HELD) 10 draft-ietf-geopriv-http-location-delivery-09.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 March 12, 2009. 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) and HTTP over Transport Layer 46 Security (HTTP/TLS) as transports for the protocol. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 52 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 54 4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 55 4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 7 56 4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 57 4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 8 58 4.3. Location by Reference . . . . . . . . . . . . . . . . . . 8 59 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 60 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 10 61 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10 62 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 63 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 64 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 65 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 66 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 67 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14 68 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14 69 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15 70 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15 71 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15 72 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16 73 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16 74 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 8. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 20 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 77 9.1. Assuring that the proper LIS has been contacted . . . . . 21 78 9.2. Protecting responses from modification . . . . . . . . . . 22 79 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22 80 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 23 82 10.2. Simple Location Request Example . . . . . . . . . . . . . 26 83 10.3. Location Request Example for Multiple Location Types . . . 27 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 85 11.1. URN Sub-Namespace Registration for 86 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28 87 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29 88 11.3. MIME Media Type Registration for 'application/held+xml' . 29 89 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30 90 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 91 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 92 14. Changes since last Version . . . . . . . . . . . . . . . . . . 32 93 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 94 15.1. Normative References . . . . . . . . . . . . . . . . . . . 37 95 15.2. Informative References . . . . . . . . . . . . . . . . . . 38 97 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 39 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 . . . . 40 101 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 40 102 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 41 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 . . . . . . . . . . . . 42 106 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 42 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 a 117 Device might rely on its access network to provide location 118 information. The Location Information Server (LIS) service applies 119 to access networks employing both wired technology (e.g. DSL, Cable) 120 and wireless technology (e.g. WiMAX) with varying degrees of Device 121 mobility. This document describes a protocol that can be used to 122 acquire Location Information (LI) from a 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) and HTTP over Transport Layer 140 Security (HTTP/TLS) as transports for the protocol. 142 2. Conventions & Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 This document uses the terms (and their acronym forms) Access 149 Provider (AP), Location Information (LI), Location Object (LO), 150 Device, Target, Location Generator (LG), Location Recipient (LR), 151 Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV 152 Requirements [RFC3693] . The terms Location Information Server 153 (LIS), Access Network, Access Provider (AP) and Access Network 154 Provider are used in the same context as defined in the L7 LCP 155 Problem statement and Requirements document 156 [I-D.ietf-geopriv-l7-lcp-ps]. The usage of the terms, Civic 157 Location/Address and Geodetic Location follows the usage in many of 158 the referenced documents. 160 In describing the protocol, the terms "attribute" and "element" are 161 used according to their context in XML. The term "parameter" is used 162 in a more general protocol context and can refer to either an XML 163 "attribute" or "element". 165 3. Overview and Scope 167 This document describes an interface between a Device and a Location 168 Information Server (LIS). This document assumes that the LIS is 169 present within the same administrative domain as the Device (e.g., 170 the access network). An Access Provider (AP) operates the LIS so 171 that Devices (and Targets) can retrieve their LI. The LIS exists 172 because not all Devices are capable of determining LI, and because, 173 even if a device is able to determine its own LI, it may be more 174 efficient with assistance. This document does not specify how LI is 175 determined. 177 This document is based on the attribution of the LI to a Device and 178 not specifically a person (end user) or Target, based on the premise 179 that location determination technologies are generally designed to 180 locate a device and not a person. It is expected that, for most 181 applications, LI for the device can be used as an adequate substitute 182 for the end user's LI. Since revealing the location of the device 183 almost invariably reveals some information about the location of the 184 user of the device, the same level of privacy protection demanded by 185 a user is required for the device. This approach may require either 186 some additional assurances about the link between device and target, 187 or an acceptance of the limitation that unless the device requires 188 active user authentication, there is no guarantee that any particular 189 individual is using the device at that instant. 191 The following diagram shows the logical configuration of some of the 192 functional elements identified in [RFC3693] and the LIS defined in 193 [I-D.ietf-geopriv-l7-lcp-ps] and where this protocol applies, with 194 the Rule Maker and Target represented by the role of the Device. 195 Note that only the interfaces relevant to the Device are identified 196 in the diagram. 198 +---------------------------------------------+ 199 | Access Network Provider | 200 | | 201 | +--------------------------------------+ | 202 | | Location Information Server | | 203 | | | | 204 | | | | 205 | | | | 206 | | | | 207 | +------|-------------------------------+ | 208 +----------|----------------------------------+ 209 | 210 | 211 HELD 212 | 213 Rule Maker - _ +-----------+ +-----------+ 214 o - - | Device | | Location | 215 716 724 725 726 This document (RFC xxxx) defines HELD messages. 727 729 730 732 735 736 737 738 739 740 742 743 745 746 747 749 750 751 752 753 754 755 756 757 758 759 760 761 762 764 765 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 784 785 786 787 788 789 790 791 792 793 794 796 797 798 799 801 802 803 805 806 807 808 809 810 812 813 814 815 817 818 819 820 821 823 825 826 827 828 830 832 833 834 835 836 837 840 842 843 844 845 847 850 852 853 854 855 856 859 861 862 863 864 866 869 871 8. HTTP/HTTPS Binding 873 This section describes the use of HTTP [RFC2616] and HTTPS [RFC2818] 874 as transport mechanisms for the HELD protocol, which all conforming 875 implementations MUST support. 877 The request is carried in the body of an HTTP/HTTPS POST request. 878 The MIME type of both request and response bodies should be 879 "application/held+xml". This should be reflected in the HTTP 880 Content-Type and Accept header fields. 882 The LIS populates the HTTP/HTTPS headers so that they are consistent 883 with the contents of the message. In particular, the cache control 884 header SHOULD be set to disable the HTTP/HTTPS caching of any PIDF-LO 885 document or Location URIs. Otherwise, there is the risk of stale 886 locations and/or the unauthorized disclosure of the LI. This also 887 allows the LIS to control any caching with the "expires" parameter. 888 The HTTP/HTTPS status code MUST indicate a 2xx series response for 889 all HELD locationResponse and error messages. 891 The use of HTTP/HTTPS also includes a default behaviour, which is 892 triggered by a GET request, or a POST with no request body. If 893 either of these queries are received, the LIS MUST attempt to provide 894 either a PIDF-LO document or a Location URI, as if the request was a 895 location request. 897 Implementation of HELD that implement HTTP transport MUST implement a 898 transport over HTTPS [RFC2818]. TLS provides message integrity and 899 confidentiality between Device and LIS. The LIS MUST implement the 900 server authentication method described in [RFC2818]. The device uses 901 the URI obtained during LIS discovery to authenticate the server. 902 The details of this authentication method are provided in section 3.1 903 of [RFC2818]. When TLS is used, the Device SHOULD fail a request if 904 server authentication fails, except in the event of an emergency. 906 9. Security Considerations 908 HELD is a location acquisition protocol whereby the a client requests 909 its location from a LIS. Specific requirements and security 910 considerations for location acquisition protocols are provided in 911 [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security 912 considerations applicable to the use of Location URIs and by 913 reference provision of LI is included in 914 [I-D.ietf-geopriv-lbyr-requirements]. 916 By using the HELD protocol, the client and the LIS expose themselves 917 to two types of risk: 919 Accuracy: Client receives incorrect location information 920 Privacy: An unauthorized entity receives location information 922 The provision of an accurate and privacy/confidentiality protected 923 location to the requestor depends on the success of five steps: 925 1. The client must determine the proper LIS. 926 2. The client must connect to the proper LIS. 927 3. The LIS must be able to identify the device by its identifier 928 (IP Address). 929 4. The LIS must be able to return the desired location. 930 5. HELD messages must be transmitted unmodified between the LIS 931 and the client. 933 Of these, only the second, third and the fifth are within the scope 934 of this document. The first step is based on either manual 935 configuration or on the LIS discovery defined in 936 [I-D.ietf-geopriv-lis-discovery], in which appropriate security 937 considerations are already discussed. The fourth step is dependent 938 on the specific positioning capabilities of the LIS, and is thus 939 outside the scope of this document. 941 9.1. Assuring that the proper LIS has been contacted 943 This document assumes that the LIS to be contacted is identified 944 either by an IP address or a domain name, as is the case for a LIS 945 discovered as described in LIS Discovery 946 [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is 947 conducted using TLS [RFC4346], the LIS can authenticate its identity, 948 either as a domain name or as an IP address, to the client by 949 presenting a certificate containing that identifier as a 950 subjectAltName (i.e., as an iPAddress or dNSName, respectively). In 951 the case of the HTTP binding described above, this is exactly the 952 authentication described by TLS [RFC2818]. Any binding of HELD MUST 953 be capable of being transacted over TLS so that the client can 954 request the above authentication, and a LIS implementation for a 955 binding MUST include this feature. Note that in order for the 956 presented certificate to be valid at the client, the client must be 957 able to validate the certificate. In particular, the validation path 958 of the certificate must end in one of the client's trust anchors, 959 even if that trust anchor is the LIS certificate itself. 961 9.2. Protecting responses from modification 963 In order to prevent that response from being modified en route, 964 messages must be transmitted over an integrity-protected channel. 965 When the transaction is being conducted over TLS (a required feature 966 per Section 9.1), the channel will be integrity protected by 967 appropriate ciphersuites. When TLS is not used, this protection will 968 vary depending on the binding; in most cases, without protection from 969 TLS, the response will not be protected from modification en route. 971 9.3. Privacy and Confidentiality 973 Location information returned by the LIS must be protected from 974 access by unauthorized parties, whether those parties request the 975 location from the LIS or intercept it en route. As in section 976 Section 9.2, transactions conducted over TLS with appropriate 977 ciphersuites are protected from access by unauthorized parties en 978 route. Conversely, in most cases, when not conducted over TLS, the 979 response will be accessible while en route from the LIS to the 980 requestor. 982 Because HELD is an LCP and identifies clients and targets by IP 983 addresses, a requestor is authorized to access location for an IP 984 address only if it is the holder of that IP address. The LIS MUST 985 verify that the client is the target of the returned location, i.e., 986 the LIS MUST NOT provide location to other entities than the target. 987 Note that this is a necessary, but not sufficient criterion for 988 authorization. A LIS MAY deny requests according to any local 989 policy. 991 A prerequisite for meeting this requirement is that the LIS must have 992 some assurance of the identity of the client. Since the target of 993 the returned location is identified by an IP address, simply sending 994 the response to this IP address will provide sufficient assurance in 995 many cases. This is the default mechanism in HELD for assuring that 996 location is given only to authorized clients; LIS implementations 997 MUST support a mode of operation in which this is the only client 998 authentication. 1000 Using IP return routability as an authenticator means that location 1001 information is vulnerable to exposure through IP address spoofing 1002 attacks. A temporary spoofing of IP address could mean that a device 1003 could request a Location Object or Location URI that would result in 1004 another Device's location. In addition, in cases where a Device 1005 drops off the network for various reasons, the re-use of the Device's 1006 IP address could result in another Device receiving the original 1007 Device's location rather than its own location. These exposures are 1008 limited by the following: 1010 o Location URIs MUST have a limited lifetime, as reflected by the 1011 value for the expires element in Section Section 6.5.2. The 1012 lifetime of location URIs necessarily depends on the nature of the 1013 access. 1014 o The network SHOULD have mechanisms that protect against IP address 1015 spoofing, such as those defined in [RFC3704]. 1016 o The LIS and network SHOULD be configured so that the LIS is made 1017 aware of Device movement within the network and addressing 1018 changes. If the LIS detects a change in the network that results 1019 in it no longer being able to determine the location of the 1020 Device, then all location URIs for that Device SHOULD be 1021 invalidated. 1023 The above measures are dependent on network configuration, which 1024 SHOULD be considered. For instance, in a fixed internet access, 1025 providers may be able to restrict the allocation of IP addresses to a 1026 single physical line, ensuring that spoofing is not possible; in such 1027 an environment, additional measures may not be necessary. 1029 10. Examples 1031 The following sections provide basic HTTP/HTTPS examples, a simple 1032 location request example and a location request for multiple location 1033 types example along with the relevant location responses. To focus 1034 on important portions of messages, the examples in Section 10.2 and 1035 Section 10.3 do not show HTTP/HTTPS headers or the XML prologue. In 1036 addition, sections of XML not relevant to the example are replaced 1037 with comments. 1039 10.1. HTTPS Example Messages 1041 The examples in this section show a complete HTTPS message that 1042 includes the HELD request or response document. 1044 This example shows the most basic request for a LO. This uses the 1045 GET feature described by the HTTP binding. 1047 GET https://lis.example.com:49152/location HTTP/1.1 1048 Accept:application/held+xml, 1049 application/xml;q=0.8, 1050 text/xml;q=0.7 1051 Accept-Charset: UTF-8,* 1053 The GET request is exactly identical to a minimal POST request that 1054 includes an empty "locationRequest" element. 1056 POST https://lis.example.com:49152/location HTTP/1.1 1057 Accept: application/held+xml, 1058 application/xml;q=0.8, 1059 text/xml;q=0.7 1060 Accept-Charset: UTF-8,* 1061 Content-Type: application/held+xml 1062 Content-Length: 87 1064 1065 1067 Since neither of these requests includes a "locationType" element, 1068 the successful response to either of these requests may contain any 1069 type of location. The following shows a response containing a 1070 minimal PIDF-LO. 1072 HTTP/1.x 200 OK 1073 Server: Example LIS 1074 Date: Tue, 10 Jan 2006 03:42:29 GMT 1075 Expires: Tue, 10 Jan 2006 03:42:29 GMT 1076 Cache-control: private 1077 Content-Type: application/held+xml 1078 Content-Length: 594 1080 1081 1082 1084 1085 1086 1087 1088 1090 -34.407 150.88001 1091 1092 1093 1094 1095 2006-01-11T03:42:28+00:00 1096 1097 Wiremap 1098 1099 1100 2006-01-10T03:42:28+00:00 1101 1102 1103 1105 The error response to either of these requests is an error document. 1106 The following response shows an example error response. 1108 HTTP/1.1 200 OK 1109 Server: Example LIS 1110 Expires: Tue, 10 Jan 2006 03:49:20 GMT 1111 Cache-control: private 1112 Content-Type: application/held+xml 1113 Content-Length: 135 1115 1116 1120 10.2. Simple Location Request Example 1122 The location request shown below doesn't specify any location types 1123 or response time. 1125 1127 The example response to this location request contains a list of 1128 Location URIs. 1130 1131 1132 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1133 1134 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 1135 1136 1137 1139 An error response to this location request is shown below: 1141 1145 10.3. Location Request Example for Multiple Location Types 1147 The following Location Request message includes a request for 1148 geodetic, civic and any Location URIs. 1150 1151 1152 geodetic 1153 civic 1154 locationURI 1155 1156 1158 The corresponding Location Response message includes the requested 1159 location information, including two location URIs. 1161 1162 1163 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1164 1165 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 1166 1167 1168 1170 1171 1172 1173 1174 1178 -34.407242 150.882518 1179 30 1180 1182 1183 1186 AU 1187 NSW 1188 Wollongong 1189 Gwynneville 1190 Northfield Avenue 1191 University of Wollongong 1192 2 1193 Andrew Corporation 1194 2500 1195 39 1196 WS-183 1197 U40 1198 1199 1200 1201 false 1202 2007-05-25T12:35:02+10:00 1203 1204 1205 Wiremap 1206 1207 1208 2007-05-24T12:35:02+10:00 1209 1210 1211 1213 11. IANA Considerations 1215 This document requires several IANA registrations detailed in the 1216 following sections. 1218 11.1. URN Sub-Namespace Registration for 1219 urn:ietf:params:xml:ns:geopriv:held 1221 This section registers a new XML namespace, 1222 "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in 1223 [RFC3688]. 1225 URI: urn:ietf:params:xml:ns:geopriv:held 1226 Registrant Contact: IETF, GEOPRIV working group, 1227 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1228 XML: 1230 BEGIN 1231 1232 1234 1235 1236 HELD Messages 1237 1238 1239

Namespace for HELD Messages

1240

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

1241 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1242 with the RFC number for this specification.] 1243

See RFCXXXX

1244 1245 1246 END 1248 11.2. XML Schema Registration 1250 This section registers an XML schema as per the guidelines in 1251 [RFC3688]. 1253 URI: urn:ietf:params:xml:schema:geopriv:held 1254 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1255 Mary Barnes (mary.barnes@nortel.com). 1256 Schema: The XML for this schema can be found as the entirety of 1257 Section 7 of this document. 1259 11.3. MIME Media Type Registration for 'application/held+xml' 1261 This section registers the "application/held+xml" MIME type. 1263 To: ietf-types@iana.org 1264 Subject: Registration of MIME media type application/held+xml 1265 MIME media type name: application 1266 MIME subtype name: held+xml 1267 Required parameters: (none) 1268 Optional parameters: charset 1269 Indicates the character encoding of enclosed XML. Default is 1270 UTF-8. 1272 Encoding considerations: Uses XML, which can employ 8-bit 1273 characters, depending on the character encoding used. See RFC 1274 3023 [RFC3023], section 3.2. 1275 Security considerations: This content type is designed to carry 1276 protocol data related to the location of an entity, which could 1277 include information that is considered private. Appropriate 1278 precautions should be taken to limit disclosure of this 1279 information. 1280 Interoperability considerations: This content type provides a basis 1281 for a protocol 1282 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please 1283 replace XXXX with the RFC number for this specification.] 1284 Applications which use this media type: Location information 1285 providers and consumers. 1286 Additional Information: Magic Number(s): (none) 1287 File extension(s): .xml 1288 Macintosh File Type Code(s): (none) 1289 Person & email address to contact for further information: Mary 1290 Barnes 1291 Intended usage: LIMITED USE 1292 Author/Change controller: The IETF 1293 Other information: This media type is a specialization of 1294 application/xml [RFC3023], and many of the considerations 1295 described there also apply to application/held+xml. 1297 11.4. Error code Registry 1299 This document requests that the IANA create a new registry for the 1300 HELD protocol including an initial registry for error codes. The 1301 error codes are included in HELD error messages as described in 1302 Section 6.3 and defined in the schema in the 'codeType' token in the 1303 XML schema in (Section 7) 1305 The following summarizes the requested registry: 1307 Related Registry: Geopriv HELD Registries, Error codes for HELD 1308 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1309 with the RFC number for this specification.] 1310 Registration/Assignment Procedures: Following the policies outlined 1311 in [RFC5226], the IANA policy for assigning new values for the 1312 Error codes for HELD shall be Specification Required: values and 1313 their meanings must be documented in an RFC or in some other 1314 permanent and readily available reference, in sufficient detail 1315 that interoperability between independent implementations is 1316 possible. 1318 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1319 Mary Barnes (mary.barnes@nortel.com). 1321 This section pre-registers the following seven initial error codes as 1322 described above in Section 6.3: 1324 requestError: This code indicates that the request was badly formed 1325 in some fashion. 1326 xmlError: This code indicates that the XML content of the request 1327 was either badly formed or invalid. 1328 generalLisError: This code indicates that an unspecified error 1329 occurred at the LIS. 1330 locationUnknown: This code indicates that the LIS could not 1331 determine the location of the Device. 1332 unsupportedMessage: This code indicates that the request was not 1333 supported or understood by the LIS. This error code is used when 1334 a HELD request contains a document element that is not supported 1335 by the receiver. 1336 timeout: This code indicates that the LIS could not satisfy the 1337 request within the time specified in the "responseTime" parameter. 1338 cannotProvideLiType: This code indicates that the LIS was unable to 1339 provide LI of the type or types requested. This code is used when 1340 the "exact" attribute on the "locationType" parameter is set to 1341 "true". 1342 notLocatable: This code indicates that the LIS is unable to locate 1343 the Device, and that the Device MUST NOT make further attempts to 1344 retrieve LI from this LIS. This error code is used to indicate 1345 that the Device is outside the access network served by the LIS; 1346 for instance, the VPN and NAT scenarios discussed in 1347 Section 4.1.2. 1349 12. Contributors 1351 James Winterbottom, Martin Thomson and Barbara Stark are the authors 1352 of the original document, from which this WG document was derived. 1353 Their contact information is included in the Author's address 1354 section. In addition, they also contributed to the WG document, 1355 including the XML schema. 1357 13. Acknowledgements 1359 The author/contributors would like to thank the participants in the 1360 GEOPRIV WG and the following people for their constructive input and 1361 feedback on this document (in alphabetical order): Nadine Abbott, 1362 Eric Arolick, Richard Barnes (in particular the security section), 1363 Peter Blatherwick, Ben Campbell, Guy Caron, Martin Dawson, Lisa 1364 Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil 1365 Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall, 1366 Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, Brian 1367 Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed 1368 Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf. 1370 14. Changes since last Version 1372 NOTE TO THE RFC-Editor: Please remove this section prior to 1373 publication as an RFC. 1375 Changes from WG 08 to 09 (Post-IETF LC: continued resolution of sec- 1376 dir and gen-art review comments, along with apps-area feedback): 1378 1) Removed heldref/heldrefs URIs, including fixing examples (which 1379 were buggy anyways). 1381 2) Clarified text for locationURI - specifying that the deref 1382 protocol must define or appropriately restrict and clarifying that 1383 requirements for deref must be met and that deref details are out of 1384 scope for this document. 1386 3) Clarified text in security section for support of both HTTP/HTTPS. 1388 4) Changed definition for Location Type to force the specification of 1389 at least one location type. 1391 Changes from WG 07 to 08 (IETF LC: sec-dir and gen-art review 1392 comments): 1394 1) Fix editorial nits: rearranging sections in 4.1 for readibility, 1395 etc. 1397 2) Added back text in Device and VPN section referencing DHCP and 1398 LLDP-MED when a VPN device serves as a LIS. 1400 3) Clarified the use of both HTTP and HTTPS. 1402 4) Defined two URIs related to 3 respectively - divided IANA 1403 registrations into sub-sections to accomodate this change. (Note: 1404 LIS Discovery will now define that URI, thus this document defines 1405 the one associatied with a Location reference). 1407 5) Clarified the description of the location URI in Protocol Overview 1408 and Protocol parameter sections. Note that these sections again 1409 reference location dereference protocol for completeness and 1410 clarification of issues that are out of scope for this base document. 1412 6) Defined new error code: notLocatable. 1414 7) Clarifications and corrections in security section. 1416 8) Clarified text for locationType, specifically removing extra text 1417 from "any" description and putting that in a separate paragraph. 1418 Also, provided an example. 1420 9) Added boundaries for "expires" parameter. 1422 10) Clarified that the HELD protocol as defined by this document does 1423 not allow for canceling location references. 1425 Changes from WG 06 to 07 (PROTO review comments): 1427 1) Fix nits: remove unused references, move requirements to 1428 Informational References section, fix long line in ABNF, fix ABNF 1429 (quotes around '?'), add schemaLocation to import namespace in XML 1430 schema. 1432 2) Remove text in Device and VPN section referencing DHCP and LLDP- 1433 MED when a VPN device serves as a LIS, per Issue 1 resolution at 1434 IETF-71. (Editorial oversight in producing version 06). 1436 Changes from WG 05 to 06 (2nd WGLC comments): 1438 1) Updated security section based on WG feedback, including 1439 condensing section 10.1.1 (Assuring the proper LIS has been 1440 contacted), restructuring sections by flattening, adding an 1441 additional step to the list that had been in the Accuracy section and 1442 removing summary section. 1444 2) Changed URI schema to "helds" to address concerns over referential 1445 integrity and for consistency with mandate of TLS for HELD. 1447 3) Editorial clarifications including fixing examples to match HELD 1448 URI definition (e.g., adding port, adding randomness to URI examples, 1449 etc.) 1451 4) Updated references removing unused references and moving 1452 requirements docs to Informational Reference section to avoid 1453 downrefs. 1455 Changes from WG 04 to 05 (WGLC comments): 1457 1) Totally replaced the security section with the details provided by 1458 Richard Barnes so that we don't need a reference to the location 1459 security document. 1461 2) Fixed error codes in schema to allow extensibility. Change the 1462 IANA registration to be "specification required". 1464 3) Cleaned up the HELD: URI description, per comments from Martin and 1465 James and partially addressing HELD-04 Issue 1. Put the definition 1466 in a separate section and clarified the applicability (to also 1467 include being a results of the discovery process) and fixed examples. 1469 4) Updated the LocationURI section to be more accurate, address 1470 HELD-04 Issue 3, and include the reference to the new HELD:URI 1471 section. Also, fixed an error in the doc in that the top level parm 1472 in the locationResponse is actually locationUriSet, which contains 1473 any number of locationURI elements and the "expires" parameter. So, 1474 Table 1 was also updated and a new section for the LocationURISet was 1475 added that includes the subsections for the "locationURI" and 1476 "expires". And, then clarified that "expires" applies to 1477 "locationURISet" and not per "locationURI". 1479 5) Editorial nits: pointed out offline by Richard (e.g., by-value -> 1480 by value, by-reference -> by reference, etc.) and onlist by James and 1481 Martin. Please refer to the diff for a complete view of editorial 1482 changes. 1484 6) Added text in HTTP binding section to disable HTTP caching 1485 (HELD-04 Issue 5 on the list). 1487 Changes from WG 03 to 04: 1489 1) Terminology: clarified in terminology section that "attribute" and 1490 "element" are used in the strict XML sense and "parameter" is used as 1491 a general protocol term Replaced term "HTTP delivery" with "HTTP 1492 transport". Still have two terms "HTTP transport" and "HTTP 1493 binding", but those are consistent with general uses of HTTP. 1495 2) Editorial changes and clarifications: per Roger Marshall's and 1496 Eric Arolick's comments and subsequent WG mailing list discussion. 1498 3) Changed normative language for describing expected and recommended 1499 LIS behaviors to be non-normative recommendations in cases where the 1500 protocol parameters were not the target of the discussion (e.g., we 1501 can't prescribe to the LIS how it determines location or what it 1502 defines to be an "accurate" location). 1504 4) Clarified responseTime attribute (section 6.1). Changed type from 1505 "decimal" to "nonNegativeInteger" in XML schema (section 7) 1507 5) Updated Table 1 in section 6 to only include top-level parameters 1508 and fixed some errors in that table (i.e., code for locationResponse) 1509 and adding PIDF-LO to the table. Added a detailed section describing 1510 PIDF-LO (section 6.6), moving some of the normative text in the 1511 Protocol Overview to this section. 1513 6) Added schema and description for locationURI to section 6.5. 1514 Added IANA registration for HELD: URI schema. 1516 7) Added IANA registry for error codes. 1518 Changes from WG 02 to 03: 1520 1) Added text to address concern over use of IP address as device 1521 identifier, per long email thread - changes to section 3 (overview) 1522 and section 4 (protocol overview). 1524 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed) 1526 3) Added extensibility to baseRequestType in the schema (an oversight 1527 from previous edits), along with fixing some other nits in schema 1528 (section 7) 1530 4) Moved discussion of Location URI from section 5.3 (Location 1531 Response) to where it rightly belonged in Section 6.5 (Location URI 1532 Parameter). 1534 5) Clarified text for "expires" parameter (6.5.1) - it's an optional 1535 parm, but required for LocationURIs 1537 6) Clarified responseTime parameter: when missing, then the LCS 1538 provides most precise LI, with the time required being implementation 1539 specific. 1541 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST 1542 implement. 1544 8) Updated references (removed unused/added new). 1546 Changes from WG 01 to 02: 1548 1) Updated Terminology to be consistent with WG agreements and other 1549 documents (e.g., LCS -> LIS and removed duplicate terms). In the 1550 end, there are no new terms defined in this document. 1552 2) Modified definition of responseTime to reflect WG consensus. 1554 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving 1555 just "civic"). 1557 4) Clarified text that locationType is optional. Fixed table 1 and 1558 text in section 5.2 (locationRequest description). Text in section 1559 6.2 (description of locationType element) already defined the default 1560 to be "any". 1562 5) Simplified error responses. Separated the definition of error 1563 response type from the locationResponse type thus no need for 1564 defining an error code of "success". This simplifies the schema and 1565 processing. 1567 6) Updated schema/examples for the above. 1569 7) Updated Appendix A based on updates to requirements document, 1570 specifically changes to A.1, A.3 and adding A.10. 1572 8) Miscellaneous editorial clarifications. 1574 Changes from WG 00 to 01: 1576 1) heldResponse renamed to locationResponse. 1578 2) Changed namespace references for the PIDF-LO geoShape in the 1579 schema to match the agreed GML PIDF-LO Geometry Shape Application 1580 Schema. 1582 3) Removed "options" element - leaving optionality/extensibility to 1583 XML mechanisms. 1585 4) Changed error codes to be enumerations and not redefinitions of 1586 HTTP response codes. 1588 5) Updated schema/examples for the above and removed some remnants of 1589 the context element. 1591 6) Clarified the definition of "Location Information (LI)" to include 1592 a reference to the location (to match the XML schema and provide 1593 consistency of usage throughout the document). Added an additional 1594 statement in section 7.2 (locationType) to clarify that LCS MAY also 1595 return a Location URI. 1597 7) Modifed the definition of "Location Configuration Server (LCS)" to 1598 be consistent with the current definiton in the requirements 1599 document. 1601 8) Updated Location Response (section 6.3) to remove reference to 1602 context and discuss the used of a local identifier or unlinked 1603 pseudonym in providing privacy/security. 1605 9) Clarified that the source IP address in the request is used as the 1606 identifier for the target/device for the HELD protocol as defined in 1607 this document. 1609 10) Miscellaneous editorial clarifications. 1611 15. References 1613 15.1. Normative References 1615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1616 Requirement Levels", BCP 14, RFC 2119, March 1997. 1618 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1619 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1621 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1622 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1623 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1625 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1627 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1628 January 2004. 1630 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1631 Networks", BCP 84, RFC 3704, March 2004. 1633 [I-D.ietf-geopriv-pdif-lo-profile] 1634 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1635 PIDF-LO Usage Clarification, Considerations and 1636 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 1637 (work in progress), February 2008. 1639 [W3C.REC-xmlschema-1-20041028] 1640 Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, 1641 "XML Schema Part 1: Structures Second Edition", World Wide 1642 Web Consortium Recommendation REC-xmlschema-1-20041028, 1643 October 2004, 1644 . 1646 [W3C.REC-xmlschema-2-20041028] 1647 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1648 Second Edition", World Wide Web Consortium 1649 Recommendation REC-xmlschema-2-20041028, October 2004, 1650 . 1652 [I-D.ietf-geopriv-lis-discovery] 1653 Thomson, M. and J. Winterbottom, "Discovering the Local 1654 Location Information Server (LIS)", 1655 draft-ietf-geopriv-lis-discovery-02 (work in progress), 1656 July 2008. 1658 15.2. Informative References 1660 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1661 RFC 793, September 1981. 1663 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1664 Types", RFC 3023, January 2001. 1666 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1667 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1669 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1670 Configuration Protocol Option for Coordinate-based 1671 Location Configuration Information", RFC 3825, July 2004. 1673 [LLDP-MED] 1674 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1675 Endpoint Discovery". 1677 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1678 Resource Identifier (URI): Generic Syntax", STD 66, 1679 RFC 3986, January 2005. 1681 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 1682 Registration Procedures for New URI Schemes", BCP 115, 1683 RFC 4395, February 2006. 1685 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1686 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1687 May 2008. 1689 [I-D.ietf-geopriv-l7-lcp-ps] 1690 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 1691 Location Configuration Protocol; Problem Statement and 1692 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in 1693 progress), June 2008. 1695 [I-D.ietf-geopriv-lbyr-requirements] 1696 Marshall, R., "Requirements for a Location-by-Reference 1697 Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work 1698 in progress), July 2008. 1700 [I-D.ietf-sip-location-conveyance] 1701 Polk, J. and B. Rosen, "Location Conveyance for the 1702 Session Initiation Protocol", 1703 draft-ietf-sip-location-conveyance-10 (work in progress), 1704 February 2008. 1706 [I-D.winterbottom-geopriv-deref-protocol] 1707 Winterbottom, J., Tschofenig, H., Schulzrinne, H., 1708 Thomson, M., and M. Dawson, "An HTTPS Location 1709 Dereferencing Protocol Using HELD", 1710 draft-winterbottom-geopriv-deref-protocol-02 (work in 1711 progress), July 2008. 1713 Appendix A. HELD Compliance to IETF LCP requirements 1715 This appendix describes HELD's compliance to the requirements 1716 specified in the [I-D.ietf-geopriv-l7-lcp-ps]. 1718 A.1. L7-1: Identifier Choice 1720 "The L7 LCP MUST be able to carry different identifiers or MUST 1721 define an identifier that is mandatory to implement. Regarding the 1722 latter aspect, such an identifier is only appropriate if it is from 1723 the same realm as the one for which the location information service 1724 maintains identifier to location mapping." 1726 COMPLY 1728 HELD uses the IP address of the location request message as the 1729 primary source of identity for the requesting device or target. This 1730 identity can be used with other contextual network information to 1731 provide a physical location for the Target for many network 1732 deployments. There may be network deployments where an IP address 1733 alone is insufficient to identify a Target in a network. However, 1734 any necessary identity extensions for these networks is beyond the 1735 scope of this document. 1737 A.2. L7-2: Mobility Support 1739 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 1740 broad range of mobility from devices that can only move between 1741 reboots, to devices that can change attachment points with the impact 1742 that their IP address is changed, to devices that do not change their 1743 IP address while roaming, to devices that continuously move by being 1744 attached to the same network attachment point." 1746 COMPLY 1747 Mobility support is inherently a characteristic of the access network 1748 technology and HELD is designed to be access network agnostic. 1749 Consequently HELD complies with this requirement. In addition HELD 1750 provides specific support for mobile environments by providing an 1751 optional responseTime attribute in location request messages. 1752 Wireless networks often have several different mechanisms at their 1753 disposal for position determination (e.g. Assisted GPS versus 1754 location based on serving base station identity), each providing 1755 different degrees of accuracy and taking different amounts of time to 1756 yield a result. The responseTime parameter provides the LIS with a 1757 criterion which it can use to select a location determination 1758 technique. 1760 A.3. L7-3: ASP and Access Network Provider Relationship 1762 "The design of the L7 LCP MUST NOT assume a business or trust 1763 relationship between the Application Service Provider (ASP) and the 1764 Access Network Provider. Requirements for resolving a reference to 1765 location information are not discussed in this document." 1767 COMPLY 1769 HELD describes a location acquisition protocol between a Device and a 1770 LIS. In the context of HELD, the LIS is within the Access Network. 1771 Thus, HELD is independent of the business or trust relationship 1772 between the Application Service Provider (ASP) and the Access Network 1773 Provider. Location acquisition using HELD is subject to the 1774 restrictions described in Section 9. 1776 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship 1778 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1779 MUST assume that there is a trust and business relationship between 1780 the L2 and the L3 provider. The L3 provider operates the LIS and 1781 needs to obtain location information from the L2 provider since this 1782 one is closest to the end host. If the L2 and L3 provider for the 1783 same host are different entities, they cooperate for the purposes 1784 needed to determine end system locations." 1786 COMPLY 1788 HELD was specifically designed with this model in mind and readily 1789 allows itself to chaining requests between operators without a change 1790 in protocol being required. HELD is a webservices protocol it can be 1791 bound to transports other than HTTP. Using o offers the option of 1792 high request throughput over a dedicated connection between an L3 1793 provider and an L2 provider without incurring the serial restriction 1794 imposed by HTTP. This is less easy to do with protocols that do not 1795 decouple themselves from the transport. 1797 A.5. L7-5: Legacy Device Considerations 1799 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1800 MUST consider legacy residential NAT devices and NTEs in an DSL 1801 environment that cannot be upgraded to support additional protocols, 1802 for example to pass additional information through DHCP." 1804 COMPLY 1806 HELD is an application protocol and operates on top of IP. A HELD 1807 request from a host behind a residential NAT will traverse the NAT 1808 acquiring the external address of the home router. The location 1809 provided to the host therefore will be the address of the home router 1810 in this circumstance. No changes are required to the home router in 1811 order to support this function, HELD was designed specifically to 1812 address this deployment scenario. 1814 A.6. L7-6: VPN Awareness 1816 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1817 MUST assume that at least one end of a VPN is aware of the VPN 1818 functionality. In an enterprise scenario, the enterprise side will 1819 provide the LIS used by the client and can thereby detect whether the 1820 LIS request was initiated through a VPN tunnel." 1822 COMPLY 1824 HELD does not preclude a LIS on the far end of a VPN tunnel being 1825 aware that the client request is occurring over that tunnel. It also 1826 does not preclude a client device from accessing a LIS serving the 1827 local physical network and subsequently using the location 1828 information with an application that is accessed over a VPN tunnel. 1830 A.7. L7-7: Network Access Authentication 1832 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1833 MUST NOT assume prior network access authentication." 1835 COMPLY 1837 HELD makes no assumptions about prior network access authentication. 1838 HELD strongly recommends the use of TLS with server-side certificates 1839 for communication between the end-point and the LIS. There is no 1840 requirement for the end-point to authenticate with the LIS. 1842 A.8. L7-8: Network Topology Unawareness 1844 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1845 MUST NOT assume end systems being aware of the access network 1846 topology. End systems are, however, able to determine their public 1847 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." 1849 COMPLY 1851 HELD makes no assumption about the network topology. HELD doesn't 1852 require that the device know its external IP address, except where 1853 that is required for discovery of the LIS. 1855 A.9. L7-9: Discovery Mechanism 1857 "The L7 LCP MUST define a single mandatory to implement discovery 1858 mechanism." 1860 COMPLY 1862 HELD uses the discovery mechanism in 1863 [I-D.ietf-geopriv-lis-discovery]. 1865 A.10. L7-10: PIDF-LO Creation 1867 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the 1868 element into the element of the presence document 1869 (see RFC 4479). This ensures that the resulting PIDF-LO document, 1870 which is subsequently distributed to other entities, conforms to the 1871 rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile] 1873 COMPLY 1875 HELD protocol overview (Section 4 ) describes the requirements on the 1876 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated 1877 by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile]. 1879 Authors' Addresses 1881 Mary Barnes (editor) 1882 Nortel 1883 2201 Lakeside Blvd 1884 Richardson, TX 1886 Email: mary.barnes@nortel.com 1887 James Winterbottom 1888 Andrew 1889 PO Box U40 1890 Wollongong University Campus, NSW 2500 1891 AU 1893 Phone: +61 2 4221 2938 1894 Email: james.winterbottom@andrew.com 1895 URI: http://www.andrew.com/ 1897 Martin Thomson 1898 Andrew 1899 PO Box U40 1900 Wollongong University Campus, NSW 2500 1901 AU 1903 Phone: +61 2 4221 2915 1904 Email: martin.thomson@andrew.com 1905 URI: http://www.andrew.com/ 1907 Barbara Stark 1908 BellSouth 1909 Room 7A43 1910 725 W Peachtree St. 1911 Atlanta, GA 30308 1912 US 1914 Email: barbara.stark@att.com 1916 Full Copyright Statement 1918 Copyright (C) The IETF Trust (2008). 1920 This document is subject to the rights, licenses and restrictions 1921 contained in BCP 78, and except as set forth therein, the authors 1922 retain all their rights. 1924 This document and the information contained herein are provided on an 1925 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1926 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1927 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1928 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1929 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1930 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1932 Intellectual Property 1934 The IETF takes no position regarding the validity or scope of any 1935 Intellectual Property Rights or other rights that might be claimed to 1936 pertain to the implementation or use of the technology described in 1937 this document or the extent to which any license under such rights 1938 might or might not be available; nor does it represent that it has 1939 made any independent effort to identify any such rights. Information 1940 on the procedures with respect to rights in RFC documents can be 1941 found in BCP 78 and BCP 79. 1943 Copies of IPR disclosures made to the IETF Secretariat and any 1944 assurances of licenses to be made available, or the result of an 1945 attempt made to obtain a general license or permission for the use of 1946 such proprietary rights by implementers or users of this 1947 specification can be obtained from the IETF on-line IPR repository at 1948 http://www.ietf.org/ipr. 1950 The IETF invites any interested party to bring to its attention any 1951 copyrights, patents or patent applications, or other proprietary 1952 rights that may cover technology that may be required to implement 1953 this standard. Please address the information to the IETF at 1954 ietf-ipr@ietf.org.