idnits 2.17.00 (12 Aug 2021) /tmp/idnits37192/draft-ietf-geopriv-http-location-delivery-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 (February 25, 2009) is 4833 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 2818 == Outdated reference: draft-ietf-geopriv-pdif-lo-profile has been published as RFC 5491 == Outdated reference: draft-ietf-geopriv-lis-discovery has been published as RFC 5986 -- 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 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-geopriv-l7-lcp-ps has been published as RFC 5687 == Outdated reference: draft-ietf-geopriv-lbyr-requirements has been published as RFC 5808 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-12 == Outdated reference: A later version (-05) exists of draft-winterbottom-geopriv-deref-protocol-03 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 5 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: August 29, 2009 7 February 25, 2009 9 HTTP Enabled Location Delivery (HELD) 10 draft-ietf-geopriv-http-location-delivery-13.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 29, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 A Layer 7 Location Configuration Protocol (L7 LCP) is described that 49 is used for retrieving location information from a server within an 50 access network. The protocol includes options for retrieving 51 location information in two forms: by value and by reference. The 52 protocol is an extensible application-layer protocol that is 53 independent of session-layer. This document describes the use of 54 HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer 55 Security (HTTP/TLS) as transports for the protocol. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 61 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7 64 4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 7 65 4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8 66 4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 8 67 4.3. Location by Reference . . . . . . . . . . . . . . . . . . 9 68 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 10 70 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10 71 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10 72 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 11 73 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 74 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 12 75 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 76 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14 77 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14 78 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15 79 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15 80 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15 81 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16 82 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16 83 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 9.1. Assuring that the proper LIS has been contacted . . . . . 23 87 9.2. Protecting responses from modification . . . . . . . . . . 24 88 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24 89 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 25 91 10.2. Simple Location Request Example . . . . . . . . . . . . . 27 92 10.3. Location Request Example for Multiple Location Types . . . 28 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 94 11.1. URN Sub-Namespace Registration for 95 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 29 97 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 30 98 11.3. MIME Media Type Registration for 'application/held+xml' . 30 99 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 31 100 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 102 14. Changes since last Version . . . . . . . . . . . . . . . . . . 33 103 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 104 15.1. Normative References . . . . . . . . . . . . . . . . . . . 39 105 15.2. Informative References . . . . . . . . . . . . . . . . . . 40 106 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 41 107 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 41 108 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 42 109 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 42 110 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 42 111 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 43 112 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 43 113 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 44 114 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 44 115 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 44 116 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 44 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 119 1. Introduction 121 The location of a Device is information that is useful for a number 122 of applications. The L7 Location Configuration Protocol (LCP) 123 problem statement and requirements document 124 [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a 125 Device might rely on its access network to provide location 126 information. The Location Information Server (LIS) service applies 127 to access networks employing both wired technology (e.g. DSL, Cable) 128 and wireless technology (e.g. WiMAX) with varying degrees of Device 129 mobility. This document describes a protocol that can be used to 130 acquire Location Information (LI) from a LIS within an access 131 network. 133 This specification identifies two types of location information that 134 may be retrieved from the LIS. Location may be retrieved from the 135 LIS by value, that is, the Device may acquire a literal location 136 object describing the location of the Device. The Device may also 137 request that the LIS provide a location reference in the form of a 138 location URI or set of location URIs, allowing the Device to 139 distribute its LI by reference. Both of these methods can be 140 provided concurrently from the same LIS to accommodate application 141 requirements for different types of location information. 143 This specification defines an extensible XML-based protocol that 144 enables the retrieval of LI from a LIS by a Device. This protocol 145 can be bound to any session-layer protocol, particularly those 146 capable of MIME transport. This document describes the use of 147 HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer 148 Security (HTTP/TLS) as transports for the protocol. 150 2. Conventions & Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 This document uses the terms (and their acronym forms) Access 157 Provider (AP), Location Information (LI), Location Object (LO), 158 Device, Target, Location Generator (LG), Location Recipient (LR), 159 Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV 160 Requirements [RFC3693] . The terms Location Information Server 161 (LIS), Access Network, Access Provider (AP) and Access Network 162 Provider are used in the same context as defined in the L7 LCP 163 Problem statement and Requirements document 164 [I-D.ietf-geopriv-l7-lcp-ps]. The usage of the terms, Civic 165 Location/Address and Geodetic Location follows the usage in many of 166 the referenced documents. 168 In describing the protocol, the terms "attribute" and "element" are 169 used according to their context in XML. The term "parameter" is used 170 in a more general protocol context and can refer to either an XML 171 "attribute" or "element". 173 3. Overview and Scope 175 This document describes an interface between a Device and a Location 176 Information Server (LIS). This document assumes that the LIS is 177 present within the same administrative domain as the Device (e.g., 178 the access network). An Access Provider (AP) operates the LIS so 179 that Devices (and Targets) can retrieve their LI. The LIS exists 180 because not all Devices are capable of determining LI, and because, 181 even if a device is able to determine its own LI, it may be more 182 efficient with assistance. This document does not specify how LI is 183 determined. 185 This document is based on the attribution of the LI to a Device and 186 not specifically a person (end user) or Target, based on the premise 187 that location determination technologies are generally designed to 188 locate a device and not a person. It is expected that, for most 189 applications, LI for the device can be used as an adequate substitute 190 for the end user's LI. Since revealing the location of the device 191 almost invariably reveals some information about the location of the 192 user of the device, the same level of privacy protection demanded by 193 a user is required for the device. This approach may require either 194 some additional assurances about the link between device and target, 195 or an acceptance of the limitation that unless the device requires 196 active user authentication, there is no guarantee that any particular 197 individual is using the device at that instant. 199 The following diagram shows the logical configuration of some of the 200 functional elements identified in [RFC3693] and the LIS defined in 201 [I-D.ietf-geopriv-l7-lcp-ps] and where this protocol applies, with 202 the Rule Maker and Target represented by the role of the Device. 203 Note that only the interfaces relevant to the Device are identified 204 in the diagram. 206 +---------------------------------------------+ 207 | Access Network Provider | 208 | | 209 | +--------------------------------------+ | 210 | | Location Information Server | | 211 | | | | 212 | | | | 213 | | | | 214 | | | | 215 | +------|-------------------------------+ | 216 +----------|----------------------------------+ 217 | 218 | 219 HELD 220 | 221 Rule Maker - _ +-----------+ +-----------+ 222 o - - | Device | | Location | 223 745 753 754 755 This document (RFC xxxx) defines HELD messages. 756 758 759 761 764 765 766 767 768 769 771 772 774 775 776 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 812 813 814 815 816 817 818 819 820 821 822 824 825 826 827 829 830 831 833 834 835 836 837 838 840 841 842 843 845 846 847 848 849 851 852 854 856 857 858 859 861 863 865 866 867 868 869 870 873 875 876 877 878 879 881 884 886 887 888 889 890 893 895 896 897 898 900 903 905 8. HTTP Binding 907 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 908 [RFC2818] as transport mechanisms for the HELD protocol, which a 909 conforming LIS and Device MUST support. 911 Although HELD uses HTTP as a transport, it uses a strict subset of 912 HTTP features, and due to the restrictions of some features, a LIS is 913 not a fully compliant HTTP server. It is intended that a LIS can 914 easily be built using an HTTP server with extensibility mechanisms, 915 and that a HELD Device can trivially use existing HTTP libraries. 916 This subset of requirements helps implementors avoid ambiguity with 917 the many options the full HTTP protocol offers. The LIS MUST NOT 918 rely on device support for cookies [RFC2965] or use Basic or Digest 919 authentication [RFC2617]. 921 A HELD request is carried in the body of an HTTP POST request. The 922 Device MUST include a Host header in the request. 924 The MIME type of HELD request and response bodies is 925 "application/held+xml". LIS and Device MUST provide this value in 926 the HTTP Content-Type and Accept header fields.If the LIS does not 927 receive the appropriate Content-Type and Accept header fields, the 928 LIS SHOULD fail the request, returning a 406 (not acceptable) 929 response. HELD responses SHOULD include a Content-Length header. 931 Devices MUST NOT use the "Expect" header or the "Range" header in 932 HELD requests. The LIS MAY return 501 (not implemented) errors if 933 either of these HTTP features are used. In the case that the LIS 934 receives a request from the Device containing a If-* (conditional) 935 header, the LIS SHOULD return a 412 (precondition failed) response. 937 The POST method is the only method REQUIRED for HELD. If a LIS 938 chooses to support GET or HEAD, it SHOULD consider the kind of 939 application doing the GET. Since a HELD Device only uses a POST 940 method, the GET or HEAD MUST be either an escaped URL (e.g., somebody 941 found a URL in protocol traces or log files and fed it into their 942 browser) or somebody doing testing/ debugging. The LIS could provide 943 information in the HELD response indicating that the URL corresponds 944 to a LIS server and only responds to HELD POST requests or the LIS 945 could instead try to avoid any leak of information by returning a 946 very generic HTTP error message such as 404 (not found). 948 The LIS populates the HTTP headers of responses so that they are 949 consistent with the contents of the message. In particular, the 950 "CacheControl" header SHOULD be set to disable caching of any PIDF-LO 951 document or Location URIs by HTTP intermediaries. Otherwise, there 952 is the risk of stale locations and/or the unauthorized disclosure of 953 the LI. This also allows the LIS to control any caching with the 954 HELD "expires" parameter. The HTTP status code MUST indicate a 2xx 955 series response for all HELD locationResponse and HELD error 956 messages. 958 The LIS MAY redirect a HELD request. A Device MUST handle redirects, 959 by using the Location header provided by the server in a 3xx 960 response. When redirecting, the Device MUST observe the delay 961 indicated by the Retry-After header. The Device MUST authenticate 962 the server that returns the redirect response before following the 963 redirect. A Device SHOULD authenticate the LIS indicated in a 964 redirect. 966 The LIS SHOULD support persistent connections and request pipelining. 967 If pipelining is not supported, the LIS MUST NOT allow persistent 968 connections. The Device MUST support termination of a response by 969 the closing of a connection. 971 The use of HTTP also includes a default behaviour, which is triggered 972 by a POST with no request body. If either of these queries are 973 received, the LIS MUST attempt to provide either a PIDF-LO document 974 or a Location URI, as if the request was a location request. 976 Implementations of HELD that implement HTTP transport MUST implement 977 transport over TLS [RFC2818]. TLS provides message integrity and 978 confidentiality between Device and LIS. The Device MUST implement 979 the server authentication method described in HTTPS [RFC2818]. The 980 device uses the URI obtained during LIS discovery to authenticate the 981 server. The details of this authentication method are provided in 982 section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device SHOULD 983 fail a request if server authentication fails, except in the event of 984 an emergency. 986 9. Security Considerations 988 HELD is a location acquisition protocol whereby the a client requests 989 its location from a LIS. Specific requirements and security 990 considerations for location acquisition protocols are provided in 991 [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security 992 considerations applicable to the use of Location URIs and by 993 reference provision of LI is included in 994 [I-D.ietf-geopriv-lbyr-requirements]. 996 By using the HELD protocol, the client and the LIS expose themselves 997 to two types of risk: 999 Accuracy: Client receives incorrect location information 1000 Privacy: An unauthorized entity receives location information 1002 The provision of an accurate and privacy/confidentiality protected 1003 location to the requestor depends on the success of five steps: 1005 1. The client must determine the proper LIS. 1006 2. The client must connect to the proper LIS. 1007 3. The LIS must be able to identify the device by its identifier 1008 (IP Address). 1009 4. The LIS must be able to return the desired location. 1010 5. HELD messages must be transmitted unmodified between the LIS 1011 and the client. 1013 Of these, only the second, third and the fifth are within the scope 1014 of this document. The first step is based on either manual 1015 configuration or on the LIS discovery defined in 1016 [I-D.ietf-geopriv-lis-discovery], in which appropriate security 1017 considerations are already discussed. The fourth step is dependent 1018 on the specific positioning capabilities of the LIS, and is thus 1019 outside the scope of this document. 1021 9.1. Assuring that the proper LIS has been contacted 1023 This document assumes that the LIS to be contacted is identified 1024 either by an IP address or a domain name, as is the case for a LIS 1025 discovered as described in LIS Discovery 1026 [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is 1027 conducted using TLS [RFC5246], the LIS can authenticate its identity, 1028 either as a domain name or as an IP address, to the client by 1029 presenting a certificate containing that identifier as a 1030 subjectAltName (i.e., as an iPAddress or dNSName, respectively). In 1031 the case of the HTTP binding described above, this is exactly the 1032 authentication described by TLS [RFC2818]. If the client has 1033 external information as to the expected identity or credentials of 1034 the proper LIS (e.g., a certificate fingerprint), these checks MAY be 1035 omitted. Any binding of HELD MUST be capable of being transacted 1036 over TLS so that the client can request the above authentication, and 1037 a LIS implementation for a binding MUST include this feature. Note 1038 that in order for the presented certificate to be valid at the 1039 client, the client must be able to validate the certificate. In 1040 particular, the validation path of the certificate must end in one of 1041 the client's trust anchors, even if that trust anchor is the LIS 1042 certificate itself. 1044 9.2. Protecting responses from modification 1046 In order to prevent that response from being modified en route, 1047 messages must be transmitted over an integrity-protected channel. 1048 When the transaction is being conducted over TLS (a required feature 1049 per Section 9.1), the channel will be integrity protected by 1050 appropriate ciphersuites. When TLS is not used, this protection will 1051 vary depending on the binding; in most cases, without protection from 1052 TLS, the response will not be protected from modification en route. 1054 9.3. Privacy and Confidentiality 1056 Location information returned by the LIS must be protected from 1057 access by unauthorized parties, whether those parties request the 1058 location from the LIS or intercept it en route. As in Section 9.2, 1059 transactions conducted over TLS with appropriate ciphersuites are 1060 protected from access by unauthorized parties en route. Conversely, 1061 in most cases, when not conducted over TLS, the response will be 1062 accessible while en route from the LIS to the requestor. 1064 Because HELD is an LCP and identifies clients and targets by IP 1065 addresses, a requestor is authorized to access location for an IP 1066 address only if it is the holder of that IP address. The LIS MUST 1067 verify that the client is the target of the returned location, i.e., 1068 the LIS MUST NOT provide location to other entities than the target. 1069 Note that this is a necessary, but not sufficient criterion for 1070 authorization. A LIS MAY deny requests according to any local 1071 policy. 1073 A prerequisite for meeting this requirement is that the LIS must have 1074 some assurance of the identity of the client. Since the target of 1075 the returned location is identified by an IP address, simply sending 1076 the response to this IP address will provide sufficient assurance in 1077 many cases. This is the default mechanism in HELD for assuring that 1078 location is given only to authorized clients; LIS implementations 1079 MUST support a mode of operation in which this is the only client 1080 authentication. 1082 Using IP return routability as an authenticator means that location 1083 information is vulnerable to exposure through IP address spoofing 1084 attacks. A temporary spoofing of IP address could mean that a device 1085 could request a Location Object or Location URI that would result in 1086 another Device's location. In addition, in cases where a Device 1087 drops off the network for various reasons, the re-use of the Device's 1088 IP address could result in another Device receiving the original 1089 Device's location rather than its own location. These exposures are 1090 limited by the following: 1092 o Location URIs MUST have a limited lifetime, as reflected by the 1093 value for the expires element in Section 6.5.2. The lifetime of 1094 location URIs necessarily depends on the nature of the access. 1095 o The LIS and network SHOULD be configured so that the LIS is made 1096 aware of Device movement within the network and addressing 1097 changes. If the LIS detects a change in the network that results 1098 in it no longer being able to determine the location of the 1099 Device, then all location URIs for that Device SHOULD be 1100 invalidated. 1102 The above measures are dependent on network configuration, which 1103 SHOULD be considered. For instance, in a fixed internet access, 1104 providers may be able to restrict the allocation of IP addresses to a 1105 single physical line, ensuring that spoofing is not possible; in such 1106 an environment, additional measures may not be necessary. 1108 10. Examples 1110 The following sections provide basic HTTP/HTTPS examples, a simple 1111 location request example and a location request for multiple location 1112 types example along with the relevant location responses. To focus 1113 on important portions of messages, the examples in Section 10.2 and 1114 Section 10.3 do not show HTTP/HTTPS headers or the XML prologue. In 1115 addition, sections of XML not relevant to the example are replaced 1116 with comments. 1118 10.1. HTTPS Example Messages 1120 The examples in this section show complete HTTP/HTTPS messages that 1121 include the HELD request or response document. 1123 This example shows the most basic request for a LO. The POST 1124 includes an empty "locationRequest" element. 1126 POST /location HTTP/1.1 1127 Host: lis.example.com:49152 1128 Content-Type: application/held+xml 1129 Content-Length: 87 1131 1132 1134 Since the above request does not include a "locationType" element, 1135 the successful response to the request may contain any type of 1136 location. The following shows a response containing a minimal 1137 PIDF-LO. 1139 HTTP/1.1 200 OK 1140 Server: Example LIS 1141 Date: Tue, 10 Jan 2006 03:42:29 GMT 1142 Expires: Tue, 10 Jan 2006 03:42:29 GMT 1143 Cache-control: private 1144 Content-Type: application/held+xml 1145 Content-Length: 594 1147 1148 1149 1151 1152 1153 1154 1155 1157 -34.407 150.88001 1158 1159 1160 1161 1162 2006-01-11T03:42:28+00:00 1163 1164 Wiremap 1165 1166 1167 2006-01-10T03:42:28+00:00 1168 1169 1170 1172 The error response to the request is an error document. The 1173 following response shows an example error response. 1175 HTTP/1.1 200 OK 1176 Server: Example LIS 1177 Expires: Tue, 10 Jan 2006 03:49:20 GMT 1178 Cache-control: private 1179 Content-Type: application/held+xml 1180 Content-Length: 135 1182 1183 1187 10.2. Simple Location Request Example 1189 The location request shown below doesn't specify any location types 1190 or response time. 1192 1194 The example response to this location request contains a list of 1195 Location URIs. 1197 1198 1199 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1200 1201 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 1202 1203 1204 1206 An error response to this location request is shown below: 1208 1212 10.3. Location Request Example for Multiple Location Types 1214 The following Location Request message includes a request for 1215 geodetic, civic and any Location URIs. 1217 1218 1219 geodetic 1220 civic 1221 locationURI 1222 1223 1225 The corresponding Location Response message includes the requested 1226 location information, including two location URIs. 1228 1229 1230 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1231 1232 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 1233 1234 1235 1237 1238 1239 1240 1241 1245 -34.407242 150.882518 1246 30 1247 1249 1250 1253 AU 1254 NSW 1255 Wollongong 1256 Gwynneville 1257 Northfield Avenue 1258 University of Wollongong 1259 2 1260 Andrew Corporation 1261 2500 1262 39 1263 WS-183 1264 U40 1265 1266 1267 1268 false 1269 2007-05-25T12:35:02+10:00 1270 1271 1272 Wiremap 1273 1274 1275 2007-05-24T12:35:02+10:00 1276 1277 1278 1280 11. IANA Considerations 1282 This document requires several IANA registrations detailed in the 1283 following sections. 1285 11.1. URN Sub-Namespace Registration for 1286 urn:ietf:params:xml:ns:geopriv:held 1288 This section registers a new XML namespace, 1289 "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in 1290 [RFC3688]. 1292 URI: urn:ietf:params:xml:ns:geopriv:held 1293 Registrant Contact: IETF, GEOPRIV working group, 1294 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1295 XML: 1297 BEGIN 1298 1299 1301 1302 1303 HELD Messages 1304 1305 1306

Namespace for HELD Messages

1307

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

1308 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1309 with the RFC number for this specification.] 1310

See RFCXXXX

1311 1312 1313 END 1315 11.2. XML Schema Registration 1317 This section registers an XML schema as per the guidelines in 1318 [RFC3688]. 1320 URI: urn:ietf:params:xml:schema:geopriv:held 1321 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1322 Mary Barnes (mary.barnes@nortel.com). 1323 Schema: The XML for this schema can be found as the entirety of 1324 Section 7 of this document. 1326 11.3. MIME Media Type Registration for 'application/held+xml' 1328 This section registers the "application/held+xml" MIME type. 1330 To: ietf-types@iana.org 1331 Subject: Registration of MIME media type application/held+xml 1332 MIME media type name: application 1333 MIME subtype name: held+xml 1334 Required parameters: (none) 1335 Optional parameters: charset 1336 Indicates the character encoding of enclosed XML. Default is 1337 UTF-8. 1339 Encoding considerations: Uses XML, which can employ 8-bit 1340 characters, depending on the character encoding used. See RFC 1341 3023 [RFC3023], section 3.2. 1342 Security considerations: This content type is designed to carry 1343 protocol data related to the location of an entity, which could 1344 include information that is considered private. Appropriate 1345 precautions should be taken to limit disclosure of this 1346 information. 1347 Interoperability considerations: This content type provides a basis 1348 for a protocol 1349 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please 1350 replace XXXX with the RFC number for this specification.] 1351 Applications which use this media type: Location information 1352 providers and consumers. 1353 Additional Information: Magic Number(s): (none) 1354 File extension(s): .xml 1355 Macintosh File Type Code(s): (none) 1356 Person & email address to contact for further information: Mary 1357 Barnes 1358 Intended usage: LIMITED USE 1359 Author/Change controller: The IETF 1360 Other information: This media type is a specialization of 1361 application/xml [RFC3023], and many of the considerations 1362 described there also apply to application/held+xml. 1364 11.4. Error code Registry 1366 This document requests that the IANA create a new registry for the 1367 HELD protocol including an initial registry for error codes. The 1368 error codes are included in HELD error messages as described in 1369 Section 6.3 and defined in the schema in the 'codeType' token in the 1370 XML schema in (Section 7) 1372 The following summarizes the requested registry: 1374 Related Registry: Geopriv HELD Registries, Error codes for HELD 1375 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1376 with the RFC number for this specification.] 1377 Registration/Assignment Procedures: Following the policies outlined 1378 in [RFC5226], the IANA policy for assigning new values for the 1379 Error codes for HELD shall be Specification Required: values and 1380 their meanings must be documented in an RFC or in some other 1381 permanent and readily available reference, in sufficient detail 1382 that interoperability between independent implementations is 1383 possible. 1385 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1386 Mary Barnes (mary.barnes@nortel.com). 1388 This section pre-registers the following seven initial error codes as 1389 described above in Section 6.3: 1391 requestError: This code indicates that the request was badly formed 1392 in some fashion. 1393 xmlError: This code indicates that the XML content of the request 1394 was either badly formed or invalid. 1395 generalLisError: This code indicates that an unspecified error 1396 occurred at the LIS. 1397 locationUnknown: This code indicates that the LIS could not 1398 determine the location of the Device. 1399 unsupportedMessage: This code indicates that the request was not 1400 supported or understood by the LIS. This error code is used when 1401 a HELD request contains a document element that is not supported 1402 by the receiver. 1403 timeout: This code indicates that the LIS could not satisfy the 1404 request within the time specified in the "responseTime" parameter. 1405 cannotProvideLiType: This code indicates that the LIS was unable to 1406 provide LI of the type or types requested. This code is used when 1407 the "exact" attribute on the "locationType" parameter is set to 1408 "true". 1409 notLocatable: This code indicates that the LIS is unable to locate 1410 the Device, and that the Device MUST NOT make further attempts to 1411 retrieve LI from this LIS. This error code is used to indicate 1412 that the Device is outside the access network served by the LIS; 1413 for instance, the VPN and NAT scenarios discussed in 1414 Section 4.1.2. 1416 12. Contributors 1418 James Winterbottom, Martin Thomson and Barbara Stark are the authors 1419 of the original document, from which this WG document was derived. 1420 Their contact information is included in the Author's address 1421 section. In addition, they also contributed to the WG document, 1422 including the XML schema. 1424 13. Acknowledgements 1426 The author/contributors would like to thank the participants in the 1427 GEOPRIV WG and the following people for their constructive input and 1428 feedback on this document (in alphabetical order): Nadine Abbott, 1429 Eric Arolick, Richard Barnes (in particular the security section), 1430 Peter Blatherwick, Ben Campbell, Guy Caron, Eddy Corbett, Martin 1431 Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings, 1432 Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger 1433 Marshall, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, 1434 Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed 1435 Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf. 1437 14. Changes since last Version 1439 NOTE TO THE RFC-Editor: Please remove this section prior to 1440 publication as an RFC. 1442 Changes from WG 12 to 13 (Post-2nd WGLC): 1444 1) Fixed editorial error in section 6.2 with regards to empty 1445 "locationType" - error was introduced in 06 to 07 changes. 1447 2) Added additional text in section 6.5.1 to improve security 1448 associated with locationURIs. 1450 3) Modified XML schema for errorType and responseType to allow an 1451 attribute to be returned. Also, added extensibility to errorType. 1453 Changes from WG 11 to 12 (Post-2nd WGLC): 1455 1) Expanded text in section 8 (HTTP binding) to provide more detail 1456 about the requirements for an HTTP implementation supporting HELD. 1457 Clarified the mandatory functionality and specific handling of other 1458 functionality of HTTP. 1460 2) Clarification in section 9.1 for clients that have external info 1461 wrt the identity or credentials of the LIS. 1463 3) More nits. 1465 Changes from WG 10 to 11 (Post-2nd WGLC): 1467 1) Added additional text around the scope and applicability of the 1468 URI returned from LIS Discovery (section 4). 1470 2) Removed HTTP GET - will always use POST. 1472 3) Removed sentence wrt mobile devices in section 6.2. 1474 4) Added specific recommendation for minimum value for expires in 1475 section 6.5.2 (30 Minutes). 1477 5) Remove reference to RFC 3704 (for IP address spoofing) in section 1478 9.3 (bullet 2). 1480 6) Clarified that both HTTP and HTTPS are allowed - changed last 1481 bullet in section 5.1 from REQUIRES to RECOMMENDS. 1483 7) Clarification wrt "presence" parameter in section 6.6 - a "single" 1484 presence parameter may be included. 1486 Changes from WG 09 to 10 (2nd WGLC): 1488 1) Updated text for Devices and VPNs (section 4.1.1) to include 1489 servers such as HTTP and SOCKs, thus changed the text to be generic 1490 in terms of locating LIS before connecting to one of these servers, 1491 etc. 1493 2) Fixed (still buggy) HTTP examples. 1495 3) Added text explaining the whitespaces in XML schema are for 1496 readability/document format limitations and that they should be 1497 handled via parser/schema validation. 1499 4) Miscellaneous editorial nits 1501 Changes from WG 08 to 09 (Post-IETF LC: continued resolution of sec- 1502 dir and gen-art review comments, along with apps-area feedback): 1504 1) Removed heldref/heldrefs URIs, including fixing examples (which 1505 were buggy anyways). 1507 2) Clarified text for locationURI - specifying that the deref 1508 protocol must define or appropriately restrict and clarifying that 1509 requirements for deref must be met and that deref details are out of 1510 scope for this document. 1512 3) Clarified text in security section for support of both HTTP/HTTPS. 1514 4) Changed definition for Location Type to force the specification of 1515 at least one location type. 1517 Changes from WG 07 to 08 (IETF LC: sec-dir and gen-art review 1518 comments): 1520 1) Fix editorial nits: rearranging sections in 4.1 for readibility, 1521 etc. 1523 2) Added back text in Device and VPN section referencing DHCP and 1524 LLDP-MED when a VPN device serves as a LIS. 1526 3) Clarified the use of both HTTP and HTTPS. 1528 4) Defined two URIs related to 3 respectively - divided IANA 1529 registrations into sub-sections to accomodate this change. (Note: 1530 LIS Discovery will now define that URI, thus this document defines 1531 the one associatied with a Location reference). 1533 5) Clarified the description of the location URI in Protocol Overview 1534 and Protocol parameter sections. Note that these sections again 1535 reference location dereference protocol for completeness and 1536 clarification of issues that are out of scope for this base document. 1538 6) Defined new error code: notLocatable. 1540 7) Clarifications and corrections in security section. 1542 8) Clarified text for locationType, specifically removing extra text 1543 from "any" description and putting that in a separate paragraph. 1544 Also, provided an example. 1546 9) Added boundaries for "expires" parameter. 1548 10) Clarified that the HELD protocol as defined by this document does 1549 not allow for canceling location references. 1551 Changes from WG 06 to 07 (PROTO review comments): 1553 1) Fix nits: remove unused references, move requirements to 1554 Informational References section, fix long line in ABNF, fix ABNF 1555 (quotes around '?'), add schemaLocation to import namespace in XML 1556 schema. 1558 2) Remove text in Device and VPN section referencing DHCP and LLDP- 1559 MED when a VPN device serves as a LIS, per Issue 1 resolution at 1560 IETF-71. (Editorial oversight in producing version 06). 1562 Changes from WG 05 to 06 (2nd WGLC comments): 1564 1) Updated security section based on WG feedback, including 1565 condensing section 10.1.1 (Assuring the proper LIS has been 1566 contacted), restructuring sections by flattening, adding an 1567 additional step to the list that had been in the Accuracy section and 1568 removing summary section. 1570 2) Changed URI schema to "helds" to address concerns over referential 1571 integrity and for consistency with mandate of TLS for HELD. 1573 3) Editorial clarifications including fixing examples to match HELD 1574 URI definition (e.g., adding port, adding randomness to URI examples, 1575 etc.) 1577 4) Updated references removing unused references and moving 1578 requirements docs to Informational Reference section to avoid 1579 downrefs. 1581 Changes from WG 04 to 05 (WGLC comments): 1583 1) Totally replaced the security section with the details provided by 1584 Richard Barnes so that we don't need a reference to the location 1585 security document. 1587 2) Fixed error codes in schema to allow extensibility. Change the 1588 IANA registration to be "specification required". 1590 3) Cleaned up the HELD: URI description, per comments from Martin and 1591 James and partially addressing HELD-04 Issue 1. Put the definition 1592 in a separate section and clarified the applicability (to also 1593 include being a results of the discovery process) and fixed examples. 1595 4) Updated the LocationURI section to be more accurate, address 1596 HELD-04 Issue 3, and include the reference to the new HELD:URI 1597 section. Also, fixed an error in the doc in that the top level parm 1598 in the locationResponse is actually locationUriSet, which contains 1599 any number of locationURI elements and the "expires" parameter. So, 1600 Table 1 was also updated and a new section for the LocationURISet was 1601 added that includes the subsections for the "locationURI" and 1602 "expires". And, then clarified that "expires" applies to 1603 "locationURISet" and not per "locationURI". 1605 5) Editorial nits: pointed out offline by Richard (e.g., by-value -> 1606 by value, by-reference -> by reference, etc.) and onlist by James and 1607 Martin. Please refer to the diff for a complete view of editorial 1608 changes. 1610 6) Added text in HTTP binding section to disable HTTP caching 1611 (HELD-04 Issue 5 on the list). 1613 Changes from WG 03 to 04: 1615 1) Terminology: clarified in terminology section that "attribute" and 1616 "element" are used in the strict XML sense and "parameter" is used as 1617 a general protocol term Replaced term "HTTP delivery" with "HTTP 1618 transport". Still have two terms "HTTP transport" and "HTTP 1619 binding", but those are consistent with general uses of HTTP. 1621 2) Editorial changes and clarifications: per Roger Marshall's and 1622 Eric Arolick's comments and subsequent WG mailing list discussion. 1624 3) Changed normative language for describing expected and recommended 1625 LIS behaviors to be non-normative recommendations in cases where the 1626 protocol parameters were not the target of the discussion (e.g., we 1627 can't prescribe to the LIS how it determines location or what it 1628 defines to be an "accurate" location). 1630 4) Clarified responseTime attribute (section 6.1). Changed type from 1631 "decimal" to "nonNegativeInteger" in XML schema (section 7) 1633 5) Updated Table 1 in section 6 to only include top-level parameters 1634 and fixed some errors in that table (i.e., code for locationResponse) 1635 and adding PIDF-LO to the table. Added a detailed section describing 1636 PIDF-LO (section 6.6), moving some of the normative text in the 1637 Protocol Overview to this section. 1639 6) Added schema and description for locationURI to section 6.5. 1640 Added IANA registration for HELD: URI schema. 1642 7) Added IANA registry for error codes. 1644 Changes from WG 02 to 03: 1646 1) Added text to address concern over use of IP address as device 1647 identifier, per long email thread - changes to section 3 (overview) 1648 and section 4 (protocol overview). 1650 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed) 1652 3) Added extensibility to baseRequestType in the schema (an oversight 1653 from previous edits), along with fixing some other nits in schema 1654 (section 7) 1656 4) Moved discussion of Location URI from section 5.3 (Location 1657 Response) to where it rightly belonged in Section 6.5 (Location URI 1658 Parameter). 1660 5) Clarified text for "expires" parameter (6.5.1) - it's an optional 1661 parm, but required for LocationURIs 1663 6) Clarified responseTime parameter: when missing, then the LCS 1664 provides most precise LI, with the time required being implementation 1665 specific. 1667 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST 1668 implement. 1670 8) Updated references (removed unused/added new). 1672 Changes from WG 01 to 02: 1674 1) Updated Terminology to be consistent with WG agreements and other 1675 documents (e.g., LCS -> LIS and removed duplicate terms). In the 1676 end, there are no new terms defined in this document. 1678 2) Modified definition of responseTime to reflect WG consensus. 1680 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving 1681 just "civic"). 1683 4) Clarified text that locationType is optional. Fixed table 1 and 1684 text in section 5.2 (locationRequest description). Text in section 1685 6.2 (description of locationType element) already defined the default 1686 to be "any". 1688 5) Simplified error responses. Separated the definition of error 1689 response type from the locationResponse type thus no need for 1690 defining an error code of "success". This simplifies the schema and 1691 processing. 1693 6) Updated schema/examples for the above. 1695 7) Updated Appendix A based on updates to requirements document, 1696 specifically changes to A.1, A.3 and adding A.10. 1698 8) Miscellaneous editorial clarifications. 1700 Changes from WG 00 to 01: 1702 1) heldResponse renamed to locationResponse. 1704 2) Changed namespace references for the PIDF-LO geoShape in the 1705 schema to match the agreed GML PIDF-LO Geometry Shape Application 1706 Schema. 1708 3) Removed "options" element - leaving optionality/extensibility to 1709 XML mechanisms. 1711 4) Changed error codes to be enumerations and not redefinitions of 1712 HTTP response codes. 1714 5) Updated schema/examples for the above and removed some remnants of 1715 the context element. 1717 6) Clarified the definition of "Location Information (LI)" to include 1718 a reference to the location (to match the XML schema and provide 1719 consistency of usage throughout the document). Added an additional 1720 statement in section 7.2 (locationType) to clarify that LCS MAY also 1721 return a Location URI. 1723 7) Modifed the definition of "Location Configuration Server (LCS)" to 1724 be consistent with the current definiton in the requirements 1725 document. 1727 8) Updated Location Response (section 6.3) to remove reference to 1728 context and discuss the used of a local identifier or unlinked 1729 pseudonym in providing privacy/security. 1731 9) Clarified that the source IP address in the request is used as the 1732 identifier for the target/device for the HELD protocol as defined in 1733 this document. 1735 10) Miscellaneous editorial clarifications. 1737 15. References 1739 15.1. Normative References 1741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1742 Requirement Levels", BCP 14, RFC 2119, March 1997. 1744 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1745 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1747 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 1748 Mechanism", RFC 2965, October 2000. 1750 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1751 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1752 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1754 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1755 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1756 Authentication: Basic and Digest Access Authentication", 1757 RFC 2617, June 1999. 1759 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1761 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1762 January 2004. 1764 [I-D.ietf-geopriv-pdif-lo-profile] 1765 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1766 PIDF-LO Usage Clarification, Considerations and 1767 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 1768 (work in progress), November 2008. 1770 [W3C.REC-xmlschema-1-20041028] 1771 Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn, 1772 "XML Schema Part 1: Structures Second Edition", World Wide 1773 Web Consortium Recommendation REC-xmlschema-1-20041028, 1774 October 2004, 1775 . 1777 [W3C.REC-xmlschema-2-20041028] 1778 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1779 Second Edition", World Wide Web Consortium 1780 Recommendation REC-xmlschema-2-20041028, October 2004, 1781 . 1783 [I-D.ietf-geopriv-lis-discovery] 1784 Thomson, M. and J. Winterbottom, "Discovering the Local 1785 Location Information Server (LIS)", 1786 draft-ietf-geopriv-lis-discovery-07 (work in progress), 1787 February 2009. 1789 15.2. Informative References 1791 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1792 RFC 793, September 1981. 1794 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1795 Types", RFC 3023, January 2001. 1797 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1798 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1800 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1801 Configuration Protocol Option for Coordinate-based 1802 Location Configuration Information", RFC 3825, July 2004. 1804 [LLDP-MED] 1805 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1806 Endpoint Discovery". 1808 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1809 Resource Identifier (URI): Generic Syntax", STD 66, 1810 RFC 3986, January 2005. 1812 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1813 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1814 May 2008. 1816 [I-D.ietf-geopriv-l7-lcp-ps] 1817 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 1818 Location Configuration Protocol; Problem Statement and 1819 Requirements", draft-ietf-geopriv-l7-lcp-ps-09 (work in 1820 progress), February 2009. 1822 [I-D.ietf-geopriv-lbyr-requirements] 1823 Marshall, R., "Requirements for a Location-by-Reference 1824 Mechanism", draft-ietf-geopriv-lbyr-requirements-06 (work 1825 in progress), February 2009. 1827 [I-D.ietf-sip-location-conveyance] 1828 Polk, J. and B. Rosen, "Location Conveyance for the 1829 Session Initiation Protocol", 1830 draft-ietf-sip-location-conveyance-12 (work in progress), 1831 November 2008. 1833 [I-D.winterbottom-geopriv-deref-protocol] 1834 Winterbottom, J., Tschofenig, H., Schulzrinne, H., 1835 Thomson, M., and M. Dawson, "An HTTPS Location 1836 Dereferencing Protocol Using HELD", 1837 draft-winterbottom-geopriv-deref-protocol-03 (work in 1838 progress), February 2009. 1840 Appendix A. HELD Compliance to IETF LCP requirements 1842 This appendix describes HELD's compliance to the requirements 1843 specified in the [I-D.ietf-geopriv-l7-lcp-ps]. 1845 A.1. L7-1: Identifier Choice 1847 "The L7 LCP MUST be able to carry different identifiers or MUST 1848 define an identifier that is mandatory to implement. Regarding the 1849 latter aspect, such an identifier is only appropriate if it is from 1850 the same realm as the one for which the location information service 1851 maintains identifier to location mapping." 1853 COMPLY 1855 HELD uses the IP address of the location request message as the 1856 primary source of identity for the requesting device or target. This 1857 identity can be used with other contextual network information to 1858 provide a physical location for the Target for many network 1859 deployments. There may be network deployments where an IP address 1860 alone is insufficient to identify a Target in a network. However, 1861 any necessary identity extensions for these networks is beyond the 1862 scope of this document. 1864 A.2. L7-2: Mobility Support 1866 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 1867 broad range of mobility from devices that can only move between 1868 reboots, to devices that can change attachment points with the impact 1869 that their IP address is changed, to devices that do not change their 1870 IP address while roaming, to devices that continuously move by being 1871 attached to the same network attachment point." 1873 COMPLY 1875 Mobility support is inherently a characteristic of the access network 1876 technology and HELD is designed to be access network agnostic. 1877 Consequently HELD complies with this requirement. In addition HELD 1878 provides specific support for mobile environments by providing an 1879 optional responseTime attribute in location request messages. 1880 Wireless networks often have several different mechanisms at their 1881 disposal for position determination (e.g. Assisted GPS versus 1882 location based on serving base station identity), each providing 1883 different degrees of accuracy and taking different amounts of time to 1884 yield a result. The responseTime parameter provides the LIS with a 1885 criterion which it can use to select a location determination 1886 technique. 1888 A.3. L7-3: ASP and Access Network Provider Relationship 1890 "The design of the L7 LCP MUST NOT assume a business or trust 1891 relationship between the Application Service Provider (ASP) and the 1892 Access Network Provider. Requirements for resolving a reference to 1893 location information are not discussed in this document." 1895 COMPLY 1897 HELD describes a location acquisition protocol between a Device and a 1898 LIS. In the context of HELD, the LIS is within the Access Network. 1899 Thus, HELD is independent of the business or trust relationship 1900 between the Application Service Provider (ASP) and the Access Network 1901 Provider. Location acquisition using HELD is subject to the 1902 restrictions described in Section 9. 1904 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship 1906 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1907 MUST assume that there is a trust and business relationship between 1908 the L2 and the L3 provider. The L3 provider operates the LIS and 1909 needs to obtain location information from the L2 provider since this 1910 one is closest to the end host. If the L2 and L3 provider for the 1911 same host are different entities, they cooperate for the purposes 1912 needed to determine end system locations." 1914 COMPLY 1916 HELD was specifically designed with this model in mind and readily 1917 allows itself to chaining requests between operators without a change 1918 in protocol being required. HELD is a webservices protocol which can 1919 be bound to transports other than HTTP, such as BEEP. Using a 1920 protocol such as BEEP offers the option of high request throughput 1921 over a dedicated connection between an L3 provider and an L2 provider 1922 without incurring the serial restriction imposed by HTTP. This is 1923 less easy to do with protocols that do not decouple themselves from 1924 the transport. 1926 A.5. L7-5: Legacy Device Considerations 1928 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1929 MUST consider legacy residential NAT devices and NTEs in an DSL 1930 environment that cannot be upgraded to support additional protocols, 1931 for example to pass additional information through DHCP." 1933 COMPLY 1935 HELD is an application protocol and operates on top of IP. A HELD 1936 request from a host behind a residential NAT will traverse the NAT 1937 acquiring the external address of the home router. The location 1938 provided to the host therefore will be the address of the home router 1939 in this circumstance. No changes are required to the home router in 1940 order to support this function, HELD was designed specifically to 1941 address this deployment scenario. 1943 A.6. L7-6: VPN Awareness 1945 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1946 MUST assume that at least one end of a VPN is aware of the VPN 1947 functionality. In an enterprise scenario, the enterprise side will 1948 provide the LIS used by the client and can thereby detect whether the 1949 LIS request was initiated through a VPN tunnel." 1951 COMPLY 1953 HELD does not preclude a LIS on the far end of a VPN tunnel being 1954 aware that the client request is occurring over that tunnel. It also 1955 does not preclude a client device from accessing a LIS serving the 1956 local physical network and subsequently using the location 1957 information with an application that is accessed over a VPN tunnel. 1959 A.7. L7-7: Network Access Authentication 1961 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1962 MUST NOT assume prior network access authentication." 1964 COMPLY 1966 HELD makes no assumptions about prior network access authentication. 1967 HELD strongly recommends the use of TLS with server-side certificates 1968 for communication between the end-point and the LIS. There is no 1969 requirement for the end-point to authenticate with the LIS. 1971 A.8. L7-8: Network Topology Unawareness 1973 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1974 MUST NOT assume end systems being aware of the access network 1975 topology. End systems are, however, able to determine their public 1976 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." 1978 COMPLY 1980 HELD makes no assumption about the network topology. HELD doesn't 1981 require that the device know its external IP address, except where 1982 that is required for discovery of the LIS. 1984 A.9. L7-9: Discovery Mechanism 1986 "The L7 LCP MUST define a single mandatory to implement discovery 1987 mechanism." 1989 COMPLY 1991 HELD uses the discovery mechanism in 1992 [I-D.ietf-geopriv-lis-discovery]. 1994 A.10. L7-10: PIDF-LO Creation 1996 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the 1997 element into the element of the presence document 1998 (see RFC 4479). This ensures that the resulting PIDF-LO document, 1999 which is subsequently distributed to other entities, conforms to the 2000 rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile] 2002 COMPLY 2003 HELD protocol overview (Section 4 ) describes the requirements on the 2004 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated 2005 by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile]. 2007 Authors' Addresses 2009 Mary Barnes (editor) 2010 Nortel 2011 2201 Lakeside Blvd 2012 Richardson, TX 2013 USA 2015 Email: mary.barnes@nortel.com 2017 James Winterbottom 2018 Andrew 2019 PO Box U40 2020 Wollongong University Campus, NSW 2500 2021 AU 2023 Phone: +61 2 4221 2938 2024 Email: james.winterbottom@andrew.com 2025 URI: http://www.andrew.com/ 2027 Martin Thomson 2028 Andrew 2029 PO Box U40 2030 Wollongong University Campus, NSW 2500 2031 AU 2033 Phone: +61 2 4221 2915 2034 Email: martin.thomson@andrew.com 2035 URI: http://www.andrew.com/ 2036 Barbara Stark 2037 BellSouth 2038 Room 7A43 2039 725 W Peachtree St. 2040 Atlanta, GA 30308 2041 US 2043 Email: barbara.stark@att.com