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

Namespace for HELD Messages

1207

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

1208 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 1209 with the RFC number for this specification.] 1210

See RFCXXXX

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