idnits 2.17.1 draft-ietf-geopriv-http-location-delivery-16.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 (Aug 28, 2009) is 5348 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 2818 (Obsoleted by RFC 9110) == Outdated reference: A later version (-15) exists of draft-ietf-geopriv-lis-discovery-11 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- 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: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-07 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-location-conveyance-01 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 1, 2010 7 Aug 28, 2009 9 HTTP Enabled Location Delivery (HELD) 10 draft-ietf-geopriv-http-location-delivery-16.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 March 1, 2010. 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. Location Request . . . . . . . . . . . . . . . . . . . . . 10 70 5.2. Location Response . . . . . . . . . . . . . . . . . . . . 10 71 5.3. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10 72 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 74 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 75 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13 76 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14 77 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14 78 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15 79 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15 80 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16 81 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16 82 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 85 9.1. Assuring that the proper LIS has been contacted . . . . . 23 86 9.2. Protecting responses from modification . . . . . . . . . . 24 87 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24 88 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 25 90 10.2. Simple Location Request Example . . . . . . . . . . . . . 27 91 10.3. Location Request Example for Multiple Location Types . . . 28 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 93 11.1. URN Sub-Namespace Registration for 94 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 29 95 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 30 96 11.3. MIME Media Type Registration for 'application/held+xml' . 30 97 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 31 98 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 100 14. Changes since last Version . . . . . . . . . . . . . . . . . . 33 101 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 102 15.1. Normative References . . . . . . . . . . . . . . . . . . . 41 103 15.2. Informative References . . . . . . . . . . . . . . . . . . 41 104 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 43 105 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 43 106 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 43 107 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 44 108 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 44 109 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 44 110 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 45 111 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 45 112 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 45 113 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 46 114 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 46 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 117 1. Introduction 119 The location of a Device is information that is useful for a number 120 of applications. The L7 Location Configuration Protocol (LCP) 121 problem statement and requirements document 122 [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a 123 Device might rely on its access network to provide location 124 information. The Location Information Server (LIS) service applies 125 to access networks employing both wired technology (e.g. DSL, Cable) 126 and wireless technology (e.g. WiMAX) with varying degrees of Device 127 mobility. This document describes a protocol that can be used to 128 acquire Location Information (LI) from a LIS within an access 129 network. 131 This specification identifies two types of location information that 132 may be retrieved from the LIS. Location may be retrieved from the 133 LIS by value, that is, the Device may acquire a literal location 134 object describing the location of the Device. The Device may also 135 request that the LIS provide a location reference in the form of a 136 location URI or set of location URIs, allowing the Device to 137 distribute its LI by reference. Both of these methods can be 138 provided concurrently from the same LIS to accommodate application 139 requirements for different types of location information. 141 This specification defines an extensible XML-based protocol that 142 enables the retrieval of LI from a LIS by a Device. This protocol 143 can be bound to any session-layer protocol, particularly those 144 capable of MIME transport. This document describes the use of 145 HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer 146 Security (HTTP/TLS) as transports for the protocol. 148 2. Conventions & Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 This document uses the terms (and their acronym forms) Access 155 Provider (AP), Location Information (LI), Location Object (LO), 156 Device, Target, Location Generator (LG), Location Recipient (LR), 157 Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV 158 Requirements [RFC3693] . The terms Location Information Server 159 (LIS), Access Network, Access Provider (AP) and Access Network 160 Provider are used in the same context as defined in the L7 LCP 161 Problem statement and Requirements document 162 [I-D.ietf-geopriv-l7-lcp-ps]. The usage of the terms, Civic 163 Location/Address and Geodetic Location follows the usage in many of 164 the referenced documents. 166 In describing the protocol, the terms "attribute" and "element" are 167 used according to their context in XML. The term "parameter" is used 168 in a more general protocol context and can refer to either an XML 169 "attribute" or "element". 171 3. Overview and Scope 173 This document describes an interface between a Device and a Location 174 Information Server (LIS). This document assumes that the LIS is 175 present within the same administrative domain as the Device (e.g., 176 the access network). The LIS exists because not all Devices are 177 capable of determining LI, and because, even if a device is able to 178 determine its own LI, it may be more efficient with assistance. This 179 document does not specify how LI is determined. An Access Provider 180 (AP) operates the LIS so that Devices (and Targets) can retrieve 181 their LI. This document assumes that the Device and Access Provider 182 have no prior relationship other than what is necessary for the 183 Device to obtain network access. 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 746 754 755 756 This document (RFC xxxx) defines HELD messages. 757 759 760 762 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 811 812 813 814 815 816 817 818 819 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 853 854 856 857 858 859 861 862 863 864 865 866 867 868 869 871 872 873 874 875 876 879 881 882 883 884 886 889 891 892 893 894 895 898 900 901 902 903 905 908 910 8. HTTP Binding 912 This section describes the use of HTTP [RFC2616] and HTTP Over TLS 913 [RFC2818] as transport mechanisms for the HELD protocol, which a 914 conforming LIS and Device MUST support. 916 Although HELD uses HTTP as a transport, it uses a strict subset of 917 HTTP features, and due to the restrictions of some features, a LIS is 918 not a fully compliant HTTP server. It is intended that a LIS can 919 easily be built using an HTTP server with extensibility mechanisms, 920 and that a HELD Device can trivially use existing HTTP libraries. 921 This subset of requirements helps implementors avoid ambiguity with 922 the many options the full HTTP protocol offers. 924 A Device that conforms to this specification MAY choose not to 925 support HTTP authentication [RFC2617] or cookies [RFC2965]. Because 926 the Device and the LIS may not necessarily have a prior relationship, 927 the LIS SHOULD NOT require a Device to authenticate, either using the 928 above HTTP authentication methods or TLS client authentication. 929 Unless all Devices that access a LIS can be expected to be able to 930 authenticate in a certain fashion, denying access to location 931 information could prevent a Device from using location-dependent 932 services, such as emergency calling. Extensions to this protocol 933 might result in the addition of request parameters that a LIS might 934 use to decide to request Device authentication. 936 A HELD request is carried in the body of an HTTP POST request. The 937 Device MUST include a Host header in the request. 939 The MIME type of HELD request and response bodies is 940 "application/held+xml". LIS and Device MUST provide this value in 941 the HTTP Content-Type and Accept header fields.If the LIS does not 942 receive the appropriate Content-Type and Accept header fields, the 943 LIS SHOULD fail the request, returning a 406 (not acceptable) 944 response. HELD responses SHOULD include a Content-Length header. 946 Devices MUST NOT use the "Expect" header or the "Range" header in 947 HELD requests. The LIS MAY return 501 (not implemented) errors if 948 either of these HTTP features are used. In the case that the LIS 949 receives a request from the Device containing a If-* (conditional) 950 header, the LIS SHOULD return a 412 (precondition failed) response. 952 The POST method is the only method REQUIRED for HELD. If a LIS 953 chooses to support GET or HEAD, it SHOULD consider the kind of 954 application doing the GET. Since a HELD Device only uses a POST 955 method, the GET or HEAD MUST be either an escaped URL (e.g., somebody 956 found a URL in protocol traces or log files and fed it into their 957 browser) or somebody doing testing/ debugging. The LIS could provide 958 information in the HELD response indicating that the URL corresponds 959 to a LIS server and only responds to HELD POST requests or the LIS 960 could instead try to avoid any leak of information by returning a 961 very generic HTTP error message such as 404 (not found). 963 The LIS populates the HTTP headers of responses so that they are 964 consistent with the contents of the message. In particular, the 965 "CacheControl" header SHOULD be set to disable caching of any PIDF-LO 966 document or Location URIs by HTTP intermediaries. Otherwise, there 967 is the risk of stale locations and/or the unauthorized disclosure of 968 the LI. This also allows the LIS to control any caching with the 969 HELD "expires" parameter. The HTTP status code MUST indicate a 2xx 970 series response for all HELD locationResponse and HELD error 971 messages. 973 The LIS MAY redirect a HELD request. A Device MUST handle redirects, 974 by using the Location header provided by the server in a 3xx 975 response. When redirecting, the Device MUST observe the delay 976 indicated by the Retry-After header. The Device MUST authenticate 977 the server that returns the redirect response before following the 978 redirect, if a Device requires that the server is authenticated. A 979 Device SHOULD authenticate the LIS indicated in a redirect. 981 The LIS SHOULD support persistent connections and request pipelining. 982 If pipelining is not supported, the LIS MUST NOT allow persistent 983 connections. The Device MUST support termination of a response by 984 the closing of a connection. 986 Implementations of HELD that implement HTTP transport MUST implement 987 transport over TLS [RFC2818]. TLS provides message integrity and 988 confidentiality between Device and LIS. The Device MUST implement 989 the server authentication method described in Section 3.1 of 990 [RFC2818], with an exception in how wildcards are handled. The 991 leftmost label MAY contain the wildcard string "*", which matches any 992 single domain name label. Additional characters in this leftmost 993 label are invalid (that is, "f*.example.com" is not a valid name and 994 does not match any domain name). 996 The device uses the URI obtained during LIS discovery to authenticate 997 the server. The details of this authentication method are provided 998 in section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device 999 SHOULD fail a request if server authentication fails, except in the 1000 event of an emergency. 1002 9. Security Considerations 1004 HELD is a location acquisition protocol whereby the a client requests 1005 its location from a LIS. Specific requirements and security 1006 considerations for location acquisition protocols are provided in 1007 [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security 1008 considerations applicable to the use of Location URIs and by 1009 reference provision of LI is included in 1011 [I-D.ietf-geopriv-lbyr-requirements]. 1013 By using the HELD protocol, the client and the LIS expose themselves 1014 to two types of risk: 1016 Accuracy: Client receives incorrect location information 1017 Privacy: An unauthorized entity receives location information 1019 The provision of an accurate and privacy/confidentiality protected 1020 location to the requestor depends on the success of five steps: 1022 1. The client must determine the proper LIS. 1023 2. The client must connect to the proper LIS. 1024 3. The LIS must be able to identify the device by its identifier 1025 (IP Address). 1026 4. The LIS must be able to return the desired location. 1027 5. HELD messages must be transmitted unmodified between the LIS 1028 and the client. 1030 Of these, only the second, third and the fifth are within the scope 1031 of this document. The first step is based on either manual 1032 configuration or on the LIS discovery defined in 1033 [I-D.ietf-geopriv-lis-discovery], in which appropriate security 1034 considerations are already discussed. The fourth step is dependent 1035 on the specific positioning capabilities of the LIS, and is thus 1036 outside the scope of this document. 1038 9.1. Assuring that the proper LIS has been contacted 1040 This document assumes that the LIS to be contacted is identified 1041 either by an IP address or a domain name, as is the case for a LIS 1042 discovered as described in LIS Discovery 1043 [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is 1044 conducted using TLS [RFC5246], the LIS can authenticate its identity, 1045 either as a domain name or as an IP address, to the client by 1046 presenting a certificate containing that identifier as a 1047 subjectAltName (i.e., as an iPAddress or dNSName, respectively). In 1048 the case of the HTTP binding described above, this is exactly the 1049 authentication described by TLS [RFC2818]. If the client has 1050 external information as to the expected identity or credentials of 1051 the proper LIS (e.g., a certificate fingerprint), these checks MAY be 1052 omitted. Any binding of HELD MUST be capable of being transacted 1053 over TLS so that the client can request the above authentication, and 1054 a LIS implementation for a binding MUST include this feature. Note 1055 that in order for the presented certificate to be valid at the 1056 client, the client must be able to validate the certificate. In 1057 particular, the validation path of the certificate must end in one of 1058 the client's trust anchors, even if that trust anchor is the LIS 1059 certificate itself. 1061 9.2. Protecting responses from modification 1063 In order to prevent that response from being modified en route, 1064 messages must be transmitted over an integrity-protected channel. 1065 When the transaction is being conducted over TLS (a required feature 1066 per Section 9.1), the channel will be integrity protected by 1067 appropriate ciphersuites. When TLS is not used, this protection will 1068 vary depending on the binding; in most cases, without protection from 1069 TLS, the response will not be protected from modification en route. 1071 9.3. Privacy and Confidentiality 1073 Location information returned by the LIS must be protected from 1074 access by unauthorized parties, whether those parties request the 1075 location from the LIS or intercept it en route. As in Section 9.2, 1076 transactions conducted over TLS with appropriate ciphersuites are 1077 protected from access by unauthorized parties en route. Conversely, 1078 in most cases, when not conducted over TLS, the response will be 1079 accessible while en route from the LIS to the requestor. 1081 Because HELD is an LCP and identifies clients and targets by IP 1082 addresses, a requestor is authorized to access location for an IP 1083 address only if it is the holder of that IP address. The LIS MUST 1084 verify that the client is the target of the returned location, i.e., 1085 the LIS MUST NOT provide location to other entities than the target. 1086 Note that this is a necessary, but not sufficient criterion for 1087 authorization. A LIS MAY deny requests according to any local 1088 policy. 1090 A prerequisite for meeting this requirement is that the LIS must have 1091 some assurance of the identity of the client. Since the target of 1092 the returned location is identified by an IP address, simply sending 1093 the response to this IP address will provide sufficient assurance in 1094 many cases. This is the default mechanism in HELD for assuring that 1095 location is given only to authorized clients; LIS implementations 1096 MUST support a mode of operation in which this is the only client 1097 authentication. 1099 Using IP return routability as an authenticator means that location 1100 information is vulnerable to exposure through IP address spoofing 1101 attacks. A temporary spoofing of IP address could mean that a device 1102 c ould request a Location Object or Location URI that would result in 1103 receiving another Device's location if the attacker is able to 1104 receive packets sent to the spoofed address. In addition, in cases 1105 where a Device drops off the network for various reasons, the re-use 1106 of the Device's IP address could result in another Device receiving 1107 the original Device's location rather than its own location. These 1108 exposures are limited by the following: 1110 o Location URIs MUST have a limited lifetime, as reflected by the 1111 value for the expires element in Section 6.5.2. The lifetime of 1112 location URIs necessarily depends on the nature of the access. 1113 o The LIS and network SHOULD be configured so that the LIS is made 1114 aware of Device movement within the network and addressing 1115 changes. If the LIS detects a change in the network that results 1116 in it no longer being able to determine the location of the 1117 Device, then all location URIs for that Device SHOULD be 1118 invalidated. 1120 The above measures are dependent on network configuration, which 1121 SHOULD be considered. For instance, in a fixed internet access, 1122 providers may be able to restrict the allocation of IP addresses to a 1123 single physical line, ensuring that spoofing is not possible; in such 1124 an environment, additional measures may not be necessary. 1126 10. Examples 1128 The following sections provide basic HTTP/HTTPS examples, a simple 1129 location request example and a location request for multiple location 1130 types example along with the relevant location responses. To focus 1131 on important portions of messages, the examples in Section 10.2 and 1132 Section 10.3 do not show HTTP/HTTPS headers or the XML prologue. In 1133 addition, sections of XML not relevant to the example are replaced 1134 with comments. 1136 10.1. HTTPS Example Messages 1138 The examples in this section show complete HTTP/HTTPS messages that 1139 include the HELD request or response document. 1141 This example shows the most basic request for a LO. The POST 1142 includes an empty "locationRequest" element. 1144 POST /location HTTP/1.1 1145 Host: lis.example.com:49152 1146 Content-Type: application/held+xml;charset=utf-8 1147 Content-Length: 87 1149 1150 1152 Since the above request does not include a "locationType" element, 1153 the successful response to the request may contain any type of 1154 location. The following shows a response containing a minimal 1155 PIDF-LO. 1157 HTTP/1.1 200 OK 1158 Server: Example LIS 1159 Date: Tue, 10 Jan 2006 03:42:29 GMT 1160 Expires: Tue, 10 Jan 2006 03:42:29 GMT 1161 Cache-control: private 1162 Content-Type: application/held+xml;charset=utf-8 1163 Content-Length: 856 1165 1166 1167 1169 1170 1171 1172 1173 1175 -34.407 150.88001 1176 1177 1178 1180 2006-01-11T03:42:28+00:00 1181 1182 1183 Wiremap 1184 1185 1186 2006-01-10T03:42:28+00:00 1187 1188 1189 1191 The error response to the request is an error document. The 1192 following response shows an example error response. 1194 HTTP/1.1 200 OK 1195 Server: Example LIS 1196 Expires: Tue, 10 Jan 2006 03:49:20 GMT 1197 Cache-control: private 1198 Content-Type: application/held+xml;charset=utf-8 1199 Content-Length: 182 1201 1202 1204 Unable to determine location 1205 1206 1208 10.2. Simple Location Request Example 1210 The location request shown below doesn't specify any location types 1211 or response time. 1213 1215 The example response to this location request contains a list of 1216 Location URIs. 1218 1219 1220 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1221 1222 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 1223 1224 1225 1226 An error response to this location request is shown below: 1228 1230 1232 1234 10.3. Location Request Example for Multiple Location Types 1236 The following Location Request message includes a request for 1237 geodetic, civic and any Location URIs. 1239 1240 1241 geodetic 1242 civic 1243 locationURI 1244 1245 1247 The corresponding Location Response message includes the requested 1248 location information, including two location URIs. 1250 1251 1252 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 1253 1254 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 1255 1256 1257 1259 1260 1261 1262 1263 1266 -34.407242 150.882518 1267 30 1268 1269 1270 1273 AU 1274 NSW 1275 Wollongong 1276 Gwynneville 1277 Northfield Avenue 1278 University of Wollongong 1279 2 1280 Andrew Corporation 1281 2500 1282 39 1283 WS-183 1284 U40 1285 1286 1287 1289 false 1290 1291 2007-05-25T12:35:02+10:00 1292 1293 1294 Wiremap 1295 1296 1297 2007-05-24T12:35:02+10:00 1298 1299 1300 1302 11. IANA Considerations 1304 This document requires several IANA registrations detailed in the 1305 following sections. 1307 11.1. URN Sub-Namespace Registration for 1308 urn:ietf:params:xml:ns:geopriv:held 1310 This section registers a new XML namespace, 1311 "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in 1313 [RFC3688]. 1315 URI: urn:ietf:params:xml:ns:geopriv:held 1316 Registrant Contact: IETF, GEOPRIV working group, 1317 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). 1318 XML: 1320 BEGIN 1321 1322 1324 1325 1326 HELD Messages 1327 1328 1329

Namespace for HELD Messages

1330

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

1331 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1332 with the RFC number for this specification.] 1333

See RFCXXXX

1334 1335 1336 END 1338 11.2. XML Schema Registration 1340 This section registers an XML schema as per the guidelines in 1341 [RFC3688]. 1343 URI: urn:ietf:params:xml:schema:geopriv:held 1344 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1345 Mary Barnes (mary.barnes@nortel.com). 1346 Schema: The XML for this schema can be found as the entirety of 1347 Section 7 of this document. 1349 11.3. MIME Media Type Registration for 'application/held+xml' 1351 This section registers the "application/held+xml" MIME type. 1353 To: ietf-types@iana.org 1354 Subject: Registration of MIME media type application/held+xml 1355 MIME media type name: application 1356 MIME subtype name: held+xml 1357 Required parameters: (none) 1358 Optional parameters: charset 1359 Same as the charset parameter of "application/xml" as specified in 1360 RFC 3023 [RFC3023], section 3.2. 1361 Encoding considerations: Same as the encoding considerations of 1362 "application/xml" as specified in RFC 3023 [RFC3023], section 3.2. 1363 Security considerations: This content type is designed to carry 1364 protocol data related to the location of an entity, which could 1365 include information that is considered private. Appropriate 1366 precautions should be taken to limit disclosure of this 1367 information. 1368 Interoperability considerations: This content type provides a basis 1369 for a protocol 1370 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please 1371 replace XXXX with the RFC number for this specification.] 1372 Applications which use this media type: Location information 1373 providers and consumers. 1374 Additional Information: Magic Number(s): (none) 1375 File extension(s): .xml 1376 Macintosh File Type Code(s): "TEXT" 1377 Person & email address to contact for further information: Mary 1378 Barnes 1379 Intended usage: LIMITED USE 1380 Author/Change controller: The IETF 1381 Other information: This media type is a specialization of 1382 application/xml [RFC3023], and many of the considerations 1383 described there also apply to application/held+xml. 1385 11.4. Error code Registry 1387 This document requests that the IANA create a new registry for the 1388 HELD protocol including an initial registry for error codes. The 1389 error codes are included in HELD error messages as described in 1390 Section 6.3 and defined in the schema in the 'codeType' token in the 1391 XML schema in (Section 7) 1393 The following summarizes the requested registry: 1395 Related Registry: Geopriv HELD Registries, Error codes for HELD 1396 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1397 with the RFC number for this specification.] 1398 Registration/Assignment Procedures: Following the policies outlined 1399 in [RFC5226], the IANA policy for assigning new values for the 1400 Error codes for HELD shall be Standards Action: Values are 1401 assigned only for Standards Track RFCs approved by the IESG. 1403 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 1404 Mary Barnes (mary.barnes@nortel.com). 1406 This section pre-registers the following seven initial error codes as 1407 described above in Section 6.3: 1409 requestError: This code indicates that the request was badly formed 1410 in some fashion. 1411 xmlError: This code indicates that the XML content of the request 1412 was either badly formed or invalid. 1413 generalLisError: This code indicates that an unspecified error 1414 occurred at the LIS. 1415 locationUnknown: This code indicates that the LIS could not 1416 determine the location of the Device. 1417 unsupportedMessage: This code indicates that the request was not 1418 supported or understood by the LIS. This error code is used when 1419 a HELD request contains a document element that is not supported 1420 by the receiver. 1421 timeout: This code indicates that the LIS could not satisfy the 1422 request within the time specified in the "responseTime" parameter. 1423 cannotProvideLiType: This code indicates that the LIS was unable to 1424 provide LI of the type or types requested. This code is used when 1425 the "exact" attribute on the "locationType" parameter is set to 1426 "true". 1427 notLocatable: This code indicates that the LIS is unable to locate 1428 the Device, and that the Device MUST NOT make further attempts to 1429 retrieve LI from this LIS. This error code is used to indicate 1430 that the Device is outside the access network served by the LIS; 1431 for instance, the VPN and NAT scenarios discussed in 1432 Section 4.1.2. 1434 12. Contributors 1436 James Winterbottom, Martin Thomson and Barbara Stark are the authors 1437 of the original document, from which this WG document was derived. 1438 Their contact information is included in the Author's address 1439 section. In addition, they also contributed to the WG document, 1440 including the XML schema. 1442 13. Acknowledgements 1444 The author/contributors would like to thank the participants in the 1445 GEOPRIV WG and the following people for their constructive input and 1446 feedback on this document (in alphabetical order): Nadine Abbott, 1447 Bernard Aboba, Eric Arolick, Richard Barnes (in particular the 1448 security section), Peter Blatherwick, Ben Campbell, Guy Caron, Eddy 1449 Corbett, Martin Dawson, Lisa Dusseault, Robins George, Jerome 1450 Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc 1451 Linsner, Patti McCalmont, Alexey Melnikov, Roger Marshall, Tim Polk, 1452 Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, Dan 1453 Romascanu, Brian Rosen, John Schnizlein, Shida Schubert, Henning 1454 Schulzrinne, Ed Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz 1455 Wolf. 1457 14. Changes since last Version 1459 NOTE TO THE RFC-Editor: Please remove this section prior to 1460 publication as an RFC. 1462 Changes from 15 to 16(IESG Review DISCUSSES/comments): 1464 1) Editorial Clarifications. 1466 2) Section 6.4 added explicit reference to draft-ietf-ltru-4646bis 1468 3) Section 6.5.3/examples (Expiry Time): clarified the details (UTC/ 1469 Gregorian calendar) for the expiry time and updated examples to 1470 include fractional seconds and trailing 'Z'. 1472 4) Section 8: Clarified the usage of wildcards in the domain name for 1473 server authentication. 1475 5) Section 10.1: Fixed examples - added charset attribute to Content 1476 Type and fixed lengths 1478 6) Section 11.3 (IANA mime registration), replaced text for Optional 1479 paramters and Encoding considerations with references to RFC 3023. 1480 Fixed Macintosh File Type Code. 1482 7) Updated location-conveyance reference to SIPCORE document. 1484 Changes from 14 to 15(Gen-Art and IETF discussion ML comments post 1485 3rd IETF LC): 1487 1) Clarification around device support for cookies or basic/digest 1488 authentication. 1490 2)Additional text in section 6.3 (PIDF-LO) around the LIS including 1491 (and not including) any information identifying the device in the 1492 returned PIDF-LO. 1494 3) As always, a few additional editorial changes and clarifications. 1496 Changes from 13 to 14 (AD comments post 2nd IETF LC): 1498 1) Section 4.3: Removed reference to location-dereference protocol 1499 document. Generalized statement wrt HELD not meeting all the lbyr 1500 requirements (e.g., cancelling of location references). 1502 2) Removed section 5.1 (Delivery Protocol) and just left the 1503 statement that this document describes the use of HTTP and that HELD 1504 is an application layer protocol. 1506 3) Section 6.1: "the LIS should provide the most accurate LI" -> "the 1507 LIS provides the most accurate LI" to avoid the inference of a 1508 normative requirement. 1510 4) Section 6.3: clarified "locationUnknown" error code. 1512 5) Section 6.4: changed text to indication that errors can contain 1513 multiple "message" parameters to accommodate errors in different 1514 languages. 1516 6) Section 7 : updated XML schema to reflect change in error message 1517 to accommodate multiple "message" parameters. Note, a few other 1518 changes to XML schema based on "strict" validation. 1520 7) Section 8: clarified that redirect should be authenticated if the 1521 Device requires that the redirect server is authenticated. 1523 8) Section 10: 1525 - updated examples due to updates to XML schema 1527 - removed empty POST example. 1529 9) Section 11.4: Changed IANA registration for error codes from 1530 "Specification Required" to "Standards Action" 1532 10) Other minor clarifications. 1534 Changes from WG 12 to 13 (Post-2nd WGLC): 1536 1) Fixed editorial error in section 6.2 with regards to empty 1537 "locationType" - error was introduced in 06 to 07 changes. 1539 2) Added additional text in section 6.5.1 to improve security 1540 associated with locationURIs. 1542 3) Modified XML schema for errorType and responseType to allow an 1543 attribute to be returned. Also, added extensibility to errorType. 1545 Changes from WG 11 to 12 (Post-2nd WGLC): 1547 1) Expanded text in section 8 (HTTP binding) to provide more detail 1548 about the requirements for an HTTP implementation supporting HELD. 1549 Clarified the mandatory functionality and specific handling of other 1550 functionality of HTTP. 1552 2) Clarification in section 9.1 for clients that have external info 1553 wrt the identity or credentials of the LIS. 1555 3) More nits. 1557 Changes from WG 10 to 11 (Post-2nd WGLC): 1559 1) Added additional text around the scope and applicability of the 1560 URI returned from LIS Discovery (section 4). 1562 2) Removed HTTP GET - will always use POST. 1564 3) Removed sentence wrt mobile devices in section 6.2. 1566 4) Added specific recommendation for minimum value for expires in 1567 section 6.5.2 (30 Minutes). 1569 5) Remove reference to RFC 3704 (for IP address spoofing) in section 1570 9.3 (bullet 2). 1572 6) Clarified that both HTTP and HTTPS are allowed - changed last 1573 bullet in section 5.1 from REQUIRES to RECOMMENDS. 1575 7) Clarification wrt "presence" parameter in section 6.6 - a "single" 1576 presence parameter may be included. 1578 Changes from WG 09 to 10 (2nd WGLC): 1580 1) Updated text for Devices and VPNs (section 4.1.1) to include 1581 servers such as HTTP and SOCKs, thus changed the text to be generic 1582 in terms of locating LIS before connecting to one of these servers, 1583 etc. 1585 2) Fixed (still buggy) HTTP examples. 1587 3) Added text explaining the whitespaces in XML schema are for 1588 readability/document format limitations and that they should be 1589 handled via parser/schema validation. 1591 4) Miscellaneous editorial nits 1592 Changes from WG 08 to 09 (Post-IETF LC: continued resolution of sec- 1593 dir and gen-art review comments, along with apps-area feedback): 1595 1) Removed heldref/heldrefs URIs, including fixing examples (which 1596 were buggy anyways). 1598 2) Clarified text for locationURI - specifying that the deref 1599 protocol must define or appropriately restrict and clarifying that 1600 requirements for deref must be met and that deref details are out of 1601 scope for this document. 1603 3) Clarified text in security section for support of both HTTP/HTTPS. 1605 4) Changed definition for Location Type to force the specification of 1606 at least one location type. 1608 Changes from WG 07 to 08 (IETF LC: sec-dir and gen-art review 1609 comments): 1611 1) Fix editorial nits: rearranging sections in 4.1 for readibility, 1612 etc. 1614 2) Added back text in Device and VPN section referencing DHCP and 1615 LLDP-MED when a VPN device serves as a LIS. 1617 3) Clarified the use of both HTTP and HTTPS. 1619 4) Defined two URIs related to 3 respectively - divided IANA 1620 registrations into sub-sections to accomodate this change. (Note: 1621 LIS Discovery will now define that URI, thus this document defines 1622 the one associatied with a Location reference). 1624 5) Clarified the description of the location URI in Protocol Overview 1625 and Protocol parameter sections. Note that these sections again 1626 reference location dereference protocol for completeness and 1627 clarification of issues that are out of scope for this base document. 1629 6) Defined new error code: notLocatable. 1631 7) Clarifications and corrections in security section. 1633 8) Clarified text for locationType, specifically removing extra text 1634 from "any" description and putting that in a separate paragraph. 1635 Also, provided an example. 1637 9) Added boundaries for "expires" parameter. 1639 10) Clarified that the HELD protocol as defined by this document does 1640 not allow for canceling location references. 1642 Changes from WG 06 to 07 (PROTO review comments): 1644 1) Fix nits: remove unused references, move requirements to 1645 Informational References section, fix long line in ABNF, fix ABNF 1646 (quotes around '?'), add schemaLocation to import namespace in XML 1647 schema. 1649 2) Remove text in Device and VPN section referencing DHCP and LLDP- 1650 MED when a VPN device serves as a LIS, per Issue 1 resolution at 1651 IETF-71. (Editorial oversight in producing version 06). 1653 Changes from WG 05 to 06 (2nd WGLC comments): 1655 1) Updated security section based on WG feedback, including 1656 condensing section 10.1.1 (Assuring the proper LIS has been 1657 contacted), restructuring sections by flattening, adding an 1658 additional step to the list that had been in the Accuracy section and 1659 removing summary section. 1661 2) Changed URI schema to "helds" to address concerns over referential 1662 integrity and for consistency with mandate of TLS for HELD. 1664 3) Editorial clarifications including fixing examples to match HELD 1665 URI definition (e.g., adding port, adding randomness to URI examples, 1666 etc.) 1668 4) Updated references removing unused references and moving 1669 requirements docs to Informational Reference section to avoid 1670 downrefs. 1672 Changes from WG 04 to 05 (WGLC comments): 1674 1) Totally replaced the security section with the details provided by 1675 Richard Barnes so that we don't need a reference to the location 1676 security document. 1678 2) Fixed error codes in schema to allow extensibility. Change the 1679 IANA registration to be "specification required". 1681 3) Cleaned up the HELD: URI description, per comments from Martin and 1682 James and partially addressing HELD-04 Issue 1. Put the definition 1683 in a separate section and clarified the applicability (to also 1684 include being a results of the discovery process) and fixed examples. 1686 4) Updated the LocationURI section to be more accurate, address 1687 HELD-04 Issue 3, and include the reference to the new HELD:URI 1688 section. Also, fixed an error in the doc in that the top level parm 1689 in the locationResponse is actually locationUriSet, which contains 1690 any number of locationURI elements and the "expires" parameter. So, 1691 Table 1 was also updated and a new section for the LocationURISet was 1692 added that includes the subsections for the "locationURI" and 1693 "expires". And, then clarified that "expires" applies to 1694 "locationURISet" and not per "locationURI". 1696 5) Editorial nits: pointed out offline by Richard (e.g., by-value -> 1697 by value, by-reference -> by reference, etc.) and onlist by James and 1698 Martin. Please refer to the diff for a complete view of editorial 1699 changes. 1701 6) Added text in HTTP binding section to disable HTTP caching 1702 (HELD-04 Issue 5 on the list). 1704 Changes from WG 03 to 04: 1706 1) Terminology: clarified in terminology section that "attribute" and 1707 "element" are used in the strict XML sense and "parameter" is used as 1708 a general protocol term Replaced term "HTTP delivery" with "HTTP 1709 transport". Still have two terms "HTTP transport" and "HTTP 1710 binding", but those are consistent with general uses of HTTP. 1712 2) Editorial changes and clarifications: per Roger Marshall's and 1713 Eric Arolick's comments and subsequent WG mailing list discussion. 1715 3) Changed normative language for describing expected and recommended 1716 LIS behaviors to be non-normative recommendations in cases where the 1717 protocol parameters were not the target of the discussion (e.g., we 1718 can't prescribe to the LIS how it determines location or what it 1719 defines to be an "accurate" location). 1721 4) Clarified responseTime attribute (section 6.1). Changed type from 1722 "decimal" to "nonNegativeInteger" in XML schema (section 7) 1724 5) Updated Table 1 in section 6 to only include top-level parameters 1725 and fixed some errors in that table (i.e., code for locationResponse) 1726 and adding PIDF-LO to the table. Added a detailed section describing 1727 PIDF-LO (section 6.6), moving some of the normative text in the 1728 Protocol Overview to this section. 1730 6) Added schema and description for locationURI to section 6.5. 1731 Added IANA registration for HELD: URI schema. 1733 7) Added IANA registry for error codes. 1735 Changes from WG 02 to 03: 1737 1) Added text to address concern over use of IP address as device 1738 identifier, per long email thread - changes to section 3 (overview) 1739 and section 4 (protocol overview). 1741 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed) 1743 3) Added extensibility to baseRequestType in the schema (an oversight 1744 from previous edits), along with fixing some other nits in schema 1745 (section 7) 1747 4) Moved discussion of Location URI from section 5.3 (Location 1748 Response) to where it rightly belonged in Section 6.5 (Location URI 1749 Parameter). 1751 5) Clarified text for "expires" parameter (6.5.1) - it's an optional 1752 parm, but required for LocationURIs 1754 6) Clarified responseTime parameter: when missing, then the LCS 1755 provides most precise LI, with the time required being implementation 1756 specific. 1758 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST 1759 implement. 1761 8) Updated references (removed unused/added new). 1763 Changes from WG 01 to 02: 1765 1) Updated Terminology to be consistent with WG agreements and other 1766 documents (e.g., LCS -> LIS and removed duplicate terms). In the 1767 end, there are no new terms defined in this document. 1769 2) Modified definition of responseTime to reflect WG consensus. 1771 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving 1772 just "civic"). 1774 4) Clarified text that locationType is optional. Fixed table 1 and 1775 text in section 5.2 (locationRequest description). Text in section 1776 6.2 (description of locationType element) already defined the default 1777 to be "any". 1779 5) Simplified error responses. Separated the definition of error 1780 response type from the locationResponse type thus no need for 1781 defining an error code of "success". This simplifies the schema and 1782 processing. 1784 6) Updated schema/examples for the above. 1786 7) Updated Appendix A based on updates to requirements document, 1787 specifically changes to A.1, A.3 and adding A.10. 1789 8) Miscellaneous editorial clarifications. 1791 Changes from WG 00 to 01: 1793 1) heldResponse renamed to locationResponse. 1795 2) Changed namespace references for the PIDF-LO geoShape in the 1796 schema to match the agreed GML PIDF-LO Geometry Shape Application 1797 Schema. 1799 3) Removed "options" element - leaving optionality/extensibility to 1800 XML mechanisms. 1802 4) Changed error codes to be enumerations and not redefinitions of 1803 HTTP response codes. 1805 5) Updated schema/examples for the above and removed some remnants of 1806 the context element. 1808 6) Clarified the definition of "Location Information (LI)" to include 1809 a reference to the location (to match the XML schema and provide 1810 consistency of usage throughout the document). Added an additional 1811 statement in section 7.2 (locationType) to clarify that LCS MAY also 1812 return a Location URI. 1814 7) Modifed the definition of "Location Configuration Server (LCS)" to 1815 be consistent with the current definiton in the requirements 1816 document. 1818 8) Updated Location Response (section 6.3) to remove reference to 1819 context and discuss the used of a local identifier or unlinked 1820 pseudonym in providing privacy/security. 1822 9) Clarified that the source IP address in the request is used as the 1823 identifier for the target/device for the HELD protocol as defined in 1824 this document. 1826 10) Miscellaneous editorial clarifications. 1828 15. References 1829 15.1. Normative References 1831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1832 Requirement Levels", BCP 14, RFC 2119, March 1997. 1834 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1835 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1837 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 1838 Mechanism", RFC 2965, October 2000. 1840 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1841 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1842 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1844 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1846 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1847 January 2004. 1849 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1850 Presence Information Data Format Location Object (PIDF-LO) 1851 Usage Clarification, Considerations, and Recommendations", 1852 RFC 5491, March 2009. 1854 [W3C.REC-xmlschema-1-20041028] 1855 Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech, 1856 "XML Schema Part 1: Structures Second Edition", World Wide 1857 Web Consortium Recommendation REC-xmlschema-1-20041028, 1858 October 2004, 1859 . 1861 [W3C.REC-xmlschema-2-20041028] 1862 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1863 Second Edition", World Wide Web Consortium 1864 Recommendation REC-xmlschema-2-20041028, October 2004, 1865 . 1867 [I-D.ietf-geopriv-lis-discovery] 1868 Thomson, M. and J. Winterbottom, "Discovering the Local 1869 Location Information Server (LIS)", 1870 draft-ietf-geopriv-lis-discovery-11 (work in progress), 1871 May 2009. 1873 15.2. Informative References 1875 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1876 RFC 793, September 1981. 1878 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1879 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1880 Authentication: Basic and Digest Access Authentication", 1881 RFC 2617, June 1999. 1883 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1884 Types", RFC 3023, January 2001. 1886 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1887 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1889 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1890 Configuration Protocol Option for Coordinate-based 1891 Location Configuration Information", RFC 3825, July 2004. 1893 [LLDP-MED] 1894 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 1895 Endpoint Discovery". 1897 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1898 Resource Identifier (URI): Generic Syntax", STD 66, 1899 RFC 3986, January 2005. 1901 [I-D.ietf-ltru-4646bis] 1902 Phillips, A. and M. Davis, "Tags for Identifying 1903 Languages", draft-ietf-ltru-4646bis-23 (work in progress), 1904 June 2009. 1906 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 1907 July 2006. 1909 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1910 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1911 May 2008. 1913 [I-D.ietf-geopriv-l7-lcp-ps] 1914 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 1915 Location Configuration Protocol; Problem Statement and 1916 Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in 1917 progress), July 2009. 1919 [I-D.ietf-geopriv-lbyr-requirements] 1920 Marshall, R., "Requirements for a Location-by-Reference 1921 Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work 1922 in progress), February 2009. 1924 [I-D.ietf-sipcore-location-conveyance] 1925 Polk, J. and B. Rosen, "Location Conveyance for the 1926 Session Initiation Protocol", 1927 draft-ietf-sipcore-location-conveyance-01 (work in 1928 progress), July 2009. 1930 Appendix A. HELD Compliance to IETF LCP requirements 1932 This appendix describes HELD's compliance to the requirements 1933 specified in the [I-D.ietf-geopriv-l7-lcp-ps]. 1935 A.1. L7-1: Identifier Choice 1937 "The L7 LCP MUST be able to carry different identifiers or MUST 1938 define an identifier that is mandatory to implement. Regarding the 1939 latter aspect, such an identifier is only appropriate if it is from 1940 the same realm as the one for which the location information service 1941 maintains identifier to location mapping." 1943 COMPLY 1945 HELD uses the IP address of the location request message as the 1946 primary source of identity for the requesting device or target. This 1947 identity can be used with other contextual network information to 1948 provide a physical location for the Target for many network 1949 deployments. There may be network deployments where an IP address 1950 alone is insufficient to identify a Target in a network. However, 1951 any necessary identity extensions for these networks is beyond the 1952 scope of this document. 1954 A.2. L7-2: Mobility Support 1956 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 1957 broad range of mobility from devices that can only move between 1958 reboots, to devices that can change attachment points with the impact 1959 that their IP address is changed, to devices that do not change their 1960 IP address while roaming, to devices that continuously move by being 1961 attached to the same network attachment point." 1963 COMPLY 1965 Mobility support is inherently a characteristic of the access network 1966 technology and HELD is designed to be access network agnostic. 1967 Consequently HELD complies with this requirement. In addition HELD 1968 provides specific support for mobile environments by providing an 1969 optional responseTime attribute in location request messages. 1970 Wireless networks often have several different mechanisms at their 1971 disposal for position determination (e.g. Assisted GPS versus 1972 location based on serving base station identity), each providing 1973 different degrees of accuracy and taking different amounts of time to 1974 yield a result. The responseTime parameter provides the LIS with a 1975 criterion which it can use to select a location determination 1976 technique. 1978 A.3. L7-3: ASP and Access Network Provider Relationship 1980 "The design of the L7 LCP MUST NOT assume a business or trust 1981 relationship between the Application Service Provider (ASP) and the 1982 Access Network Provider. Requirements for resolving a reference to 1983 location information are not discussed in this document." 1985 COMPLY 1987 HELD describes a location acquisition protocol between a Device and a 1988 LIS. In the context of HELD, the LIS is within the Access Network. 1989 Thus, HELD is independent of the business or trust relationship 1990 between the Application Service Provider (ASP) and the Access Network 1991 Provider. Location acquisition using HELD is subject to the 1992 restrictions described in Section 9. 1994 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship 1996 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 1997 MUST assume that there is a trust and business relationship between 1998 the L2 and the L3 provider. The L3 provider operates the LIS and 1999 needs to obtain location information from the L2 provider since this 2000 one is closest to the end host. If the L2 and L3 provider for the 2001 same host are different entities, they cooperate for the purposes 2002 needed to determine end system locations." 2004 COMPLY 2006 HELD was specifically designed with this model in mind and readily 2007 allows itself to chaining requests between operators without a change 2008 in protocol being required. HELD is a webservices protocol which can 2009 be bound to transports other than HTTP, such as BEEP. Using a 2010 protocol such as BEEP offers the option of high request throughput 2011 over a dedicated connection between an L3 provider and an L2 provider 2012 without incurring the serial restriction imposed by HTTP. This is 2013 less easy to do with protocols that do not decouple themselves from 2014 the transport. 2016 A.5. L7-5: Legacy Device Considerations 2018 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 2019 MUST consider legacy residential NAT devices and NTEs in an DSL 2020 environment that cannot be upgraded to support additional protocols, 2021 for example to pass additional information through DHCP." 2023 COMPLY 2025 HELD is an application protocol and operates on top of IP. A HELD 2026 request from a host behind a residential NAT will traverse the NAT 2027 acquiring the external address of the home router. The location 2028 provided to the host therefore will be the address of the home router 2029 in this circumstance. No changes are required to the home router in 2030 order to support this function, HELD was designed specifically to 2031 address this deployment scenario. 2033 A.6. L7-6: VPN Awareness 2035 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 2036 MUST assume that at least one end of a VPN is aware of the VPN 2037 functionality. In an enterprise scenario, the enterprise side will 2038 provide the LIS used by the client and can thereby detect whether the 2039 LIS request was initiated through a VPN tunnel." 2041 COMPLY 2043 HELD does not preclude a LIS on the far end of a VPN tunnel being 2044 aware that the client request is occurring over that tunnel. It also 2045 does not preclude a client device from accessing a LIS serving the 2046 local physical network and subsequently using the location 2047 information with an application that is accessed over a VPN tunnel. 2049 A.7. L7-7: Network Access Authentication 2051 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 2052 MUST NOT assume prior network access authentication." 2054 COMPLY 2056 HELD makes no assumptions about prior network access authentication. 2057 HELD strongly recommends the use of TLS with server-side certificates 2058 for communication between the end-point and the LIS. There is no 2059 requirement for the end-point to authenticate with the LIS. 2061 A.8. L7-8: Network Topology Unawareness 2063 "The design of the GEOPRIV Layer 7 Location Configuration Protocol 2064 MUST NOT assume end systems being aware of the access network 2065 topology. End systems are, however, able to determine their public 2066 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." 2068 COMPLY 2069 HELD makes no assumption about the network topology. HELD doesn't 2070 require that the device know its external IP address, except where 2071 that is required for discovery of the LIS. 2073 A.9. L7-9: Discovery Mechanism 2075 "The L7 LCP MUST define a single mandatory to implement discovery 2076 mechanism." 2078 COMPLY 2080 HELD uses the discovery mechanism in 2081 [I-D.ietf-geopriv-lis-discovery]. 2083 A.10. L7-10: PIDF-LO Creation 2085 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the 2086 element into the element of the presence document 2087 (see RFC 4479). This ensures that the resulting PIDF-LO document, 2088 which is subsequently distributed to other entities, conforms to the 2089 rules outlined in ". [RFC5491] 2091 COMPLY 2093 HELD protocol overview (Section 4 ) describes the requirements on the 2094 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated 2095 by the LIS MUST conform to [RFC5491]. 2097 Authors' Addresses 2099 Mary Barnes (editor) 2100 Nortel 2101 2201 Lakeside Blvd 2102 Richardson, TX 2103 USA 2105 Email: mary.barnes@nortel.com 2106 James Winterbottom 2107 Andrew 2108 PO Box U40 2109 Wollongong University Campus, NSW 2500 2110 AU 2112 Phone: +61 2 4221 2938 2113 Email: james.winterbottom@andrew.com 2114 URI: http://www.andrew.com/ 2116 Martin Thomson 2117 Andrew 2118 PO Box U40 2119 Wollongong University Campus, NSW 2500 2120 AU 2122 Phone: +61 2 4221 2915 2123 Email: martin.thomson@andrew.com 2124 URI: http://www.andrew.com/ 2126 Barbara Stark 2127 BellSouth 2128 Room 7A43 2129 725 W Peachtree St. 2130 Atlanta, GA 30308 2131 US 2133 Email: barbara.stark@att.com