idnits 2.17.1
draft-ietf-geopriv-http-location-delivery-08.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 2085.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2096.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2103.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2109.
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 (July 10, 2008) is 5740 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-01
-- Obsolete informational reference (is this intentional?): RFC 793
(Obsoleted by RFC 9293)
-- Obsolete informational reference (is this intentional?): RFC 3023
(Obsoleted by RFC 7303)
-- Obsolete informational reference (is this intentional?): RFC 3825
(Obsoleted by RFC 6225)
-- Obsolete informational reference (is this intentional?): RFC 4395
(Obsoleted by RFC 7595)
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
== Outdated reference: A later version (-10) exists of
draft-ietf-geopriv-l7-lcp-ps-08
== Outdated reference: A later version (-09) exists of
draft-ietf-geopriv-lbyr-requirements-03
== Outdated reference: A later version (-13) exists of
draft-ietf-sip-location-conveyance-10
== Outdated reference: A later version (-05) exists of
draft-winterbottom-geopriv-deref-protocol-01
Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV WG M. Barnes, Ed.
3 Internet-Draft Nortel
4 Intended status: Standards Track
5 Expires: January 11, 2009
7 July 10, 2008
9 HTTP Enabled Location Delivery (HELD)
10 draft-ietf-geopriv-http-location-delivery-08.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 January 11, 2009.
37 Abstract
39 A Layer 7 Location Configuration Protocol (L7 LCP) is described that
40 is used for retrieving location information from a server within an
41 access network. The protocol includes options for retrieving
42 location information in two forms: by value and by reference. The
43 protocol is an extensible application-layer protocol that is
44 independent of session-layer. This document describes the use of
45 HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
46 Security (HTTP/TLS) as transports for the protocol.
48 Table of Contents
50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
51 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
52 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5
53 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
54 4.1. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
55 4.1.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 7
56 4.1.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
57 4.2. Location by Value . . . . . . . . . . . . . . . . . . . . 8
58 4.3. Location by Reference . . . . . . . . . . . . . . . . . . 8
59 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
60 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 10
61 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10
62 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
63 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
64 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
65 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
66 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
67 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14
68 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14
69 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15
70 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15
71 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15
72 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16
73 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
74 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
75 8. HELD URI Definitions . . . . . . . . . . . . . . . . . . . . . 20
76 8.1. heldref: URI Definition . . . . . . . . . . . . . . . . . 20
77 8.2. heldrefs: URI Definition . . . . . . . . . . . . . . . . . 21
78 9. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 22
79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
80 10.1. Assuring that the proper LIS has been contacted . . . . . 24
81 10.2. Protecting responses from modification . . . . . . . . . . 24
82 10.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24
83 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
84 11.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 26
85 11.2. Simple Location Request Example . . . . . . . . . . . . . 28
86 11.3. Location Request Example for Multiple Location Types . . . 29
87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
88 12.1. URN Sub-Namespace Registration for
89 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 30
90 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 31
91 12.3. MIME Media Type Registration for 'application/held+xml' . 31
92 12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 32
93 12.5. URI Registrations . . . . . . . . . . . . . . . . . . . . 33
94 12.5.1. heldref: URI Registration . . . . . . . . . . . . . . 33
95 12.5.2. heldrefs: URI Registration . . . . . . . . . . . . . . 34
97 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
98 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
99 15. Changes since last Version . . . . . . . . . . . . . . . . . . 35
100 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
101 16.1. Normative References . . . . . . . . . . . . . . . . . . . 40
102 16.2. Informative References . . . . . . . . . . . . . . . . . . 41
103 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 42
104 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 42
105 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 43
106 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 43
107 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 44
108 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 44
109 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 44
110 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 45
111 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 45
112 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 45
113 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 45
114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
115 Intellectual Property and Copyright Statements . . . . . . . . . . 48
117 1. Introduction
119 The location of a Device is information that is useful for a number
120 of applications. The L7 Location Configuration Protocol (LCP)
121 problem statement and requirements document
122 [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a
123 Device might rely on its access network to provide location
124 information. The Location Information Server (LIS) service applies
125 to access networks employing both wired technology (e.g. DSL, Cable)
126 and wireless technology (e.g. WiMAX) with varying degrees of Device
127 mobility. This document describes a protocol that can be used to
128 acquire Location Information (LI) from a LIS within an access
129 network.
131 This specification identifies two types of location information that
132 may be retrieved from the LIS. Location may be retrieved from the
133 LIS by value, that is, the Device may acquire a literal location
134 object describing the location of the Device. The Device may also
135 request that the LIS provide a location reference in the form of a
136 location URI or set of location URIs, allowing the Device to
137 distribute its LI by reference. Both of these methods can be
138 provided concurrently from the same LIS to accommodate application
139 requirements for different types of location information.
141 This specification defines an extensible XML-based protocol that
142 enables the retrieval of LI from a LIS by a Device. This protocol
143 can be bound to any session-layer protocol, particularly those
144 capable of MIME transport. This document describes the use of
145 HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
146 Security (HTTP/TLS) as transports for the protocol.
148 2. Conventions & Terminology
150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
152 document are to be interpreted as described in [RFC2119].
154 This document uses the terms (and their acronym forms) Access
155 Provider (AP), Location Information (LI), Location Object (LO),
156 Device, Target, Location Generator (LG), Location Recipient (LR),
157 Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV
158 Requirements [RFC3693] . The terms Location Information Server
159 (LIS), Access Network, Access Provider (AP) and Access Network
160 Provider are used in the same context as defined in the L7 LCP
161 Problem statement and Requirements document
162 [I-D.ietf-geopriv-l7-lcp-ps]. The usage of the terms, Civic
163 Location/Address and Geodetic Location follows the usage in many of
164 the referenced documents.
166 In describing the protocol, the terms "attribute" and "element" are
167 used according to their context in XML. The term "parameter" is used
168 in a more general protocol context and can refer to either an XML
169 "attribute" or "element".
171 3. Overview and Scope
173 This document describes an interface between a Device and a Location
174 Information Server (LIS). This document assumes that the LIS is
175 present within the same administrative domain as the Device (e.g.,
176 the access network). An Access Provider (AP) operates the LIS so
177 that Devices (and Targets) can retrieve their LI. The LIS exists
178 because not all Devices are capable of determining LI, and because,
179 even if a device is able to determine its own LI, it may be more
180 efficient with assistance. This document does not specify how LI is
181 determined.
183 This document is based on the attribution of the LI to a Device and
184 not specifically a person (end user) or Target, based on the premise
185 that location determination technologies are generally designed to
186 locate a device and not a person. It is expected that, for most
187 applications, LI for the device can be used as an adequate substitute
188 for the end user's LI. Since revealing the location of the device
189 almost invariably reveals some information about the location of the
190 user of the device, the same level of privacy protection demanded by
191 a user is required for the device. This approach may require either
192 some additional assurances about the link between device and target,
193 or an acceptance of the limitation that unless the device requires
194 active user authentication, there is no guarantee that any particular
195 individual is using the device at that instant.
197 The following diagram shows the logical configuration of some of the
198 functional elements identified in [RFC3693] and the LIS defined in
199 [I-D.ietf-geopriv-l7-lcp-ps] and where this protocol applies, with
200 the Rule Maker and Target represented by the role of the Device.
201 Note that only the interfaces relevant to the Device are identified
202 in the diagram.
204 +---------------------------------------------+
205 | Access Network Provider |
206 | |
207 | +--------------------------------------+ |
208 | | Location Information Server | |
209 | | | |
210 | | | |
211 | | | |
212 | | | |
213 | +------|-------------------------------+ |
214 +----------|----------------------------------+
215 |
216 |
217 HELD
218 |
219 Rule Maker - _ +-----------+ +-----------+
220 o - - | Device | | Location |
221
721
729
730
731 This document (RFC xxxx) defines HELD messages.
732
734
735
737
740
741
742
743
744
745
747
748
750
751
752
754
755
756
757
758
759
760
761
762
763
764
765
766
767
769
770
772
773
774
775
776
777
778
779
780
782
783
784
785
786
787
788
789
790
791
792
793
795
796
797
798
800
801
802
804
805
806
807
808
809
811
812
813
814
815
816
817
818
819
821
823
824
825
826
828
830
831
832
833
834
835
838
840
841
842
843
845
848
850
851
852
853
854
857
859
860
861
863
865
868
870 8. HELD URI Definitions
872 This section defines the schemas for heldref: and heldrefs: URIs.
873 The heldrefs: URI is used in the case where TLS provides secure
874 transport for HELD messages transported by HTTPS as defined in
875 Section 9. These URI schemas are just two possible URI schemas for
876 the "locationURI" element, described in Section 6.5.1, in a HELD
877 "locationResponse " message. The "locationURI" indicates to the
878 Device where to obtain the actual location information for a Target.
880 There are other uses of the heldref:/heldrefs: URIs, such as the use
881 for dereferencing as described in
882 [I-D.winterbottom-geopriv-deref-protocol]. Thus, the usages of the
883 heldref:/heldrefs: URIs described in this document are not intended
884 to limit the applicability of the heldref:/heldrefs: URIs to other
885 relevant interfaces, but are necessarily restricted in scope in this
886 document to the use for the base HELD protocol.
888 8.1. heldref: URI Definition
890 The heldref: URI is defined using a subset of the URI schema
891 specified in Appendix A. of RFC3986 [RFC3986] and the associated URI
892 Guidelines [RFC4395] per the following ABNF syntax:
894 HELDREF-URI="helds://" host[ ":" port ][ path-absolute ][ "?" query ]
896 The following summarizes the primary elements comprising the HELDREF-
897 URI:
899 host: As defined in RFC3986 [RFC3986]
900 port: As defined in RFC3986 [RFC3986]. There is no unique port
901 associated with location URIs.
903 path-absolute As defined in RFC3986 [RFC3986].
904 query: As defined in RFC3986 [RFC3986]. This allows for additional
905 information associated with the URIs such as a unique anonymous
906 identifier for the Device associated with the target location.
908 The heldref: URI is not intended to be human-readable text, therefore
909 it is encoded entirely in US-ASCII. The following are examples of
910 heldrefs: URIs:
912 heldref://ls.example.com:49152/thisLocation?token=xyz987
913 heldref://ls.example.com:5432/THISLOCATION?foobar=abc123
914 heldref://ls.example.com:5432/THISlocation?foobar=ABC123
915 heldref://ls.example.com:9876/civic
917 Other than the "host" portion, URIs are case sensitive and exact
918 equivalency is required for HELDREF-URI comparisons. For example, in
919 the above examples, although similar in information, the 2nd and 3rd
920 URIs are not considered equivalent.
922 It is important to note that the heldref:URI, contained in a
923 "locationURI" element in a HELD locationResponse message, is only
924 valid for the length of time indicated by the "expires" attribute.
926 8.2. heldrefs: URI Definition
928 The heldrefs: URI is defined using a subset of the URI schema
929 specified in Appendix A. of RFC3986 [RFC3986] and the associated URI
930 Guidelines [RFC4395] per the following ABNF syntax:
932 HELDREFS-URI="heldrefs://"host[ ":" port ][ path-absolute ][ "?" query ]
934 The following summarizes the primary elements comprising the
935 HELDREFS-URI:
937 host: As defined in RFC3986 [RFC3986]
938 port: As defined in RFC3986 [RFC3986]. There is no unique port
939 associated with location URIs.
941 path-absolute As defined in RFC3986 [RFC3986].
942 query: As defined in RFC3986 [RFC3986]. This allows for additional
943 information associated with the URIs such as a unique anonymous
944 identifier for the Device associated with the target location.
946 The heldrefs: URI is not intended to be human-readable text,
947 therefore it is encoded entirely in US-ASCII. The following are
948 examples of heldrefs: URIs:
950 heldrefs://ls.example.com:49152/thisLocation?token=xyz987
951 heldrefs://ls.example.com:5432/THISLOCATION?foobar=abc123
952 heldrefs://ls.example.com:5432/THISlocation?foobar=ABC123
953 heldrefs://ls.example.com:9876/civic
955 Other than the "host" portion, URIs are case sensitive and exact
956 equivalency is required for HELDREFS-URI comparisons. For example,
957 in the above examples, although similar in information, the 2nd and
958 3rd URIs are not considered equivalent.
960 It is important to note that the heldrefs: URI, contained in a
961 "locationURI" element in a HELD locationResponse message, is only
962 valid for the length of time indicated by the "expires" attribute.
964 9. HTTP/HTTPS Binding
966 This section describes the use of HTTP [RFC2616] and HTTPS [RFC2818]
967 as transport mechanisms for the HELD protocol, which all conforming
968 implementations MUST support.
970 The request is carried in the body of an HTTP/HTTPS POST request.
971 The MIME type of both request and response bodies should be
972 "application/held+xml". This should be reflected in the HTTP
973 Content-Type and Accept header fields.
975 The LIS populates the HTTP/HTTPS headers so that they are consistent
976 with the contents of the message. In particular, the cache control
977 header SHOULD be set to disable the HTTP/HTTPS caching of any PIDF-LO
978 document or Location URIs. Otherwise, there is the risk of stale
979 locations and/or the unauthorized disclosure of the LI. This also
980 allows the LIS to control any caching with the "expires" parameter.
981 The HTTP/HTTPS status code MUST indicate a 2xx series response for
982 all HELD locationResponse and error messages.
984 The use of HTTP/HTTPS also includes a default behaviour, which is
985 triggered by a GET request, or a POST with no request body. If
986 either of these queries are received, the LIS MUST attempt to provide
987 either a PIDF-LO document or a Location URI, as if the request was a
988 location request.
990 The implementation of HTTPS as a transport mechanism MUST implement
991 TLS as described in [RFC2818]. TLS provides message integrity and
992 confidentiality between Device and LIS. The LIS MUST implement the
993 server authentication method described in [RFC2818]. The device uses
994 the URI obtained during LIS discovery to authenticate the server.
995 When TLS is used, the Device SHOULD fail a request if server
996 authentication fails, except in the event of an emergency.
998 10. Security Considerations
1000 HELD is a location acquisition protocol whereby the a client requests
1001 its location from a LIS. Specific requirements and security
1002 considerations for location acquisition protocols are provided in
1003 [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security
1004 considerations applicable to the use of Location URIs and by
1005 reference provision of LI is included in
1006 [I-D.ietf-geopriv-lbyr-requirements].
1008 By using the HELD protocol, the client and the LIS expose themselves
1009 to two types of risk:
1011 Accuracy: Client receives incorrect location information
1012 Privacy: An unauthorized entity receives location information
1014 The provision of an accurate and privacy/confidentiality protected
1015 location to the requestor depends on the success of five steps:
1017 1. The client must determine the proper LIS.
1018 2. The client must connect to the proper LIS.
1019 3. The LIS must be able to identify the device by its identifier
1020 (IP Address).
1021 4. The LIS must be able to return the desired location.
1022 5. HELD messages must be transmitted unmodified between the LIS
1023 and the client.
1025 Of these, only the second, third and the fifth are within the scope
1026 of this document. The first step is based on either manual
1027 configuration or on the LIS discovery defined in
1028 [I-D.ietf-geopriv-lis-discovery], in which appropriate security
1029 considerations are already discussed. The fourth step is dependent
1030 on the specific positioning capabilities of the LIS, and is thus
1031 outside the scope of this document.
1033 10.1. Assuring that the proper LIS has been contacted
1035 This document assumes that the LIS to be contacted is identified
1036 either by an IP address or a domain name, as is the case for a LIS
1037 discovered as described in LIS Discovery
1038 [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is
1039 conducted using TLS [RFC4346], the LIS can authenticate its identity,
1040 either as a domain name or as an IP address, to the client by
1041 presenting a certificate containing that identifier as a
1042 subjectAltName (i.e., as an iPAddress or dNSName, respectively). In
1043 the case of the HTTP binding described above, this is exactly the
1044 authentication described by TLS [RFC2818]. Any binding of HELD MUST
1045 be capable of being transacted over TLS so that the client can
1046 request the above authentication, and a LIS implementation for a
1047 binding MUST include this feature. Note that in order for the
1048 presented certificate to be valid at the client, the client must be
1049 able to validate the certificate. In particular, the validation path
1050 of the certificate must end in one of the client's trust anchors,
1051 even if that trust anchor is the LIS certificate itself.
1053 10.2. Protecting responses from modification
1055 In order to prevent that response from being modified en route,
1056 messages must be transmitted over an integrity-protected channel.
1057 When the transaction is being conducted over TLS (a required feature
1058 per Section 10.1), the channel will be integrity protected by
1059 appropriate ciphersuites. When TLS is not used, this protection will
1060 vary depending on the binding; in most cases, without protection from
1061 TLS, the response will not be protected from modification en route.
1063 10.3. Privacy and Confidentiality
1065 Location information returned by the LIS must be protected from
1066 access by unauthorized parties, whether those parties request the
1067 location from the LIS or intercept it en route. As in section
1068 Section 10.2, transactions conducted over TLS with appropriate
1069 ciphersuites are protected from access by unauthorized parties en
1070 route. Conversely, in most cases, when not conducted over TLS, the
1071 response will be accessible while en route from the LIS to the
1072 requestor.
1074 Because HELD is an LCP and identifies clients and targets by IP
1075 addresses, a requestor is authorized to access location for an IP
1076 address only if it is the holder of that IP address. The LIS MUST
1077 verify that the client is the target of the returned location, i.e.,
1078 the LIS MUST NOT provide location to other entities than the target.
1080 Note that this is a necessary, but not sufficient criterion for
1081 authorization. A LIS MAY deny requests according to any local
1082 policy.
1084 A prerequisite for meeting this requirement is that the LIS must have
1085 some assurance of the identity of the client. Since the target of
1086 the returned location is identified by an IP address, simply sending
1087 the response to this IP address will provide sufficient assurance in
1088 many cases. This is the default mechanism in HELD for assuring that
1089 location is given only to authorized clients; LIS implementations
1090 MUST support a mode of operation in which this is the only client
1091 authentication.
1093 Using IP return routability as an authenticator means that location
1094 information is vulnerable to exposure through IP address spoofing
1095 attacks. A temporary spoofing of IP address could mean that a device
1096 could request a Location Object or Location URI that would result in
1097 another Device's location. In addition, in cases where a Device
1098 drops off the network for various reasons, the re-use of the Device's
1099 IP address could result in another Device receiving the original
1100 Device's location rather than its own location. These exposures are
1101 limited by the following:
1103 o Location URIs MUST have a limited lifetime, as reflected by the
1104 value for the expires element in Section Section 6.5.2. The
1105 lifetime of location URIs necessarily depends on the nature of the
1106 access.
1107 o The network SHOULD have mechanisms that protect against IP address
1108 spoofing, such as those defined in [RFC3704].
1109 o The LIS and network SHOULD be configured so that the LIS is made
1110 aware of Device movement within the network and addressing
1111 changes. If the LIS detects a change in the network that results
1112 in it no longer being able to determine the location of the
1113 Device, then all location URIs for that Device SHOULD be
1114 invalidated.
1116 The above measures are dependent on network configuration, which
1117 SHOULD be considered. For instance, in a fixed internet access,
1118 providers may be able to restrict the allocation of IP addresses to a
1119 single physical line, ensuring that spoofing is not possible; in such
1120 an environment, additional measures may not be necessary.
1122 11. Examples
1124 The following sections provide basic HTTP/HTTPS examples, a simple
1125 location request example and a location request for multiple location
1126 types example along with the relevant location responses. To focus
1127 on important portions of messages, the examples in Section 11.2 and
1128 Section 11.3 do not show HTTP/HTTPS headers or the XML prologue. In
1129 addition, sections of XML not relevant to the example are replaced
1130 with comments.
1132 11.1. HTTPS Example Messages
1134 The examples in this section show a complete HTTPS message that
1135 includes the HELD request or response document.
1137 This example shows the most basic request for a LO. This uses the
1138 GET feature described by the HTTP binding. This example assumes that
1139 the LIS service exists at the URL "https://lis.example.com/location".
1141 GET heldrefs://lis.example.com:49152/location HTTP/1.1
1142 Accept:application/held+xml,
1143 application/xml;q=0.8,
1144 text/xml;q=0.7
1145 Accept-Charset: UTF-8,*
1147 The GET request is exactly identical to a minimal POST request that
1148 includes an empty "locationRequest" element.
1150 POST heldrefs://lis.example.com:49152/location HTTP/1.1
1151 Accept: application/held+xml,
1152 application/xml;q=0.8,
1153 text/xml;q=0.7
1154 Accept-Charset: UTF-8,*
1155 Content-Type: application/held+xml
1156 Content-Length: 87
1158
1159
1161 Since neither of these requests includes a "locationType" element,
1162 the successful response to either of these requests may contain any
1163 type of location. The following shows a response containing a
1164 minimal PIDF-LO.
1166 HTTP/1.x 200 OK
1167 Server: Example LIS
1168 Date: Tue, 10 Jan 2006 03:42:29 GMT
1169 Expires: Tue, 10 Jan 2006 03:42:29 GMT
1170 Cache-control: private
1171 Content-Type: application/held+xml
1172 Content-Length: 594
1174
1175
1176
1178
1179
1180
1181
1182
1184 -34.407 150.88001
1185
1186
1187
1188
1189 2006-01-11T03:42:28+00:00
1190
1191 Wiremap
1192
1193
1194 2006-01-10T03:42:28+00:00
1195
1196
1197
1199 The error response to either of these requests is an error document.
1200 The following response shows an example error response.
1202 HTTP/1.x 200 OK
1203 Server: Example LIS
1204 Expires: Tue, 10 Jan 2006 03:49:20 GMT
1205 Cache-control: private
1206 Content-Type: application/held+xml
1207 Content-Length: 135
1209
1210
1214 11.2. Simple Location Request Example
1216 The location request shown below doesn't specify any location types
1217 or response time.
1219
1221 The example response to this location request contains a list of
1222 Location URIs.
1224
1225
1226 heldrefs://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
1227
1228 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
1229
1230
1231
1232 An error response to this location request is shown below:
1234
1238 11.3. Location Request Example for Multiple Location Types
1240 The following Location Request message includes a request for
1241 geodetic, civic and any Location URIs.
1243
1244
1245 geodetic
1246 civic
1247 locationURI
1248
1249
1251 The corresponding Location Response message includes the requested
1252 location information, including two location URIs.
1254
1255
1256 helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
1257
1258 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
1259
1260
1261
1263
1264
1265
1266
1267
1271 -34.407242 150.882518
1272 30
1273
1275
1276
1279 AU
1280 NSW
1281 Wollongong
1282 Gwynneville
1283 Northfield Avenue
1284 University of Wollongong
1285 2
1286 Andrew Corporation
1287 2500
1288 39
1289 WS-183
1290 U40
1291
1292
1293
1294 false
1295 2007-05-25T12:35:02+10:00
1296
1297
1298 Wiremap
1299
1300
1301 2007-05-24T12:35:02+10:00
1302
1303
1304
1306 12. IANA Considerations
1308 This document requires several IANA registrations detailed in the
1309 following sections.
1311 12.1. URN Sub-Namespace Registration for
1312 urn:ietf:params:xml:ns:geopriv:held
1314 This section registers a new XML namespace,
1315 "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in
1316 [RFC3688].
1318 URI: urn:ietf:params:xml:ns:geopriv:held
1319 Registrant Contact: IETF, GEOPRIV working group,
1320 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
1321 XML:
1323 BEGIN
1324
1325
1327
1328
1329 HELD Messages
1330
1331
1332 Namespace for HELD Messages
1333 urn:ietf:params:xml:ns:geopriv:held
1334 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1335 with the RFC number for this specification.]
1336
See RFCXXXX
1337
1338
1339 END
1341 12.2. XML Schema Registration
1343 This section registers an XML schema as per the guidelines in
1344 [RFC3688].
1346 URI: urn:ietf:params:xml:schema:geopriv:held
1347 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1348 Mary Barnes (mary.barnes@nortel.com).
1349 Schema: The XML for this schema can be found as the entirety of
1350 Section 7 of this document.
1352 12.3. MIME Media Type Registration for 'application/held+xml'
1354 This section registers the "application/held+xml" MIME type.
1356 To: ietf-types@iana.org
1357 Subject: Registration of MIME media type application/held+xml
1358 MIME media type name: application
1359 MIME subtype name: held+xml
1360 Required parameters: (none)
1361 Optional parameters: charset
1362 Indicates the character encoding of enclosed XML. Default is
1363 UTF-8.
1365 Encoding considerations: Uses XML, which can employ 8-bit
1366 characters, depending on the character encoding used. See RFC
1367 3023 [RFC3023], section 3.2.
1368 Security considerations: This content type is designed to carry
1369 protocol data related to the location of an entity, which could
1370 include information that is considered private. Appropriate
1371 precautions should be taken to limit disclosure of this
1372 information.
1373 Interoperability considerations: This content type provides a basis
1374 for a protocol
1375 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
1376 replace XXXX with the RFC number for this specification.]
1377 Applications which use this media type: Location information
1378 providers and consumers.
1379 Additional Information: Magic Number(s): (none)
1380 File extension(s): .xml
1381 Macintosh File Type Code(s): (none)
1382 Person & email address to contact for further information: Mary
1383 Barnes
1384 Intended usage: LIMITED USE
1385 Author/Change controller: The IETF
1386 Other information: This media type is a specialization of
1387 application/xml [RFC3023], and many of the considerations
1388 described there also apply to application/held+xml.
1390 12.4. Error code Registry
1392 This document requests that the IANA create a new registry for the
1393 HELD protocol including an initial registry for error codes. The
1394 error codes are included in HELD error messages as described in
1395 Section 6.3 and defined in the schema in the 'codeType' token in the
1396 XML schema in (Section 7)
1398 The following summarizes the requested registry:
1400 Related Registry: Geopriv HELD Registries, Error codes for HELD
1401 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1402 with the RFC number for this specification.]
1403 Registration/Assignment Procedures: Following the policies outlined
1404 in [RFC5226], the IANA policy for assigning new values for the
1405 Error codes for HELD shall be Specification Required: values and
1406 their meanings must be documented in an RFC or in some other
1407 permanent and readily available reference, in sufficient detail
1408 that interoperability between independent implementations is
1409 possible.
1411 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1412 Mary Barnes (mary.barnes@nortel.com).
1414 This section pre-registers the following seven initial error codes as
1415 described above in Section 6.3:
1417 requestError: This code indicates that the request was badly formed
1418 in some fashion.
1419 xmlError: This code indicates that the XML content of the request
1420 was either badly formed or invalid.
1421 generalLisError: This code indicates that an unspecified error
1422 occurred at the LIS.
1423 locationUnknown: This code indicates that the LIS could not
1424 determine the location of the Device.
1425 unsupportedMessage: This code indicates that the request was not
1426 supported or understood by the LIS. This error code is used when
1427 a HELD request contains a document element that is not supported
1428 by the receiver.
1429 timeout: This code indicates that the LIS could not satisfy the
1430 request within the time specified in the "responseTime" parameter.
1431 cannotProvideLiType: This code indicates that the LIS was unable to
1432 provide LI of the type or types requested. This code is used when
1433 the "exact" attribute on the "locationType" parameter is set to
1434 "true".
1435 notLocatable: This code indicates that the LIS is unable to locate
1436 the Device, and that the Device MUST NOT make further attempts to
1437 retrieve LI from this LIS. This error code is used to indicate
1438 that the Device is outside the access network served by the LIS;
1439 for instance, the VPN and NAT scenarios discussed in
1440 Section 4.1.2.
1442 12.5. URI Registrations
1444 The following summarizes the information necessary to register the
1445 heldref: and heldrefs: URIs. [NOTE TO IANA/RFC-EDITOR: Please
1446 replace XXXX with the RFC number for this specification in the
1447 following list.]
1449 12.5.1. heldref: URI Registration
1451 URI Scheme Name: heldref
1452 Status: permanent
1453 URI Scheme syntax: See section Section 8.1.
1454 URI Scheme Semantics: The heldref: URI is intended to be used as a
1455 reference to a location object or a location information server.
1456 Further detail is provided in Section 8 of RFC XXXX.
1458 Encoding Considerations: The heldref: URI is not intended to be
1459 human-readable text, therefore they are encoded entirely in US-
1460 ASCII.
1461 Applications/protocols that use this URI scheme: The HELD protocol
1462 described in RFC XXXX and the GEOPRIV Location De-reference
1463 Protocol [I-D.winterbottom-geopriv-deref-protocol].
1464 Interoperability considerations: This URI may be used as a parameter
1465 for the HELD protocol in the locationResponse message. This URI
1466 is also used as an input parameter for the GEOPRIV Location De-
1467 reference Protocol [I-D.winterbottom-geopriv-deref-protocol].
1468 Refer to Section 8 in RFC XXXX for further detail and a particular
1469 example on the lack of permanence of a specific heldref: URI and
1470 thus the importance of using these URIs only within the specific
1471 contexts outlined in the references.
1472 Security considerations: Section 10 in RFC XXXX addresses the
1473 necessary security associated with the transport of location
1474 information between a Device and the LIS to ensure the privacy and
1475 integrity of the heldref: URI. Section 6.5.1 in RFC XXXX also
1476 recommends that the URI be allocated such that it does not reveal
1477 any detail at all about the content of the PIDF-LO that it may
1478 indirectly reference.
1479 Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
1480 Barnes (mary.barnes@nortel.com).
1481 Author/Change controller: This scheme is registered under the IETF
1482 tree. As such, IETF maintains change control.
1483 References: RFC XXXX, GEOPRIV Location De-reference Protocol
1484 [I-D.winterbottom-geopriv-deref-protocol]
1486 12.5.2. heldrefs: URI Registration
1488 URI Scheme Name: heldrefs
1489 Status: permanent
1490 URI Scheme syntax: See section Section 8.2.
1491 URI Scheme Semantics: The heldrefs: URI is intended to be used as a
1492 reference to a location object or a location information server.
1493 Further detail is provided in Section 8 of RFC XXXX.
1494 Encoding Considerations: The HELDS: URI is not intended to be human-
1495 readable text, therefore they are encoded entirely in US-ASCII.
1496 Applications/protocols that use this URI scheme: The HELD protocol
1497 described in RFC XXXX and the GEOPRIV Location De-reference
1498 Protocol [I-D.winterbottom-geopriv-deref-protocol].
1499 Interoperability considerations: This URI may be used as a parameter
1500 for the HELD protocol in the locationResponse message. This URI
1501 is also used as an input parameter for the GEOPRIV Location De-
1502 reference Protocol [I-D.winterbottom-geopriv-deref-protocol].
1503 Refer to Section 8 in RFC XXXX for further detail and a particular
1504 example on the lack of permanence of a specific heldrefs: URI and
1505 thus the importance of using these URIs only within the specific
1506 contexts outlined in the references.
1507 Security considerations: Section 10 in RFC XXXX addresses the
1508 necessary security associated with the transport of location
1509 information between a Device and the LIS to ensure the privacy and
1510 integrity of the heldrefs: URI. Section 6.5.1 in RFC XXXX also
1511 recommends that the URI be allocated such that it does not reveal
1512 any detail at all about the content of the PIDF-LO that it may
1513 indirectly reference.
1514 Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
1515 Barnes (mary.barnes@nortel.com).
1516 Author/Change controller: This scheme is registered under the IETF
1517 tree. As such, IETF maintains change control.
1518 References: RFC XXXX, GEOPRIV Location De-reference Protocol
1519 [I-D.winterbottom-geopriv-deref-protocol]
1521 13. Contributors
1523 James Winterbottom, Martin Thomson and Barbara Stark are the authors
1524 of the original document, from which this WG document was derived.
1525 Their contact information is included in the Author's address
1526 section. In addition, they also contributed to the WG document,
1527 including the XML schema.
1529 14. Acknowledgements
1531 The author/contributors would like to thank the participants in the
1532 GEOPRIV WG and the following people for their constructive input and
1533 feedback on this document (in alphabetical order): Nadine Abbott,
1534 Eric Arolick, Richard Barnes (in particular the security section),
1535 Peter Blatherwick, Ben Campbell, Guy Caron, Martin Dawson, Lisa
1536 Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil
1537 Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall,
1538 Perry Prozeniuk, Carl Reed, Eric Rescorla, Brian Rosen, John
1539 Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Shrum, Doug
1540 Stuard, Hannes Tschofenig and Karl Heinz Wolf.
1542 15. Changes since last Version
1544 NOTE TO THE RFC-Editor: Please remove this section prior to
1545 publication as an RFC.
1547 Changes from WG 07 to 08 (IETF LC: sec-dir and gen-art review
1548 comments):
1550 1) Fix editorial nits: rearranging sections in 4.1 for readibility,
1551 etc.
1553 2) Added back text in Device and VPN section referencing DHCP and
1554 LLDP-MED when a VPN device serves as a LIS.
1556 3) Clarified the use of both HTTP and HTTPS.
1558 4) Defined two URIs related to 3 respectively - divided IANA
1559 registrations into sub-sections to accomodate this change. (Note:
1560 LIS Discovery will now define that URI, thus this document defines
1561 the one associatied with a Location reference).
1563 5) Clarified the description of the location URI in Protocol Overview
1564 and Protocol parameter sections. Note that these sections again
1565 reference location dereference protocol for completeness and
1566 clarification of issues that are out of scope for this base document.
1568 6) Defined new error code: notLocatable.
1570 7) Clarifications and corrections in security section.
1572 8) Clarified text for locationType, specifically removing extra text
1573 from "any" description and putting that in a separate paragraph.
1574 Also, provided an example.
1576 9) Added boundaries for "expires" parameter.
1578 10) Clarified that the HELD protocol as defined by this document does
1579 not allow for canceling location references.
1581 Changes from WG 06 to 07 (PROTO review comments):
1583 1) Fix nits: remove unused references, move requirements to
1584 Informational References section, fix long line in ABNF, fix ABNF
1585 (quotes around '?'), add schemaLocation to import namespace in XML
1586 schema.
1588 2) Remove text in Device and VPN section referencing DHCP and LLDP-
1589 MED when a VPN device serves as a LIS, per Issue 1 resolution at
1590 IETF-71. (Editorial oversight in producing version 06).
1592 Changes from WG 05 to 06 (2nd WGLC comments):
1594 1) Updated security section based on WG feedback, including
1595 condensing section 10.1.1 (Assuring the proper LIS has been
1596 contacted), restructuring sections by flattening, adding an
1597 additional step to the list that had been in the Accuracy section and
1598 removing summary section.
1600 2) Changed URI schema to "helds" to address concerns over referential
1601 integrity and for consistency with mandate of TLS for HELD.
1603 3) Editorial clarifications including fixing examples to match HELD
1604 URI definition (e.g., adding port, adding randomness to URI examples,
1605 etc.)
1607 4) Updated references removing unused references and moving
1608 requirements docs to Informational Reference section to avoid
1609 downrefs.
1611 Changes from WG 04 to 05 (WGLC comments):
1613 1) Totally replaced the security section with the details provided by
1614 Richard Barnes so that we don't need a reference to the location
1615 security document.
1617 2) Fixed error codes in schema to allow extensibility. Change the
1618 IANA registration to be "specification required".
1620 3) Cleaned up the HELD: URI description, per comments from Martin and
1621 James and partially addressing HELD-04 Issue 1. Put the definition
1622 in a separate section and clarified the applicability (to also
1623 include being a results of the discovery process) and fixed examples.
1625 4) Updated the LocationURI section to be more accurate, address
1626 HELD-04 Issue 3, and include the reference to the new HELD:URI
1627 section. Also, fixed an error in the doc in that the top level parm
1628 in the locationResponse is actually locationUriSet, which contains
1629 any number of locationURI elements and the "expires" parameter. So,
1630 Table 1 was also updated and a new section for the LocationURISet was
1631 added that includes the subsections for the "locationURI" and
1632 "expires". And, then clarified that "expires" applies to
1633 "locationURISet" and not per "locationURI".
1635 5) Editorial nits: pointed out offline by Richard (e.g., by-value ->
1636 by value, by-reference -> by reference, etc.) and onlist by James and
1637 Martin. Please refer to the diff for a complete view of editorial
1638 changes.
1640 6) Added text in HTTP binding section to disable HTTP caching
1641 (HELD-04 Issue 5 on the list).
1643 Changes from WG 03 to 04:
1645 1) Terminology: clarified in terminology section that "attribute" and
1646 "element" are used in the strict XML sense and "parameter" is used as
1647 a general protocol term Replaced term "HTTP delivery" with "HTTP
1648 transport". Still have two terms "HTTP transport" and "HTTP
1649 binding", but those are consistent with general uses of HTTP.
1651 2) Editorial changes and clarifications: per Roger Marshall's and
1652 Eric Arolick's comments and subsequent WG mailing list discussion.
1654 3) Changed normative language for describing expected and recommended
1655 LIS behaviors to be non-normative recommendations in cases where the
1656 protocol parameters were not the target of the discussion (e.g., we
1657 can't prescribe to the LIS how it determines location or what it
1658 defines to be an "accurate" location).
1660 4) Clarified responseTime attribute (section 6.1). Changed type from
1661 "decimal" to "nonNegativeInteger" in XML schema (section 7)
1663 5) Updated Table 1 in section 6 to only include top-level parameters
1664 and fixed some errors in that table (i.e., code for locationResponse)
1665 and adding PIDF-LO to the table. Added a detailed section describing
1666 PIDF-LO (section 6.6), moving some of the normative text in the
1667 Protocol Overview to this section.
1669 6) Added schema and description for locationURI to section 6.5.
1670 Added IANA registration for HELD: URI schema.
1672 7) Added IANA registry for error codes.
1674 Changes from WG 02 to 03:
1676 1) Added text to address concern over use of IP address as device
1677 identifier, per long email thread - changes to section 3 (overview)
1678 and section 4 (protocol overview).
1680 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed)
1682 3) Added extensibility to baseRequestType in the schema (an oversight
1683 from previous edits), along with fixing some other nits in schema
1684 (section 7)
1686 4) Moved discussion of Location URI from section 5.3 (Location
1687 Response) to where it rightly belonged in Section 6.5 (Location URI
1688 Parameter).
1690 5) Clarified text for "expires" parameter (6.5.1) - it's an optional
1691 parm, but required for LocationURIs
1693 6) Clarified responseTime parameter: when missing, then the LCS
1694 provides most precise LI, with the time required being implementation
1695 specific.
1697 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST
1698 implement.
1700 8) Updated references (removed unused/added new).
1702 Changes from WG 01 to 02:
1704 1) Updated Terminology to be consistent with WG agreements and other
1705 documents (e.g., LCS -> LIS and removed duplicate terms). In the
1706 end, there are no new terms defined in this document.
1708 2) Modified definition of responseTime to reflect WG consensus.
1710 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving
1711 just "civic").
1713 4) Clarified text that locationType is optional. Fixed table 1 and
1714 text in section 5.2 (locationRequest description). Text in section
1715 6.2 (description of locationType element) already defined the default
1716 to be "any".
1718 5) Simplified error responses. Separated the definition of error
1719 response type from the locationResponse type thus no need for
1720 defining an error code of "success". This simplifies the schema and
1721 processing.
1723 6) Updated schema/examples for the above.
1725 7) Updated Appendix A based on updates to requirements document,
1726 specifically changes to A.1, A.3 and adding A.10.
1728 8) Miscellaneous editorial clarifications.
1730 Changes from WG 00 to 01:
1732 1) heldResponse renamed to locationResponse.
1734 2) Changed namespace references for the PIDF-LO geoShape in the
1735 schema to match the agreed GML PIDF-LO Geometry Shape Application
1736 Schema.
1738 3) Removed "options" element - leaving optionality/extensibility to
1739 XML mechanisms.
1741 4) Changed error codes to be enumerations and not redefinitions of
1742 HTTP response codes.
1744 5) Updated schema/examples for the above and removed some remnants of
1745 the context element.
1747 6) Clarified the definition of "Location Information (LI)" to include
1748 a reference to the location (to match the XML schema and provide
1749 consistency of usage throughout the document). Added an additional
1750 statement in section 7.2 (locationType) to clarify that LCS MAY also
1751 return a Location URI.
1753 7) Modifed the definition of "Location Configuration Server (LCS)" to
1754 be consistent with the current definiton in the requirements
1755 document.
1757 8) Updated Location Response (section 6.3) to remove reference to
1758 context and discuss the used of a local identifier or unlinked
1759 pseudonym in providing privacy/security.
1761 9) Clarified that the source IP address in the request is used as the
1762 identifier for the target/device for the HELD protocol as defined in
1763 this document.
1765 10) Miscellaneous editorial clarifications.
1767 16. References
1769 16.1. Normative References
1771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1772 Requirement Levels", BCP 14, RFC 2119, March 1997.
1774 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1775 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
1777 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1778 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1779 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1781 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1783 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1784 January 2004.
1786 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
1787 Networks", BCP 84, RFC 3704, March 2004.
1789 [I-D.ietf-geopriv-pdif-lo-profile]
1790 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
1791 PIDF-LO Usage Clarification, Considerations and
1792 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11
1793 (work in progress), February 2008.
1795 [W3C.REC-xmlschema-1-20041028]
1796 Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn,
1797 "XML Schema Part 1: Structures Second Edition", World Wide
1798 Web Consortium Recommendation REC-xmlschema-1-20041028,
1799 October 2004,
1800 .
1802 [W3C.REC-xmlschema-2-20041028]
1803 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
1804 Second Edition", World Wide Web Consortium
1805 Recommendation REC-xmlschema-2-20041028, October 2004,
1806 .
1808 [I-D.ietf-geopriv-lis-discovery]
1809 Thomson, M. and J. Winterbottom, "Discovering the Local
1810 Location Information Server (LIS)",
1811 draft-ietf-geopriv-lis-discovery-01 (work in progress),
1812 June 2008.
1814 16.2. Informative References
1816 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
1817 RFC 793, September 1981.
1819 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
1820 Types", RFC 3023, January 2001.
1822 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
1823 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
1825 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
1826 Configuration Protocol Option for Coordinate-based
1827 Location Configuration Information", RFC 3825, July 2004.
1829 [LLDP-MED]
1830 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
1831 Endpoint Discovery".
1833 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1834 Resource Identifier (URI): Generic Syntax", STD 66,
1835 RFC 3986, January 2005.
1837 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
1838 Registration Procedures for New URI Schemes", BCP 115,
1839 RFC 4395, February 2006.
1841 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1842 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1843 May 2008.
1845 [I-D.ietf-geopriv-l7-lcp-ps]
1846 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
1847 Location Configuration Protocol; Problem Statement and
1848 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
1849 progress), June 2008.
1851 [I-D.ietf-geopriv-lbyr-requirements]
1852 Marshall, R., "Requirements for a Location-by-Reference
1853 Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work
1854 in progress), July 2008.
1856 [I-D.ietf-sip-location-conveyance]
1857 Polk, J. and B. Rosen, "Location Conveyance for the
1858 Session Initiation Protocol",
1859 draft-ietf-sip-location-conveyance-10 (work in progress),
1860 February 2008.
1862 [I-D.winterbottom-geopriv-deref-protocol]
1863 Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
1864 Thomson, M., and M. Dawson, "An HTTPS Location
1865 Dereferencing Protocol Using HELD",
1866 draft-winterbottom-geopriv-deref-protocol-01 (work in
1867 progress), July 2008.
1869 Appendix A. HELD Compliance to IETF LCP requirements
1871 This appendix describes HELD's compliance to the requirements
1872 specified in the [I-D.ietf-geopriv-l7-lcp-ps].
1874 A.1. L7-1: Identifier Choice
1876 "The L7 LCP MUST be able to carry different identifiers or MUST
1877 define an identifier that is mandatory to implement. Regarding the
1878 latter aspect, such an identifier is only appropriate if it is from
1879 the same realm as the one for which the location information service
1880 maintains identifier to location mapping."
1882 COMPLY
1884 HELD uses the IP address of the location request message as the
1885 primary source of identity for the requesting device or target. This
1886 identity can be used with other contextual network information to
1887 provide a physical location for the Target for many network
1888 deployments. There may be network deployments where an IP address
1889 alone is insufficient to identify a Target in a network. However,
1890 any necessary identity extensions for these networks is beyond the
1891 scope of this document.
1893 A.2. L7-2: Mobility Support
1895 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
1896 broad range of mobility from devices that can only move between
1897 reboots, to devices that can change attachment points with the impact
1898 that their IP address is changed, to devices that do not change their
1899 IP address while roaming, to devices that continuously move by being
1900 attached to the same network attachment point."
1902 COMPLY
1904 Mobility support is inherently a characteristic of the access network
1905 technology and HELD is designed to be access network agnostic.
1906 Consequently HELD complies with this requirement. In addition HELD
1907 provides specific support for mobile environments by providing an
1908 optional responseTime attribute in location request messages.
1909 Wireless networks often have several different mechanisms at their
1910 disposal for position determination (e.g. Assisted GPS versus
1911 location based on serving base station identity), each providing
1912 different degrees of accuracy and taking different amounts of time to
1913 yield a result. The responseTime parameter provides the LIS with a
1914 criterion which it can use to select a location determination
1915 technique.
1917 A.3. L7-3: ASP and Access Network Provider Relationship
1919 "The design of the L7 LCP MUST NOT assume a business or trust
1920 relationship between the Application Service Provider (ASP) and the
1921 Access Network Provider. Requirements for resolving a reference to
1922 location information are not discussed in this document."
1924 COMPLY
1926 HELD describes a location acquisition protocol between a Device and a
1927 LIS. In the context of HELD, the LIS is within the Access Network.
1928 Thus, HELD is independent of the business or trust relationship
1929 between the Application Service Provider (ASP) and the Access Network
1930 Provider. Location acquisition using HELD is subject to the
1931 restrictions described in Section 10.
1933 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
1935 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1936 MUST assume that there is a trust and business relationship between
1937 the L2 and the L3 provider. The L3 provider operates the LIS and
1938 needs to obtain location information from the L2 provider since this
1939 one is closest to the end host. If the L2 and L3 provider for the
1940 same host are different entities, they cooperate for the purposes
1941 needed to determine end system locations."
1943 COMPLY
1945 HELD was specifically designed with this model in mind and readily
1946 allows itself to chaining requests between operators without a change
1947 in protocol being required. HELD is a webservices protocol it can be
1948 bound to transports other than HTTP. Using o offers the option of
1949 high request throughput over a dedicated connection between an L3
1950 provider and an L2 provider without incurring the serial restriction
1951 imposed by HTTP. This is less easy to do with protocols that do not
1952 decouple themselves from the transport.
1954 A.5. L7-5: Legacy Device Considerations
1956 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1957 MUST consider legacy residential NAT devices and NTEs in an DSL
1958 environment that cannot be upgraded to support additional protocols,
1959 for example to pass additional information through DHCP."
1961 COMPLY
1963 HELD is an application protocol and operates on top of IP. A HELD
1964 request from a host behind a residential NAT will traverse the NAT
1965 acquiring the external address of the home router. The location
1966 provided to the host therefore will be the address of the home router
1967 in this circumstance. No changes are required to the home router in
1968 order to support this function, HELD was designed specifically to
1969 address this deployment scenario.
1971 A.6. L7-6: VPN Awareness
1973 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1974 MUST assume that at least one end of a VPN is aware of the VPN
1975 functionality. In an enterprise scenario, the enterprise side will
1976 provide the LIS used by the client and can thereby detect whether the
1977 LIS request was initiated through a VPN tunnel."
1979 COMPLY
1980 HELD does not preclude a LIS on the far end of a VPN tunnel being
1981 aware that the client request is occurring over that tunnel. It also
1982 does not preclude a client device from accessing a LIS serving the
1983 local physical network and subsequently using the location
1984 information with an application that is accessed over a VPN tunnel.
1986 A.7. L7-7: Network Access Authentication
1988 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1989 MUST NOT assume prior network access authentication."
1991 COMPLY
1993 HELD makes no assumptions about prior network access authentication.
1994 HELD strongly recommends the use of TLS with server-side certificates
1995 for communication between the end-point and the LIS. There is no
1996 requirement for the end-point to authenticate with the LIS.
1998 A.8. L7-8: Network Topology Unawareness
2000 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
2001 MUST NOT assume end systems being aware of the access network
2002 topology. End systems are, however, able to determine their public
2003 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
2005 COMPLY
2007 HELD makes no assumption about the network topology. HELD doesn't
2008 require that the device know its external IP address, except where
2009 that is required for discovery of the LIS.
2011 A.9. L7-9: Discovery Mechanism
2013 "The L7 LCP MUST define a single mandatory to implement discovery
2014 mechanism."
2016 COMPLY
2018 HELD uses the discovery mechanism in
2019 [I-D.ietf-geopriv-lis-discovery].
2021 A.10. L7-10: PIDF-LO Creation
2023 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
2024 element into the element of the presence document
2025 (see RFC 4479). This ensures that the resulting PIDF-LO document,
2026 which is subsequently distributed to other entities, conforms to the
2027 rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile]
2028 COMPLY
2030 HELD protocol overview (Section 4 ) describes the requirements on the
2031 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
2032 by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile].
2034 Authors' Addresses
2036 Mary Barnes (editor)
2037 Nortel
2038 2201 Lakeside Blvd
2039 Richardson, TX
2041 Email: mary.barnes@nortel.com
2043 James Winterbottom
2044 Andrew
2045 PO Box U40
2046 Wollongong University Campus, NSW 2500
2047 AU
2049 Phone: +61 2 4221 2938
2050 Email: james.winterbottom@andrew.com
2051 URI: http://www.andrew.com/
2053 Martin Thomson
2054 Andrew
2055 PO Box U40
2056 Wollongong University Campus, NSW 2500
2057 AU
2059 Phone: +61 2 4221 2915
2060 Email: martin.thomson@andrew.com
2061 URI: http://www.andrew.com/
2062 Barbara Stark
2063 BellSouth
2064 Room 7A43
2065 725 W Peachtree St.
2066 Atlanta, GA 30308
2067 US
2069 Email: barbara.stark@att.com
2071 Full Copyright Statement
2073 Copyright (C) The IETF Trust (2008).
2075 This document is subject to the rights, licenses and restrictions
2076 contained in BCP 78, and except as set forth therein, the authors
2077 retain all their rights.
2079 This document and the information contained herein are provided on an
2080 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2081 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
2082 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
2083 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
2084 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2085 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2087 Intellectual Property
2089 The IETF takes no position regarding the validity or scope of any
2090 Intellectual Property Rights or other rights that might be claimed to
2091 pertain to the implementation or use of the technology described in
2092 this document or the extent to which any license under such rights
2093 might or might not be available; nor does it represent that it has
2094 made any independent effort to identify any such rights. Information
2095 on the procedures with respect to rights in RFC documents can be
2096 found in BCP 78 and BCP 79.
2098 Copies of IPR disclosures made to the IETF Secretariat and any
2099 assurances of licenses to be made available, or the result of an
2100 attempt made to obtain a general license or permission for the use of
2101 such proprietary rights by implementers or users of this
2102 specification can be obtained from the IETF on-line IPR repository at
2103 http://www.ietf.org/ipr.
2105 The IETF invites any interested party to bring to its attention any
2106 copyrights, patents or patent applications, or other proprietary
2107 rights that may cover technology that may be required to implement
2108 this standard. Please address the information to the IETF at
2109 ietf-ipr@ietf.org.