idnits 2.17.1
draft-ietf-geopriv-http-location-delivery-12.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?
-- It seems you're using the 'non-IETF stream' Licence Notice instead
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 (January 27, 2009) is 5561 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615,
RFC 7616, RFC 7617)
** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)
== Outdated reference: A later version (-15) exists of
draft-ietf-geopriv-lis-discovery-05
-- Obsolete informational reference (is this intentional?): RFC 793
(Obsoleted by RFC 9293)
-- Obsolete informational reference (is this intentional?): RFC 3023
(Obsoleted by RFC 7303)
-- Obsolete informational reference (is this intentional?): RFC 3825
(Obsoleted by RFC 6225)
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
== Outdated reference: A later version (-10) exists of
draft-ietf-geopriv-l7-lcp-ps-08
== Outdated reference: A later version (-09) exists of
draft-ietf-geopriv-lbyr-requirements-05
== Outdated reference: A later version (-13) exists of
draft-ietf-sip-location-conveyance-12
== Outdated reference: A later version (-05) exists of
draft-winterbottom-geopriv-deref-protocol-02
Summary: 6 errors (**), 0 flaws (~~), 6 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: July 31, 2009
7 January 27, 2009
9 HTTP Enabled Location Delivery (HELD)
10 draft-ietf-geopriv-http-location-delivery-12.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 July 31, 2009.
35 Copyright Notice
37 Copyright (c) 2009 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document.
47 Abstract
49 A Layer 7 Location Configuration Protocol (L7 LCP) is described that
50 is used for retrieving location information from a server within an
51 access network. The protocol includes options for retrieving
52 location information in two forms: by value and by reference. The
53 protocol is an extensible application-layer protocol that is
54 independent of session-layer. This document describes the use of
55 HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
56 Security (HTTP/TLS) as transports for the protocol.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
62 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5
63 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
64 4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
65 4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 7
66 4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
67 4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 8
68 4.3. Location by Reference . . . . . . . . . . . . . . . . . . 9
69 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
70 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 10
71 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10
72 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
73 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 11
74 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
75 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 12
76 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
77 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14
78 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14
79 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15
80 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15
81 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15
82 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16
83 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
84 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
85 8. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
87 9.1. Assuring that the proper LIS has been contacted . . . . . 23
88 9.2. Protecting responses from modification . . . . . . . . . . 23
89 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 23
90 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
91 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 25
92 10.2. Simple Location Request Example . . . . . . . . . . . . . 27
93 10.3. Location Request Example for Multiple Location Types . . . 28
95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
96 11.1. URN Sub-Namespace Registration for
97 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 29
98 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 30
99 11.3. MIME Media Type Registration for 'application/held+xml' . 30
100 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 31
101 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
102 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
103 14. Changes since last Version . . . . . . . . . . . . . . . . . . 33
104 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
105 15.1. Normative References . . . . . . . . . . . . . . . . . . . 39
106 15.2. Informative References . . . . . . . . . . . . . . . . . . 40
107 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 41
108 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 41
109 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 41
110 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 42
111 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 42
112 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 43
113 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 43
114 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 43
115 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 44
116 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 44
117 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 44
118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
120 1. Introduction
122 The location of a Device is information that is useful for a number
123 of applications. The L7 Location Configuration Protocol (LCP)
124 problem statement and requirements document
125 [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a
126 Device might rely on its access network to provide location
127 information. The Location Information Server (LIS) service applies
128 to access networks employing both wired technology (e.g. DSL, Cable)
129 and wireless technology (e.g. WiMAX) with varying degrees of Device
130 mobility. This document describes a protocol that can be used to
131 acquire Location Information (LI) from a LIS within an access
132 network.
134 This specification identifies two types of location information that
135 may be retrieved from the LIS. Location may be retrieved from the
136 LIS by value, that is, the Device may acquire a literal location
137 object describing the location of the Device. The Device may also
138 request that the LIS provide a location reference in the form of a
139 location URI or set of location URIs, allowing the Device to
140 distribute its LI by reference. Both of these methods can be
141 provided concurrently from the same LIS to accommodate application
142 requirements for different types of location information.
144 This specification defines an extensible XML-based protocol that
145 enables the retrieval of LI from a LIS by a Device. This protocol
146 can be bound to any session-layer protocol, particularly those
147 capable of MIME transport. This document describes the use of
148 HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
149 Security (HTTP/TLS) as transports for the protocol.
151 2. Conventions & Terminology
153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
155 document are to be interpreted as described in [RFC2119].
157 This document uses the terms (and their acronym forms) Access
158 Provider (AP), Location Information (LI), Location Object (LO),
159 Device, Target, Location Generator (LG), Location Recipient (LR),
160 Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV
161 Requirements [RFC3693] . The terms Location Information Server
162 (LIS), Access Network, Access Provider (AP) and Access Network
163 Provider are used in the same context as defined in the L7 LCP
164 Problem statement and Requirements document
165 [I-D.ietf-geopriv-l7-lcp-ps]. The usage of the terms, Civic
166 Location/Address and Geodetic Location follows the usage in many of
167 the referenced documents.
169 In describing the protocol, the terms "attribute" and "element" are
170 used according to their context in XML. The term "parameter" is used
171 in a more general protocol context and can refer to either an XML
172 "attribute" or "element".
174 3. Overview and Scope
176 This document describes an interface between a Device and a Location
177 Information Server (LIS). This document assumes that the LIS is
178 present within the same administrative domain as the Device (e.g.,
179 the access network). An Access Provider (AP) operates the LIS so
180 that Devices (and Targets) can retrieve their LI. The LIS exists
181 because not all Devices are capable of determining LI, and because,
182 even if a device is able to determine its own LI, it may be more
183 efficient with assistance. This document does not specify how LI is
184 determined.
186 This document is based on the attribution of the LI to a Device and
187 not specifically a person (end user) or Target, based on the premise
188 that location determination technologies are generally designed to
189 locate a device and not a person. It is expected that, for most
190 applications, LI for the device can be used as an adequate substitute
191 for the end user's LI. Since revealing the location of the device
192 almost invariably reveals some information about the location of the
193 user of the device, the same level of privacy protection demanded by
194 a user is required for the device. This approach may require either
195 some additional assurances about the link between device and target,
196 or an acceptance of the limitation that unless the device requires
197 active user authentication, there is no guarantee that any particular
198 individual is using the device at that instant.
200 The following diagram shows the logical configuration of some of the
201 functional elements identified in [RFC3693] and the LIS defined in
202 [I-D.ietf-geopriv-l7-lcp-ps] and where this protocol applies, with
203 the Rule Maker and Target represented by the role of the Device.
204 Note that only the interfaces relevant to the Device are identified
205 in the diagram.
207 +---------------------------------------------+
208 | Access Network Provider |
209 | |
210 | +--------------------------------------+ |
211 | | Location Information Server | |
212 | | | |
213 | | | |
214 | | | |
215 | | | |
216 | +------|-------------------------------+ |
217 +----------|----------------------------------+
218 |
219 |
220 HELD
221 |
222 Rule Maker - _ +-----------+ +-----------+
223 o - - | Device | | Location |
224
733
741
742
743 This document (RFC xxxx) defines HELD messages.
744
746
747
749
752
753
754
755
756
757
759
760
762
763
764
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
800
801
802
803
804
805
806
807
808
809
810
812
813
814
815
817
818
819
821
822
823
824
825
826
828
829
830
831
833
834
835
836
837
839
841
842
843
844
846
848
849
850
851
852
853
856
858
859
860
861
862
865
867
868
869
870
871
874
876
877
878
879
881
884
886 8. HTTP Binding
888 This section describes the use of HTTP [RFC2616] and HTTP Over TLS
889 [RFC2818] as transport mechanisms for the HELD protocol, which a
890 conforming LIS and Device MUST support.
892 Although HELD uses HTTP as a transport, it uses a strict subset of
893 HTTP features, and due to the restrictions of some features, a LIS is
894 not a fully compliant HTTP server. It is intended that a LIS can
895 easily be built using an HTTP server with extensibility mechanisms,
896 and that a HELD Device can trivially use existing HTTP libraries.
897 This subset of requirements helps implementors avoid ambiguity with
898 the many options the full HTTP protocol offers. The LIS MUST NOT
899 rely on device support for cookies [RFC2965] or use Basic or Digest
900 authentication [RFC2617].
902 A HELD request is carried in the body of an HTTP POST request. The
903 Device MUST include a Host header in the request.
905 The MIME type of HELD request and response bodies is
906 "application/held+xml". LIS and Device MUST provide this value in
907 the HTTP Content-Type and Accept header fields.If the LIS does not
908 receive the appropriate Content-Type and Accept header fields, the
909 LIS SHOULD fail the request, returning a 406 (not acceptable)
910 response. HELD responses SHOULD include a Content-Length header.
912 Devices MUST NOT use the "Expect" header or the "Range" header in
913 HELD requests. The LIS MAY return 501 (not implemented) errors if
914 either of these HTTP features are used. In the case that the LIS
915 receives a request from the Device containing a If-* (conditional)
916 header, the LIS SHOULD return a 412 (precondition failed) response.
918 The POST method is the only method REQUIRED for HELD. If a LIS
919 chooses to support GET or HEAD, it SHOULD consider the kind of
920 application doing the GET. Since a HELD Device only uses a POST
921 method, the GET or HEAD MUST be either an escaped URL (e.g., somebody
922 found a URL in protocol traces or log files and fed it into their
923 browser) or somebody doing testing/ debugging. The LIS could provide
924 information in the HELD response indicating that the URL corresponds
925 to a LIS server and only responds to HELD POST requests or the LIS
926 could instead try to avoid any leak of information by returning a
927 very generic HTTP error message such as 404 (not found).
929 The LIS populates the HTTP headers of responses so that they are
930 consistent with the contents of the message. In particular, the
931 "CacheControl" header SHOULD be set to disable caching of any PIDF-LO
932 document or Location URIs by HTTP intermediaries. Otherwise, there
933 is the risk of stale locations and/or the unauthorized disclosure of
934 the LI. This also allows the LIS to control any caching with the
935 HELD "expires" parameter. The HTTP status code MUST indicate a 2xx
936 series response for all HELD locationResponse and HELD error
937 messages.
939 The LIS MAY redirect a HELD request. A Device MUST handle redirects,
940 by using the Location header provided by the server in a 3xx
941 response. When redirecting, the Device MUST observe the delay
942 indicated by the Retry-After header. The Device MUST authenticate
943 the server that returns the redirect response before following the
944 redirect. A Device SHOULD authenticate the LIS indicated in a
945 redirect.
947 The LIS SHOULD support persistent connections and request pipelining.
948 If pipelining is not supported, the LIS MUST NOT allow persistent
949 connections. The Device MUST support termination of a response by
950 the closing of a connection.
952 The use of HTTP also includes a default behaviour, which is triggered
953 by a POST with no request body. If either of these queries are
954 received, the LIS MUST attempt to provide either a PIDF-LO document
955 or a Location URI, as if the request was a location request.
957 Implementations of HELD that implement HTTP transport MUST implement
958 transport over TLS [RFC2818]. TLS provides message integrity and
959 confidentiality between Device and LIS. The Device MUST implement
960 the server authentication method described in HTTPS [RFC2818]. The
961 device uses the URI obtained during LIS discovery to authenticate the
962 server. The details of this authentication method are provided in
963 section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device SHOULD
964 fail a request if server authentication fails, except in the event of
965 an emergency.
967 9. Security Considerations
969 HELD is a location acquisition protocol whereby the a client requests
970 its location from a LIS. Specific requirements and security
971 considerations for location acquisition protocols are provided in
972 [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security
973 considerations applicable to the use of Location URIs and by
974 reference provision of LI is included in
975 [I-D.ietf-geopriv-lbyr-requirements].
977 By using the HELD protocol, the client and the LIS expose themselves
978 to two types of risk:
980 Accuracy: Client receives incorrect location information
981 Privacy: An unauthorized entity receives location information
983 The provision of an accurate and privacy/confidentiality protected
984 location to the requestor depends on the success of five steps:
986 1. The client must determine the proper LIS.
987 2. The client must connect to the proper LIS.
988 3. The LIS must be able to identify the device by its identifier
989 (IP Address).
990 4. The LIS must be able to return the desired location.
991 5. HELD messages must be transmitted unmodified between the LIS
992 and the client.
994 Of these, only the second, third and the fifth are within the scope
995 of this document. The first step is based on either manual
996 configuration or on the LIS discovery defined in
997 [I-D.ietf-geopriv-lis-discovery], in which appropriate security
998 considerations are already discussed. The fourth step is dependent
999 on the specific positioning capabilities of the LIS, and is thus
1000 outside the scope of this document.
1002 9.1. Assuring that the proper LIS has been contacted
1004 This document assumes that the LIS to be contacted is identified
1005 either by an IP address or a domain name, as is the case for a LIS
1006 discovered as described in LIS Discovery
1007 [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is
1008 conducted using TLS [RFC5246], the LIS can authenticate its identity,
1009 either as a domain name or as an IP address, to the client by
1010 presenting a certificate containing that identifier as a
1011 subjectAltName (i.e., as an iPAddress or dNSName, respectively). In
1012 the case of the HTTP binding described above, this is exactly the
1013 authentication described by TLS [RFC2818]. If the client has
1014 external information as to the expected identity or credentials of
1015 the proper LIS (e.g., a certificate fingerprint), these checks MAY be
1016 omitted. Any binding of HELD MUST be capable of being transacted
1017 over TLS so that the client can request the above authentication, and
1018 a LIS implementation for a binding MUST include this feature. Note
1019 that in order for the presented certificate to be valid at the
1020 client, the client must be able to validate the certificate. In
1021 particular, the validation path of the certificate must end in one of
1022 the client's trust anchors, even if that trust anchor is the LIS
1023 certificate itself.
1025 9.2. Protecting responses from modification
1027 In order to prevent that response from being modified en route,
1028 messages must be transmitted over an integrity-protected channel.
1029 When the transaction is being conducted over TLS (a required feature
1030 per Section 9.1), the channel will be integrity protected by
1031 appropriate ciphersuites. When TLS is not used, this protection will
1032 vary depending on the binding; in most cases, without protection from
1033 TLS, the response will not be protected from modification en route.
1035 9.3. Privacy and Confidentiality
1037 Location information returned by the LIS must be protected from
1038 access by unauthorized parties, whether those parties request the
1039 location from the LIS or intercept it en route. As in Section 9.2,
1040 transactions conducted over TLS with appropriate ciphersuites are
1041 protected from access by unauthorized parties en route. Conversely,
1042 in most cases, when not conducted over TLS, the response will be
1043 accessible while en route from the LIS to the requestor.
1045 Because HELD is an LCP and identifies clients and targets by IP
1046 addresses, a requestor is authorized to access location for an IP
1047 address only if it is the holder of that IP address. The LIS MUST
1048 verify that the client is the target of the returned location, i.e.,
1049 the LIS MUST NOT provide location to other entities than the target.
1051 Note that this is a necessary, but not sufficient criterion for
1052 authorization. A LIS MAY deny requests according to any local
1053 policy.
1055 A prerequisite for meeting this requirement is that the LIS must have
1056 some assurance of the identity of the client. Since the target of
1057 the returned location is identified by an IP address, simply sending
1058 the response to this IP address will provide sufficient assurance in
1059 many cases. This is the default mechanism in HELD for assuring that
1060 location is given only to authorized clients; LIS implementations
1061 MUST support a mode of operation in which this is the only client
1062 authentication.
1064 Using IP return routability as an authenticator means that location
1065 information is vulnerable to exposure through IP address spoofing
1066 attacks. A temporary spoofing of IP address could mean that a device
1067 could request a Location Object or Location URI that would result in
1068 another Device's location. In addition, in cases where a Device
1069 drops off the network for various reasons, the re-use of the Device's
1070 IP address could result in another Device receiving the original
1071 Device's location rather than its own location. These exposures are
1072 limited by the following:
1074 o Location URIs MUST have a limited lifetime, as reflected by the
1075 value for the expires element in Section 6.5.2. The lifetime of
1076 location URIs necessarily depends on the nature of the access.
1077 o The LIS and network SHOULD be configured so that the LIS is made
1078 aware of Device movement within the network and addressing
1079 changes. If the LIS detects a change in the network that results
1080 in it no longer being able to determine the location of the
1081 Device, then all location URIs for that Device SHOULD be
1082 invalidated.
1084 The above measures are dependent on network configuration, which
1085 SHOULD be considered. For instance, in a fixed internet access,
1086 providers may be able to restrict the allocation of IP addresses to a
1087 single physical line, ensuring that spoofing is not possible; in such
1088 an environment, additional measures may not be necessary.
1090 10. Examples
1092 The following sections provide basic HTTP/HTTPS examples, a simple
1093 location request example and a location request for multiple location
1094 types example along with the relevant location responses. To focus
1095 on important portions of messages, the examples in Section 10.2 and
1096 Section 10.3 do not show HTTP/HTTPS headers or the XML prologue. In
1097 addition, sections of XML not relevant to the example are replaced
1098 with comments.
1100 10.1. HTTPS Example Messages
1102 The examples in this section show complete HTTP/HTTPS messages that
1103 include the HELD request or response document.
1105 This example shows the most basic request for a LO. The POST
1106 includes an empty "locationRequest" element.
1108 POST /location HTTP/1.1
1109 Host: lis.example.com:49152
1110 Content-Type: application/held+xml
1111 Content-Length: 87
1113
1114
1116 Since the above request does not include a "locationType" element,
1117 the successful response to the request may contain any type of
1118 location. The following shows a response containing a minimal
1119 PIDF-LO.
1121 HTTP/1.1 200 OK
1122 Server: Example LIS
1123 Date: Tue, 10 Jan 2006 03:42:29 GMT
1124 Expires: Tue, 10 Jan 2006 03:42:29 GMT
1125 Cache-control: private
1126 Content-Type: application/held+xml
1127 Content-Length: 594
1129
1130
1131
1133
1134
1135
1136
1137
1139 -34.407 150.88001
1140
1141
1142
1143
1144 2006-01-11T03:42:28+00:00
1145
1146 Wiremap
1147
1148
1149 2006-01-10T03:42:28+00:00
1150
1151
1152
1154 The error response to the request is an error document. The
1155 following response shows an example error response.
1157 HTTP/1.1 200 OK
1158 Server: Example LIS
1159 Expires: Tue, 10 Jan 2006 03:49:20 GMT
1160 Cache-control: private
1161 Content-Type: application/held+xml
1162 Content-Length: 135
1164
1165
1169 10.2. Simple Location Request Example
1171 The location request shown below doesn't specify any location types
1172 or response time.
1174
1176 The example response to this location request contains a list of
1177 Location URIs.
1179
1180
1181 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
1182
1183 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
1184
1185
1186
1188 An error response to this location request is shown below:
1190
1194 10.3. Location Request Example for Multiple Location Types
1196 The following Location Request message includes a request for
1197 geodetic, civic and any Location URIs.
1199
1200
1201 geodetic
1202 civic
1203 locationURI
1204
1205
1207 The corresponding Location Response message includes the requested
1208 location information, including two location URIs.
1210
1211
1212 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
1213
1214 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
1215
1216
1217
1219
1220
1221
1222
1223
1227 -34.407242 150.882518
1228 30
1229
1231
1232
1235 AU
1236 NSW
1237 Wollongong
1238 Gwynneville
1239 Northfield Avenue
1240 University of Wollongong
1241 2
1242 Andrew Corporation
1243 2500
1244 39
1245 WS-183
1246 U40
1247
1248
1249
1250 false
1251 2007-05-25T12:35:02+10:00
1252
1253
1254 Wiremap
1255
1256
1257 2007-05-24T12:35:02+10:00
1258
1259
1260
1262 11. IANA Considerations
1264 This document requires several IANA registrations detailed in the
1265 following sections.
1267 11.1. URN Sub-Namespace Registration for
1268 urn:ietf:params:xml:ns:geopriv:held
1270 This section registers a new XML namespace,
1271 "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in
1272 [RFC3688].
1274 URI: urn:ietf:params:xml:ns:geopriv:held
1275 Registrant Contact: IETF, GEOPRIV working group,
1276 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
1277 XML:
1279 BEGIN
1280
1281
1283
1284
1285 HELD Messages
1286
1287
1288 Namespace for HELD Messages
1289 urn:ietf:params:xml:ns:geopriv:held
1290 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1291 with the RFC number for this specification.]
1292
See RFCXXXX
1293
1294
1295 END
1297 11.2. XML Schema Registration
1299 This section registers an XML schema as per the guidelines in
1300 [RFC3688].
1302 URI: urn:ietf:params:xml:schema:geopriv:held
1303 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1304 Mary Barnes (mary.barnes@nortel.com).
1305 Schema: The XML for this schema can be found as the entirety of
1306 Section 7 of this document.
1308 11.3. MIME Media Type Registration for 'application/held+xml'
1310 This section registers the "application/held+xml" MIME type.
1312 To: ietf-types@iana.org
1313 Subject: Registration of MIME media type application/held+xml
1314 MIME media type name: application
1315 MIME subtype name: held+xml
1316 Required parameters: (none)
1317 Optional parameters: charset
1318 Indicates the character encoding of enclosed XML. Default is
1319 UTF-8.
1321 Encoding considerations: Uses XML, which can employ 8-bit
1322 characters, depending on the character encoding used. See RFC
1323 3023 [RFC3023], section 3.2.
1324 Security considerations: This content type is designed to carry
1325 protocol data related to the location of an entity, which could
1326 include information that is considered private. Appropriate
1327 precautions should be taken to limit disclosure of this
1328 information.
1329 Interoperability considerations: This content type provides a basis
1330 for a protocol
1331 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
1332 replace XXXX with the RFC number for this specification.]
1333 Applications which use this media type: Location information
1334 providers and consumers.
1335 Additional Information: Magic Number(s): (none)
1336 File extension(s): .xml
1337 Macintosh File Type Code(s): (none)
1338 Person & email address to contact for further information: Mary
1339 Barnes
1340 Intended usage: LIMITED USE
1341 Author/Change controller: The IETF
1342 Other information: This media type is a specialization of
1343 application/xml [RFC3023], and many of the considerations
1344 described there also apply to application/held+xml.
1346 11.4. Error code Registry
1348 This document requests that the IANA create a new registry for the
1349 HELD protocol including an initial registry for error codes. The
1350 error codes are included in HELD error messages as described in
1351 Section 6.3 and defined in the schema in the 'codeType' token in the
1352 XML schema in (Section 7)
1354 The following summarizes the requested registry:
1356 Related Registry: Geopriv HELD Registries, Error codes for HELD
1357 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1358 with the RFC number for this specification.]
1359 Registration/Assignment Procedures: Following the policies outlined
1360 in [RFC5226], the IANA policy for assigning new values for the
1361 Error codes for HELD shall be Specification Required: values and
1362 their meanings must be documented in an RFC or in some other
1363 permanent and readily available reference, in sufficient detail
1364 that interoperability between independent implementations is
1365 possible.
1367 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1368 Mary Barnes (mary.barnes@nortel.com).
1370 This section pre-registers the following seven initial error codes as
1371 described above in Section 6.3:
1373 requestError: This code indicates that the request was badly formed
1374 in some fashion.
1375 xmlError: This code indicates that the XML content of the request
1376 was either badly formed or invalid.
1377 generalLisError: This code indicates that an unspecified error
1378 occurred at the LIS.
1379 locationUnknown: This code indicates that the LIS could not
1380 determine the location of the Device.
1381 unsupportedMessage: This code indicates that the request was not
1382 supported or understood by the LIS. This error code is used when
1383 a HELD request contains a document element that is not supported
1384 by the receiver.
1385 timeout: This code indicates that the LIS could not satisfy the
1386 request within the time specified in the "responseTime" parameter.
1387 cannotProvideLiType: This code indicates that the LIS was unable to
1388 provide LI of the type or types requested. This code is used when
1389 the "exact" attribute on the "locationType" parameter is set to
1390 "true".
1391 notLocatable: This code indicates that the LIS is unable to locate
1392 the Device, and that the Device MUST NOT make further attempts to
1393 retrieve LI from this LIS. This error code is used to indicate
1394 that the Device is outside the access network served by the LIS;
1395 for instance, the VPN and NAT scenarios discussed in
1396 Section 4.1.2.
1398 12. Contributors
1400 James Winterbottom, Martin Thomson and Barbara Stark are the authors
1401 of the original document, from which this WG document was derived.
1402 Their contact information is included in the Author's address
1403 section. In addition, they also contributed to the WG document,
1404 including the XML schema.
1406 13. Acknowledgements
1408 The author/contributors would like to thank the participants in the
1409 GEOPRIV WG and the following people for their constructive input and
1410 feedback on this document (in alphabetical order): Nadine Abbott,
1411 Eric Arolick, Richard Barnes (in particular the security section),
1412 Peter Blatherwick, Ben Campbell, Guy Caron, Eddy Corbett, Martin
1413 Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings,
1414 Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger
1415 Marshall, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla,
1416 Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
1417 Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf.
1419 14. Changes since last Version
1421 NOTE TO THE RFC-Editor: Please remove this section prior to
1422 publication as an RFC.
1424 Changes from WG 11 to 12 (Post-2nd WGLC):
1426 1) Expanded text in section 8 (HTTP binding) to provide more detail
1427 about the requirements for an HTTP implementation supporting HELD.
1428 Clarified the mandatory functionality and specific handling of other
1429 functionality of HTTP.
1431 2) Clarification in section 9.1 for clients that have external info
1432 wrt the identity or credentials of the LIS.
1434 3) More nits.
1436 Changes from WG 10 to 11 (Post-2nd WGLC):
1438 1) Added additional text around the scope and applicability of the
1439 URI returned from LIS Discovery (section 4).
1441 2) Removed HTTP GET - will always use POST.
1443 3) Removed sentence wrt mobile devices in section 6.2.
1445 4) Added specific recommendation for minimum value for expires in
1446 section 6.5.2 (30 Minutes).
1448 5) Remove reference to RFC 3704 (for IP address spoofing) in section
1449 9.3 (bullet 2).
1451 6) Clarified that both HTTP and HTTPS are allowed - changed last
1452 bullet in section 5.1 from REQUIRES to RECOMMENDS.
1454 7) Clarification wrt "presence" parameter in section 6.6 - a "single"
1455 presence parameter may be included.
1457 Changes from WG 09 to 10 (2nd WGLC):
1459 1) Updated text for Devices and VPNs (section 4.1.1) to include
1460 servers such as HTTP and SOCKs, thus changed the text to be generic
1461 in terms of locating LIS before connecting to one of these servers,
1462 etc.
1464 2) Fixed (still buggy) HTTP examples.
1466 3) Added text explaining the whitespaces in XML schema are for
1467 readability/document format limitations and that they should be
1468 handled via parser/schema validation.
1470 4) Miscellaneous editorial nits
1472 Changes from WG 08 to 09 (Post-IETF LC: continued resolution of sec-
1473 dir and gen-art review comments, along with apps-area feedback):
1475 1) Removed heldref/heldrefs URIs, including fixing examples (which
1476 were buggy anyways).
1478 2) Clarified text for locationURI - specifying that the deref
1479 protocol must define or appropriately restrict and clarifying that
1480 requirements for deref must be met and that deref details are out of
1481 scope for this document.
1483 3) Clarified text in security section for support of both HTTP/HTTPS.
1485 4) Changed definition for Location Type to force the specification of
1486 at least one location type.
1488 Changes from WG 07 to 08 (IETF LC: sec-dir and gen-art review
1489 comments):
1491 1) Fix editorial nits: rearranging sections in 4.1 for readibility,
1492 etc.
1494 2) Added back text in Device and VPN section referencing DHCP and
1495 LLDP-MED when a VPN device serves as a LIS.
1497 3) Clarified the use of both HTTP and HTTPS.
1499 4) Defined two URIs related to 3 respectively - divided IANA
1500 registrations into sub-sections to accomodate this change. (Note:
1501 LIS Discovery will now define that URI, thus this document defines
1502 the one associatied with a Location reference).
1504 5) Clarified the description of the location URI in Protocol Overview
1505 and Protocol parameter sections. Note that these sections again
1506 reference location dereference protocol for completeness and
1507 clarification of issues that are out of scope for this base document.
1509 6) Defined new error code: notLocatable.
1511 7) Clarifications and corrections in security section.
1513 8) Clarified text for locationType, specifically removing extra text
1514 from "any" description and putting that in a separate paragraph.
1515 Also, provided an example.
1517 9) Added boundaries for "expires" parameter.
1519 10) Clarified that the HELD protocol as defined by this document does
1520 not allow for canceling location references.
1522 Changes from WG 06 to 07 (PROTO review comments):
1524 1) Fix nits: remove unused references, move requirements to
1525 Informational References section, fix long line in ABNF, fix ABNF
1526 (quotes around '?'), add schemaLocation to import namespace in XML
1527 schema.
1529 2) Remove text in Device and VPN section referencing DHCP and LLDP-
1530 MED when a VPN device serves as a LIS, per Issue 1 resolution at
1531 IETF-71. (Editorial oversight in producing version 06).
1533 Changes from WG 05 to 06 (2nd WGLC comments):
1535 1) Updated security section based on WG feedback, including
1536 condensing section 10.1.1 (Assuring the proper LIS has been
1537 contacted), restructuring sections by flattening, adding an
1538 additional step to the list that had been in the Accuracy section and
1539 removing summary section.
1541 2) Changed URI schema to "helds" to address concerns over referential
1542 integrity and for consistency with mandate of TLS for HELD.
1544 3) Editorial clarifications including fixing examples to match HELD
1545 URI definition (e.g., adding port, adding randomness to URI examples,
1546 etc.)
1548 4) Updated references removing unused references and moving
1549 requirements docs to Informational Reference section to avoid
1550 downrefs.
1552 Changes from WG 04 to 05 (WGLC comments):
1554 1) Totally replaced the security section with the details provided by
1555 Richard Barnes so that we don't need a reference to the location
1556 security document.
1558 2) Fixed error codes in schema to allow extensibility. Change the
1559 IANA registration to be "specification required".
1561 3) Cleaned up the HELD: URI description, per comments from Martin and
1562 James and partially addressing HELD-04 Issue 1. Put the definition
1563 in a separate section and clarified the applicability (to also
1564 include being a results of the discovery process) and fixed examples.
1566 4) Updated the LocationURI section to be more accurate, address
1567 HELD-04 Issue 3, and include the reference to the new HELD:URI
1568 section. Also, fixed an error in the doc in that the top level parm
1569 in the locationResponse is actually locationUriSet, which contains
1570 any number of locationURI elements and the "expires" parameter. So,
1571 Table 1 was also updated and a new section for the LocationURISet was
1572 added that includes the subsections for the "locationURI" and
1573 "expires". And, then clarified that "expires" applies to
1574 "locationURISet" and not per "locationURI".
1576 5) Editorial nits: pointed out offline by Richard (e.g., by-value ->
1577 by value, by-reference -> by reference, etc.) and onlist by James and
1578 Martin. Please refer to the diff for a complete view of editorial
1579 changes.
1581 6) Added text in HTTP binding section to disable HTTP caching
1582 (HELD-04 Issue 5 on the list).
1584 Changes from WG 03 to 04:
1586 1) Terminology: clarified in terminology section that "attribute" and
1587 "element" are used in the strict XML sense and "parameter" is used as
1588 a general protocol term Replaced term "HTTP delivery" with "HTTP
1589 transport". Still have two terms "HTTP transport" and "HTTP
1590 binding", but those are consistent with general uses of HTTP.
1592 2) Editorial changes and clarifications: per Roger Marshall's and
1593 Eric Arolick's comments and subsequent WG mailing list discussion.
1595 3) Changed normative language for describing expected and recommended
1596 LIS behaviors to be non-normative recommendations in cases where the
1597 protocol parameters were not the target of the discussion (e.g., we
1598 can't prescribe to the LIS how it determines location or what it
1599 defines to be an "accurate" location).
1601 4) Clarified responseTime attribute (section 6.1). Changed type from
1602 "decimal" to "nonNegativeInteger" in XML schema (section 7)
1604 5) Updated Table 1 in section 6 to only include top-level parameters
1605 and fixed some errors in that table (i.e., code for locationResponse)
1606 and adding PIDF-LO to the table. Added a detailed section describing
1607 PIDF-LO (section 6.6), moving some of the normative text in the
1608 Protocol Overview to this section.
1610 6) Added schema and description for locationURI to section 6.5.
1611 Added IANA registration for HELD: URI schema.
1613 7) Added IANA registry for error codes.
1615 Changes from WG 02 to 03:
1617 1) Added text to address concern over use of IP address as device
1618 identifier, per long email thread - changes to section 3 (overview)
1619 and section 4 (protocol overview).
1621 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed)
1623 3) Added extensibility to baseRequestType in the schema (an oversight
1624 from previous edits), along with fixing some other nits in schema
1625 (section 7)
1627 4) Moved discussion of Location URI from section 5.3 (Location
1628 Response) to where it rightly belonged in Section 6.5 (Location URI
1629 Parameter).
1631 5) Clarified text for "expires" parameter (6.5.1) - it's an optional
1632 parm, but required for LocationURIs
1634 6) Clarified responseTime parameter: when missing, then the LCS
1635 provides most precise LI, with the time required being implementation
1636 specific.
1638 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST
1639 implement.
1641 8) Updated references (removed unused/added new).
1643 Changes from WG 01 to 02:
1645 1) Updated Terminology to be consistent with WG agreements and other
1646 documents (e.g., LCS -> LIS and removed duplicate terms). In the
1647 end, there are no new terms defined in this document.
1649 2) Modified definition of responseTime to reflect WG consensus.
1651 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving
1652 just "civic").
1654 4) Clarified text that locationType is optional. Fixed table 1 and
1655 text in section 5.2 (locationRequest description). Text in section
1656 6.2 (description of locationType element) already defined the default
1657 to be "any".
1659 5) Simplified error responses. Separated the definition of error
1660 response type from the locationResponse type thus no need for
1661 defining an error code of "success". This simplifies the schema and
1662 processing.
1664 6) Updated schema/examples for the above.
1666 7) Updated Appendix A based on updates to requirements document,
1667 specifically changes to A.1, A.3 and adding A.10.
1669 8) Miscellaneous editorial clarifications.
1671 Changes from WG 00 to 01:
1673 1) heldResponse renamed to locationResponse.
1675 2) Changed namespace references for the PIDF-LO geoShape in the
1676 schema to match the agreed GML PIDF-LO Geometry Shape Application
1677 Schema.
1679 3) Removed "options" element - leaving optionality/extensibility to
1680 XML mechanisms.
1682 4) Changed error codes to be enumerations and not redefinitions of
1683 HTTP response codes.
1685 5) Updated schema/examples for the above and removed some remnants of
1686 the context element.
1688 6) Clarified the definition of "Location Information (LI)" to include
1689 a reference to the location (to match the XML schema and provide
1690 consistency of usage throughout the document). Added an additional
1691 statement in section 7.2 (locationType) to clarify that LCS MAY also
1692 return a Location URI.
1694 7) Modifed the definition of "Location Configuration Server (LCS)" to
1695 be consistent with the current definiton in the requirements
1696 document.
1698 8) Updated Location Response (section 6.3) to remove reference to
1699 context and discuss the used of a local identifier or unlinked
1700 pseudonym in providing privacy/security.
1702 9) Clarified that the source IP address in the request is used as the
1703 identifier for the target/device for the HELD protocol as defined in
1704 this document.
1706 10) Miscellaneous editorial clarifications.
1708 15. References
1710 15.1. Normative References
1712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1713 Requirement Levels", BCP 14, RFC 2119, March 1997.
1715 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1716 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1718 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
1719 Mechanism", RFC 2965, October 2000.
1721 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1722 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1723 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1725 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
1726 Leach, P., Luotonen, A., and L. Stewart, "HTTP
1727 Authentication: Basic and Digest Access Authentication",
1728 RFC 2617, June 1999.
1730 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1732 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1733 January 2004.
1735 [I-D.ietf-geopriv-pdif-lo-profile]
1736 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
1737 PIDF-LO Usage Clarification, Considerations and
1738 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
1739 (work in progress), November 2008.
1741 [W3C.REC-xmlschema-1-20041028]
1742 Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech,
1743 "XML Schema Part 1: Structures Second Edition", World Wide
1744 Web Consortium Recommendation REC-xmlschema-1-20041028,
1745 October 2004,
1746 .
1748 [W3C.REC-xmlschema-2-20041028]
1749 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
1750 Second Edition", World Wide Web Consortium
1751 Recommendation REC-xmlschema-2-20041028, October 2004,
1752 .
1754 [I-D.ietf-geopriv-lis-discovery]
1755 Thomson, M. and J. Winterbottom, "Discovering the Local
1756 Location Information Server (LIS)",
1757 draft-ietf-geopriv-lis-discovery-05 (work in progress),
1758 December 2008.
1760 15.2. Informative References
1762 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
1763 RFC 793, September 1981.
1765 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
1766 Types", RFC 3023, January 2001.
1768 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
1769 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
1771 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
1772 Configuration Protocol Option for Coordinate-based
1773 Location Configuration Information", RFC 3825, July 2004.
1775 [LLDP-MED]
1776 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
1777 Endpoint Discovery".
1779 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1780 Resource Identifier (URI): Generic Syntax", STD 66,
1781 RFC 3986, January 2005.
1783 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1784 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1785 May 2008.
1787 [I-D.ietf-geopriv-l7-lcp-ps]
1788 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
1789 Location Configuration Protocol; Problem Statement and
1790 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
1791 progress), June 2008.
1793 [I-D.ietf-geopriv-lbyr-requirements]
1794 Marshall, R., "Requirements for a Location-by-Reference
1795 Mechanism", draft-ietf-geopriv-lbyr-requirements-05 (work
1796 in progress), November 2008.
1798 [I-D.ietf-sip-location-conveyance]
1799 Polk, J. and B. Rosen, "Location Conveyance for the
1800 Session Initiation Protocol",
1801 draft-ietf-sip-location-conveyance-12 (work in progress),
1802 November 2008.
1804 [I-D.winterbottom-geopriv-deref-protocol]
1805 Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
1806 Thomson, M., and M. Dawson, "An HTTPS Location
1807 Dereferencing Protocol Using HELD",
1808 draft-winterbottom-geopriv-deref-protocol-02 (work in
1809 progress), July 2008.
1811 Appendix A. HELD Compliance to IETF LCP requirements
1813 This appendix describes HELD's compliance to the requirements
1814 specified in the [I-D.ietf-geopriv-l7-lcp-ps].
1816 A.1. L7-1: Identifier Choice
1818 "The L7 LCP MUST be able to carry different identifiers or MUST
1819 define an identifier that is mandatory to implement. Regarding the
1820 latter aspect, such an identifier is only appropriate if it is from
1821 the same realm as the one for which the location information service
1822 maintains identifier to location mapping."
1824 COMPLY
1826 HELD uses the IP address of the location request message as the
1827 primary source of identity for the requesting device or target. This
1828 identity can be used with other contextual network information to
1829 provide a physical location for the Target for many network
1830 deployments. There may be network deployments where an IP address
1831 alone is insufficient to identify a Target in a network. However,
1832 any necessary identity extensions for these networks is beyond the
1833 scope of this document.
1835 A.2. L7-2: Mobility Support
1837 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
1838 broad range of mobility from devices that can only move between
1839 reboots, to devices that can change attachment points with the impact
1840 that their IP address is changed, to devices that do not change their
1841 IP address while roaming, to devices that continuously move by being
1842 attached to the same network attachment point."
1844 COMPLY
1845 Mobility support is inherently a characteristic of the access network
1846 technology and HELD is designed to be access network agnostic.
1847 Consequently HELD complies with this requirement. In addition HELD
1848 provides specific support for mobile environments by providing an
1849 optional responseTime attribute in location request messages.
1850 Wireless networks often have several different mechanisms at their
1851 disposal for position determination (e.g. Assisted GPS versus
1852 location based on serving base station identity), each providing
1853 different degrees of accuracy and taking different amounts of time to
1854 yield a result. The responseTime parameter provides the LIS with a
1855 criterion which it can use to select a location determination
1856 technique.
1858 A.3. L7-3: ASP and Access Network Provider Relationship
1860 "The design of the L7 LCP MUST NOT assume a business or trust
1861 relationship between the Application Service Provider (ASP) and the
1862 Access Network Provider. Requirements for resolving a reference to
1863 location information are not discussed in this document."
1865 COMPLY
1867 HELD describes a location acquisition protocol between a Device and a
1868 LIS. In the context of HELD, the LIS is within the Access Network.
1869 Thus, HELD is independent of the business or trust relationship
1870 between the Application Service Provider (ASP) and the Access Network
1871 Provider. Location acquisition using HELD is subject to the
1872 restrictions described in Section 9.
1874 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
1876 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1877 MUST assume that there is a trust and business relationship between
1878 the L2 and the L3 provider. The L3 provider operates the LIS and
1879 needs to obtain location information from the L2 provider since this
1880 one is closest to the end host. If the L2 and L3 provider for the
1881 same host are different entities, they cooperate for the purposes
1882 needed to determine end system locations."
1884 COMPLY
1886 HELD was specifically designed with this model in mind and readily
1887 allows itself to chaining requests between operators without a change
1888 in protocol being required. HELD is a webservices protocol which can
1889 be bound to transports other than HTTP, such as BEEP. Using a
1890 protocol such as BEEP offers the option of high request throughput
1891 over a dedicated connection between an L3 provider and an L2 provider
1892 without incurring the serial restriction imposed by HTTP. This is
1893 less easy to do with protocols that do not decouple themselves from
1894 the transport.
1896 A.5. L7-5: Legacy Device Considerations
1898 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1899 MUST consider legacy residential NAT devices and NTEs in an DSL
1900 environment that cannot be upgraded to support additional protocols,
1901 for example to pass additional information through DHCP."
1903 COMPLY
1905 HELD is an application protocol and operates on top of IP. A HELD
1906 request from a host behind a residential NAT will traverse the NAT
1907 acquiring the external address of the home router. The location
1908 provided to the host therefore will be the address of the home router
1909 in this circumstance. No changes are required to the home router in
1910 order to support this function, HELD was designed specifically to
1911 address this deployment scenario.
1913 A.6. L7-6: VPN Awareness
1915 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1916 MUST assume that at least one end of a VPN is aware of the VPN
1917 functionality. In an enterprise scenario, the enterprise side will
1918 provide the LIS used by the client and can thereby detect whether the
1919 LIS request was initiated through a VPN tunnel."
1921 COMPLY
1923 HELD does not preclude a LIS on the far end of a VPN tunnel being
1924 aware that the client request is occurring over that tunnel. It also
1925 does not preclude a client device from accessing a LIS serving the
1926 local physical network and subsequently using the location
1927 information with an application that is accessed over a VPN tunnel.
1929 A.7. L7-7: Network Access Authentication
1931 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1932 MUST NOT assume prior network access authentication."
1934 COMPLY
1936 HELD makes no assumptions about prior network access authentication.
1937 HELD strongly recommends the use of TLS with server-side certificates
1938 for communication between the end-point and the LIS. There is no
1939 requirement for the end-point to authenticate with the LIS.
1941 A.8. L7-8: Network Topology Unawareness
1943 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1944 MUST NOT assume end systems being aware of the access network
1945 topology. End systems are, however, able to determine their public
1946 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
1948 COMPLY
1950 HELD makes no assumption about the network topology. HELD doesn't
1951 require that the device know its external IP address, except where
1952 that is required for discovery of the LIS.
1954 A.9. L7-9: Discovery Mechanism
1956 "The L7 LCP MUST define a single mandatory to implement discovery
1957 mechanism."
1959 COMPLY
1961 HELD uses the discovery mechanism in
1962 [I-D.ietf-geopriv-lis-discovery].
1964 A.10. L7-10: PIDF-LO Creation
1966 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
1967 element into the element of the presence document
1968 (see RFC 4479). This ensures that the resulting PIDF-LO document,
1969 which is subsequently distributed to other entities, conforms to the
1970 rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile]
1972 COMPLY
1974 HELD protocol overview (Section 4 ) describes the requirements on the
1975 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
1976 by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile].
1978 Authors' Addresses
1980 Mary Barnes (editor)
1981 Nortel
1982 2201 Lakeside Blvd
1983 Richardson, TX
1985 Email: mary.barnes@nortel.com
1986 James Winterbottom
1987 Andrew
1988 PO Box U40
1989 Wollongong University Campus, NSW 2500
1990 AU
1992 Phone: +61 2 4221 2938
1993 Email: james.winterbottom@andrew.com
1994 URI: http://www.andrew.com/
1996 Martin Thomson
1997 Andrew
1998 PO Box U40
1999 Wollongong University Campus, NSW 2500
2000 AU
2002 Phone: +61 2 4221 2915
2003 Email: martin.thomson@andrew.com
2004 URI: http://www.andrew.com/
2006 Barbara Stark
2007 BellSouth
2008 Room 7A43
2009 725 W Peachtree St.
2010 Atlanta, GA 30308
2011 US
2013 Email: barbara.stark@att.com