idnits 2.17.1
draft-ietf-geopriv-http-location-delivery-10.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 1942.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1953.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1960.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1966.
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 (October 29, 2008) is 5649 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)
== Unused Reference: 'RFC4395' is defined on line 1693, but no explicit
reference was found in the text
** 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-13
== Outdated reference: A later version (-15) exists of
draft-ietf-geopriv-lis-discovery-03
-- 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-02
Summary: 4 errors (**), 0 flaws (~~), 8 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: May 2, 2009
7 October 29, 2008
9 HTTP Enabled Location Delivery (HELD)
10 draft-ietf-geopriv-http-location-delivery-10.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 May 2, 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 . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . 11
64 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 11
65 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
75 8. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 20
76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
77 9.1. Assuring that the proper LIS has been contacted . . . . . 22
78 9.2. Protecting responses from modification . . . . . . . . . . 22
79 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22
80 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
81 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 24
82 10.2. Simple Location Request Example . . . . . . . . . . . . . 26
83 10.3. Location Request Example for Multiple Location Types . . . 27
84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
85 11.1. URN Sub-Namespace Registration for
86 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
87 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
88 11.3. MIME Media Type Registration for 'application/held+xml' . 29
89 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30
90 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
91 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
92 14. Changes since last Version . . . . . . . . . . . . . . . . . . 32
93 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
94 15.1. Normative References . . . . . . . . . . . . . . . . . . . 37
95 15.2. Informative References . . . . . . . . . . . . . . . . . . 38
97 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 39
98 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 39
99 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 40
100 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 40
101 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 41
102 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 41
103 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 41
104 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 42
105 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 42
106 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 42
107 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 42
108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
109 Intellectual Property and Copyright Statements . . . . . . . . . . 45
111 1. Introduction
113 The location of a Device is information that is useful for a number
114 of applications. The L7 Location Configuration Protocol (LCP)
115 problem statement and requirements document
116 [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a
117 Device might rely on its access network to provide location
118 information. The Location Information Server (LIS) service applies
119 to access networks employing both wired technology (e.g. DSL, Cable)
120 and wireless technology (e.g. WiMAX) with varying degrees of Device
121 mobility. This document describes a protocol that can be used to
122 acquire Location Information (LI) from a LIS within an access
123 network.
125 This specification identifies two types of location information that
126 may be retrieved from the LIS. Location may be retrieved from the
127 LIS by value, that is, the Device may acquire a literal location
128 object describing the location of the Device. The Device may also
129 request that the LIS provide a location reference in the form of a
130 location URI or set of location URIs, allowing the Device to
131 distribute its LI by reference. Both of these methods can be
132 provided concurrently from the same LIS to accommodate application
133 requirements for different types of location information.
135 This specification defines an extensible XML-based protocol that
136 enables the retrieval of LI from a LIS by a Device. This protocol
137 can be bound to any session-layer protocol, particularly those
138 capable of MIME transport. This document describes the use of
139 HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
140 Security (HTTP/TLS) as transports for the protocol.
142 2. Conventions & Terminology
144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
146 document are to be interpreted as described in [RFC2119].
148 This document uses the terms (and their acronym forms) Access
149 Provider (AP), Location Information (LI), Location Object (LO),
150 Device, Target, Location Generator (LG), Location Recipient (LR),
151 Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV
152 Requirements [RFC3693] . The terms Location Information Server
153 (LIS), Access Network, Access Provider (AP) and Access Network
154 Provider are used in the same context as defined in the L7 LCP
155 Problem statement and Requirements document
156 [I-D.ietf-geopriv-l7-lcp-ps]. The usage of the terms, Civic
157 Location/Address and Geodetic Location follows the usage in many of
158 the referenced documents.
160 In describing the protocol, the terms "attribute" and "element" are
161 used according to their context in XML. The term "parameter" is used
162 in a more general protocol context and can refer to either an XML
163 "attribute" or "element".
165 3. Overview and Scope
167 This document describes an interface between a Device and a Location
168 Information Server (LIS). This document assumes that the LIS is
169 present within the same administrative domain as the Device (e.g.,
170 the access network). An Access Provider (AP) operates the LIS so
171 that Devices (and Targets) can retrieve their LI. The LIS exists
172 because not all Devices are capable of determining LI, and because,
173 even if a device is able to determine its own LI, it may be more
174 efficient with assistance. This document does not specify how LI is
175 determined.
177 This document is based on the attribution of the LI to a Device and
178 not specifically a person (end user) or Target, based on the premise
179 that location determination technologies are generally designed to
180 locate a device and not a person. It is expected that, for most
181 applications, LI for the device can be used as an adequate substitute
182 for the end user's LI. Since revealing the location of the device
183 almost invariably reveals some information about the location of the
184 user of the device, the same level of privacy protection demanded by
185 a user is required for the device. This approach may require either
186 some additional assurances about the link between device and target,
187 or an acceptance of the limitation that unless the device requires
188 active user authentication, there is no guarantee that any particular
189 individual is using the device at that instant.
191 The following diagram shows the logical configuration of some of the
192 functional elements identified in [RFC3693] and the LIS defined in
193 [I-D.ietf-geopriv-l7-lcp-ps] and where this protocol applies, with
194 the Rule Maker and Target represented by the role of the Device.
195 Note that only the interfaces relevant to the Device are identified
196 in the diagram.
198 +---------------------------------------------+
199 | Access Network Provider |
200 | |
201 | +--------------------------------------+ |
202 | | Location Information Server | |
203 | | | |
204 | | | |
205 | | | |
206 | | | |
207 | +------|-------------------------------+ |
208 +----------|----------------------------------+
209 |
210 |
211 HELD
212 |
213 Rule Maker - _ +-----------+ +-----------+
214 o - - | Device | | Location |
215
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
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
787
788
789
790
791
792
793
794
795
796
797
799
800
801
802
804
805
806
808
809
810
811
812
813
815
816
817
818
820
821
822
823
824
826
828
829
830
831
833
835
836
837
838
839
840
843
845
846
848
849
851
854
856
857
858
859
860
863
865
866
867
868
870
873
875 8. HTTP/HTTPS Binding
877 This section describes the use of HTTP [RFC2616] and HTTPS [RFC2818]
878 as transport mechanisms for the HELD protocol, which all conforming
879 implementations MUST support.
881 The request is carried in the body of an HTTP/HTTPS POST request.
882 The MIME type of both request and response bodies should be
883 "application/held+xml". This should be reflected in the HTTP
884 Content-Type and Accept header fields.
886 The LIS populates the HTTP/HTTPS headers so that they are consistent
887 with the contents of the message. In particular, the cache control
888 header SHOULD be set to disable the HTTP/HTTPS caching of any PIDF-LO
889 document or Location URIs. Otherwise, there is the risk of stale
890 locations and/or the unauthorized disclosure of the LI. This also
891 allows the LIS to control any caching with the "expires" parameter.
892 The HTTP/HTTPS status code MUST indicate a 2xx series response for
893 all HELD locationResponse and error messages.
895 The use of HTTP/HTTPS also includes a default behaviour, which is
896 triggered by a GET request, or a POST with no request body. If
897 either of these queries are received, the LIS MUST attempt to provide
898 either a PIDF-LO document or a Location URI, as if the request was a
899 location request.
901 Implementation of HELD that implement HTTP transport MUST implement a
902 transport over HTTPS [RFC2818]. TLS provides message integrity and
903 confidentiality between Device and LIS. The LIS MUST implement the
904 server authentication method described in [RFC2818]. The device uses
905 the URI obtained during LIS discovery to authenticate the server.
906 The details of this authentication method are provided in section 3.1
907 of [RFC2818]. When TLS is used, the Device SHOULD fail a request if
908 server authentication fails, except in the event of an emergency.
910 9. Security Considerations
912 HELD is a location acquisition protocol whereby the a client requests
913 its location from a LIS. Specific requirements and security
914 considerations for location acquisition protocols are provided in
915 [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security
916 considerations applicable to the use of Location URIs and by
917 reference provision of LI is included in
918 [I-D.ietf-geopriv-lbyr-requirements].
920 By using the HELD protocol, the client and the LIS expose themselves
921 to two types of risk:
923 Accuracy: Client receives incorrect location information
924 Privacy: An unauthorized entity receives location information
926 The provision of an accurate and privacy/confidentiality protected
927 location to the requestor depends on the success of five steps:
929 1. The client must determine the proper LIS.
930 2. The client must connect to the proper LIS.
931 3. The LIS must be able to identify the device by its identifier
932 (IP Address).
933 4. The LIS must be able to return the desired location.
934 5. HELD messages must be transmitted unmodified between the LIS
935 and the client.
937 Of these, only the second, third and the fifth are within the scope
938 of this document. The first step is based on either manual
939 configuration or on the LIS discovery defined in
941 [I-D.ietf-geopriv-lis-discovery], in which appropriate security
942 considerations are already discussed. The fourth step is dependent
943 on the specific positioning capabilities of the LIS, and is thus
944 outside the scope of this document.
946 9.1. Assuring that the proper LIS has been contacted
948 This document assumes that the LIS to be contacted is identified
949 either by an IP address or a domain name, as is the case for a LIS
950 discovered as described in LIS Discovery
951 [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is
952 conducted using TLS [RFC4346], the LIS can authenticate its identity,
953 either as a domain name or as an IP address, to the client by
954 presenting a certificate containing that identifier as a
955 subjectAltName (i.e., as an iPAddress or dNSName, respectively). In
956 the case of the HTTP binding described above, this is exactly the
957 authentication described by TLS [RFC2818]. Any binding of HELD MUST
958 be capable of being transacted over TLS so that the client can
959 request the above authentication, and a LIS implementation for a
960 binding MUST include this feature. Note that in order for the
961 presented certificate to be valid at the client, the client must be
962 able to validate the certificate. In particular, the validation path
963 of the certificate must end in one of the client's trust anchors,
964 even if that trust anchor is the LIS certificate itself.
966 9.2. Protecting responses from modification
968 In order to prevent that response from being modified en route,
969 messages must be transmitted over an integrity-protected channel.
970 When the transaction is being conducted over TLS (a required feature
971 per Section 9.1), the channel will be integrity protected by
972 appropriate ciphersuites. When TLS is not used, this protection will
973 vary depending on the binding; in most cases, without protection from
974 TLS, the response will not be protected from modification en route.
976 9.3. Privacy and Confidentiality
978 Location information returned by the LIS must be protected from
979 access by unauthorized parties, whether those parties request the
980 location from the LIS or intercept it en route. As in Section 9.2,
981 transactions conducted over TLS with appropriate ciphersuites are
982 protected from access by unauthorized parties en route. Conversely,
983 in most cases, when not conducted over TLS, the response will be
984 accessible while en route from the LIS to the requestor.
986 Because HELD is an LCP and identifies clients and targets by IP
987 addresses, a requestor is authorized to access location for an IP
988 address only if it is the holder of that IP address. The LIS MUST
989 verify that the client is the target of the returned location, i.e.,
990 the LIS MUST NOT provide location to other entities than the target.
991 Note that this is a necessary, but not sufficient criterion for
992 authorization. A LIS MAY deny requests according to any local
993 policy.
995 A prerequisite for meeting this requirement is that the LIS must have
996 some assurance of the identity of the client. Since the target of
997 the returned location is identified by an IP address, simply sending
998 the response to this IP address will provide sufficient assurance in
999 many cases. This is the default mechanism in HELD for assuring that
1000 location is given only to authorized clients; LIS implementations
1001 MUST support a mode of operation in which this is the only client
1002 authentication.
1004 Using IP return routability as an authenticator means that location
1005 information is vulnerable to exposure through IP address spoofing
1006 attacks. A temporary spoofing of IP address could mean that a device
1007 could request a Location Object or Location URI that would result in
1008 another Device's location. In addition, in cases where a Device
1009 drops off the network for various reasons, the re-use of the Device's
1010 IP address could result in another Device receiving the original
1011 Device's location rather than its own location. These exposures are
1012 limited by the following:
1014 o Location URIs MUST have a limited lifetime, as reflected by the
1015 value for the expires element in Section 6.5.2. The lifetime of
1016 location URIs necessarily depends on the nature of the access.
1017 o The network SHOULD have mechanisms that protect against IP address
1018 spoofing, such as those defined in [RFC3704].
1019 o The LIS and network SHOULD be configured so that the LIS is made
1020 aware of Device movement within the network and addressing
1021 changes. If the LIS detects a change in the network that results
1022 in it no longer being able to determine the location of the
1023 Device, then all location URIs for that Device SHOULD be
1024 invalidated.
1026 The above measures are dependent on network configuration, which
1027 SHOULD be considered. For instance, in a fixed internet access,
1028 providers may be able to restrict the allocation of IP addresses to a
1029 single physical line, ensuring that spoofing is not possible; in such
1030 an environment, additional measures may not be necessary.
1032 10. Examples
1034 The following sections provide basic HTTP/HTTPS examples, a simple
1035 location request example and a location request for multiple location
1036 types example along with the relevant location responses. To focus
1037 on important portions of messages, the examples in Section 10.2 and
1038 Section 10.3 do not show HTTP/HTTPS headers or the XML prologue. In
1039 addition, sections of XML not relevant to the example are replaced
1040 with comments.
1042 10.1. HTTPS Example Messages
1044 The examples in this section show a complete HTTPS message that
1045 includes the HELD request or response document.
1047 This example shows the most basic request for a LO. This uses the
1048 GET feature described by the HTTP binding.
1050 GET /location HTTP/1.1
1051 Host: lis.example.com:49152
1053 The GET request is exactly identical to a minimal POST request that
1054 includes an empty "locationRequest" element.
1056 POST /location HTTP/1.1
1057 Host: lis.example.com:49152
1058 Content-Type: application/held+xml
1059 Content-Length: 87
1061
1062
1064 Since neither of these requests includes a "locationType" element,
1065 the successful response to either of these requests may contain any
1066 type of location. The following shows a response containing a
1067 minimal PIDF-LO.
1069 HTTP/1.1 200 OK
1070 Server: Example LIS
1071 Date: Tue, 10 Jan 2006 03:42:29 GMT
1072 Expires: Tue, 10 Jan 2006 03:42:29 GMT
1073 Cache-control: private
1074 Content-Type: application/held+xml
1075 Content-Length: 594
1077
1078
1079
1081
1082
1083
1084
1085
1087 -34.407 150.88001
1088
1089
1090
1091
1092 2006-01-11T03:42:28+00:00
1093
1094 Wiremap
1095
1096
1097 2006-01-10T03:42:28+00:00
1098
1099
1100
1102 The error response to either of these requests is an error document.
1103 The following response shows an example error response.
1105 HTTP/1.1 200 OK
1106 Server: Example LIS
1107 Expires: Tue, 10 Jan 2006 03:49:20 GMT
1108 Cache-control: private
1109 Content-Type: application/held+xml
1110 Content-Length: 135
1112
1113
1117 10.2. Simple Location Request Example
1119 The location request shown below doesn't specify any location types
1120 or response time.
1122
1124 The example response to this location request contains a list of
1125 Location URIs.
1127
1128
1129 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
1130
1131 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
1132
1133
1134
1136 An error response to this location request is shown below:
1138
1142 10.3. Location Request Example for Multiple Location Types
1144 The following Location Request message includes a request for
1145 geodetic, civic and any Location URIs.
1147
1148
1149 geodetic
1150 civic
1151 locationURI
1152
1153
1155 The corresponding Location Response message includes the requested
1156 location information, including two location URIs.
1158
1159
1160 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
1161
1162 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
1163
1164
1165
1167
1168
1169
1170
1171
1175 -34.407242 150.882518
1176 30
1177
1179
1180
1183 AU
1184 NSW
1185 Wollongong
1186 Gwynneville
1187 Northfield Avenue
1188 University of Wollongong
1189 2
1190 Andrew Corporation
1191 2500
1192 39
1193 WS-183
1194 U40
1195
1196
1197
1198 false
1199 2007-05-25T12:35:02+10:00
1200
1201
1202 Wiremap
1203
1204
1205 2007-05-24T12:35:02+10:00
1206
1207
1208
1210 11. IANA Considerations
1212 This document requires several IANA registrations detailed in the
1213 following sections.
1215 11.1. URN Sub-Namespace Registration for
1216 urn:ietf:params:xml:ns:geopriv:held
1218 This section registers a new XML namespace,
1219 "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in
1220 [RFC3688].
1222 URI: urn:ietf:params:xml:ns:geopriv:held
1223 Registrant Contact: IETF, GEOPRIV working group,
1224 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
1225 XML:
1227 BEGIN
1228
1229
1231
1232
1233 HELD Messages
1234
1235
1236 Namespace for HELD Messages
1237 urn:ietf:params:xml:ns:geopriv:held
1238 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1239 with the RFC number for this specification.]
1240
See RFCXXXX
1241
1242
1243 END
1245 11.2. XML Schema Registration
1247 This section registers an XML schema as per the guidelines in
1248 [RFC3688].
1250 URI: urn:ietf:params:xml:schema:geopriv:held
1251 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1252 Mary Barnes (mary.barnes@nortel.com).
1253 Schema: The XML for this schema can be found as the entirety of
1254 Section 7 of this document.
1256 11.3. MIME Media Type Registration for 'application/held+xml'
1258 This section registers the "application/held+xml" MIME type.
1260 To: ietf-types@iana.org
1261 Subject: Registration of MIME media type application/held+xml
1262 MIME media type name: application
1263 MIME subtype name: held+xml
1264 Required parameters: (none)
1265 Optional parameters: charset
1266 Indicates the character encoding of enclosed XML. Default is
1267 UTF-8.
1269 Encoding considerations: Uses XML, which can employ 8-bit
1270 characters, depending on the character encoding used. See RFC
1271 3023 [RFC3023], section 3.2.
1272 Security considerations: This content type is designed to carry
1273 protocol data related to the location of an entity, which could
1274 include information that is considered private. Appropriate
1275 precautions should be taken to limit disclosure of this
1276 information.
1277 Interoperability considerations: This content type provides a basis
1278 for a protocol
1279 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
1280 replace XXXX with the RFC number for this specification.]
1281 Applications which use this media type: Location information
1282 providers and consumers.
1283 Additional Information: Magic Number(s): (none)
1284 File extension(s): .xml
1285 Macintosh File Type Code(s): (none)
1286 Person & email address to contact for further information: Mary
1287 Barnes
1288 Intended usage: LIMITED USE
1289 Author/Change controller: The IETF
1290 Other information: This media type is a specialization of
1291 application/xml [RFC3023], and many of the considerations
1292 described there also apply to application/held+xml.
1294 11.4. Error code Registry
1296 This document requests that the IANA create a new registry for the
1297 HELD protocol including an initial registry for error codes. The
1298 error codes are included in HELD error messages as described in
1299 Section 6.3 and defined in the schema in the 'codeType' token in the
1300 XML schema in (Section 7)
1302 The following summarizes the requested registry:
1304 Related Registry: Geopriv HELD Registries, Error codes for HELD
1305 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1306 with the RFC number for this specification.]
1307 Registration/Assignment Procedures: Following the policies outlined
1308 in [RFC5226], the IANA policy for assigning new values for the
1309 Error codes for HELD shall be Specification Required: values and
1310 their meanings must be documented in an RFC or in some other
1311 permanent and readily available reference, in sufficient detail
1312 that interoperability between independent implementations is
1313 possible.
1315 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1316 Mary Barnes (mary.barnes@nortel.com).
1318 This section pre-registers the following seven initial error codes as
1319 described above in Section 6.3:
1321 requestError: This code indicates that the request was badly formed
1322 in some fashion.
1323 xmlError: This code indicates that the XML content of the request
1324 was either badly formed or invalid.
1325 generalLisError: This code indicates that an unspecified error
1326 occurred at the LIS.
1327 locationUnknown: This code indicates that the LIS could not
1328 determine the location of the Device.
1329 unsupportedMessage: This code indicates that the request was not
1330 supported or understood by the LIS. This error code is used when
1331 a HELD request contains a document element that is not supported
1332 by the receiver.
1333 timeout: This code indicates that the LIS could not satisfy the
1334 request within the time specified in the "responseTime" parameter.
1335 cannotProvideLiType: This code indicates that the LIS was unable to
1336 provide LI of the type or types requested. This code is used when
1337 the "exact" attribute on the "locationType" parameter is set to
1338 "true".
1339 notLocatable: This code indicates that the LIS is unable to locate
1340 the Device, and that the Device MUST NOT make further attempts to
1341 retrieve LI from this LIS. This error code is used to indicate
1342 that the Device is outside the access network served by the LIS;
1343 for instance, the VPN and NAT scenarios discussed in
1344 Section 4.1.2.
1346 12. Contributors
1348 James Winterbottom, Martin Thomson and Barbara Stark are the authors
1349 of the original document, from which this WG document was derived.
1350 Their contact information is included in the Author's address
1351 section. In addition, they also contributed to the WG document,
1352 including the XML schema.
1354 13. Acknowledgements
1356 The author/contributors would like to thank the participants in the
1357 GEOPRIV WG and the following people for their constructive input and
1358 feedback on this document (in alphabetical order): Nadine Abbott,
1359 Eric Arolick, Richard Barnes (in particular the security section),
1360 Peter Blatherwick, Ben Campbell, Guy Caron, Eddy Corbett, Martin
1361 Dawson, Lisa Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings,
1362 Neil Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger
1363 Marshall, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla,
1364 Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
1365 Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf.
1367 14. Changes since last Version
1369 NOTE TO THE RFC-Editor: Please remove this section prior to
1370 publication as an RFC.
1372 Changes from WG 09 to 10 (2nd WGLC):
1374 1) Updated text for Devices and VPNs (section 4.1.1) to include
1375 servers such as HTTP and SOCKs, thus changed the text to be generic
1376 in terms of locating LIS before connecting to one of these servers,
1377 etc.
1379 2) Fixed (still buggy) HTTP examples.
1381 3) Added text explaining the whitespaces in XML schema are for
1382 readability/document format limitations and that they should be
1383 handled via parser/schema validation.
1385 4) Miscellaneous editorial nits
1387 Changes from WG 08 to 09 (Post-IETF LC: continued resolution of sec-
1388 dir and gen-art review comments, along with apps-area feedback):
1390 1) Removed heldref/heldrefs URIs, including fixing examples (which
1391 were buggy anyways).
1393 2) Clarified text for locationURI - specifying that the deref
1394 protocol must define or appropriately restrict and clarifying that
1395 requirements for deref must be met and that deref details are out of
1396 scope for this document.
1398 3) Clarified text in security section for support of both HTTP/HTTPS.
1400 4) Changed definition for Location Type to force the specification of
1401 at least one location type.
1403 Changes from WG 07 to 08 (IETF LC: sec-dir and gen-art review
1404 comments):
1406 1) Fix editorial nits: rearranging sections in 4.1 for readibility,
1407 etc.
1409 2) Added back text in Device and VPN section referencing DHCP and
1410 LLDP-MED when a VPN device serves as a LIS.
1412 3) Clarified the use of both HTTP and HTTPS.
1414 4) Defined two URIs related to 3 respectively - divided IANA
1415 registrations into sub-sections to accomodate this change. (Note:
1416 LIS Discovery will now define that URI, thus this document defines
1417 the one associatied with a Location reference).
1419 5) Clarified the description of the location URI in Protocol Overview
1420 and Protocol parameter sections. Note that these sections again
1421 reference location dereference protocol for completeness and
1422 clarification of issues that are out of scope for this base document.
1424 6) Defined new error code: notLocatable.
1426 7) Clarifications and corrections in security section.
1428 8) Clarified text for locationType, specifically removing extra text
1429 from "any" description and putting that in a separate paragraph.
1430 Also, provided an example.
1432 9) Added boundaries for "expires" parameter.
1434 10) Clarified that the HELD protocol as defined by this document does
1435 not allow for canceling location references.
1437 Changes from WG 06 to 07 (PROTO review comments):
1439 1) Fix nits: remove unused references, move requirements to
1440 Informational References section, fix long line in ABNF, fix ABNF
1441 (quotes around '?'), add schemaLocation to import namespace in XML
1442 schema.
1444 2) Remove text in Device and VPN section referencing DHCP and LLDP-
1445 MED when a VPN device serves as a LIS, per Issue 1 resolution at
1446 IETF-71. (Editorial oversight in producing version 06).
1448 Changes from WG 05 to 06 (2nd WGLC comments):
1450 1) Updated security section based on WG feedback, including
1451 condensing section 10.1.1 (Assuring the proper LIS has been
1452 contacted), restructuring sections by flattening, adding an
1453 additional step to the list that had been in the Accuracy section and
1454 removing summary section.
1456 2) Changed URI schema to "helds" to address concerns over referential
1457 integrity and for consistency with mandate of TLS for HELD.
1459 3) Editorial clarifications including fixing examples to match HELD
1460 URI definition (e.g., adding port, adding randomness to URI examples,
1461 etc.)
1463 4) Updated references removing unused references and moving
1464 requirements docs to Informational Reference section to avoid
1465 downrefs.
1467 Changes from WG 04 to 05 (WGLC comments):
1469 1) Totally replaced the security section with the details provided by
1470 Richard Barnes so that we don't need a reference to the location
1471 security document.
1473 2) Fixed error codes in schema to allow extensibility. Change the
1474 IANA registration to be "specification required".
1476 3) Cleaned up the HELD: URI description, per comments from Martin and
1477 James and partially addressing HELD-04 Issue 1. Put the definition
1478 in a separate section and clarified the applicability (to also
1479 include being a results of the discovery process) and fixed examples.
1481 4) Updated the LocationURI section to be more accurate, address
1482 HELD-04 Issue 3, and include the reference to the new HELD:URI
1483 section. Also, fixed an error in the doc in that the top level parm
1484 in the locationResponse is actually locationUriSet, which contains
1485 any number of locationURI elements and the "expires" parameter. So,
1486 Table 1 was also updated and a new section for the LocationURISet was
1487 added that includes the subsections for the "locationURI" and
1488 "expires". And, then clarified that "expires" applies to
1489 "locationURISet" and not per "locationURI".
1491 5) Editorial nits: pointed out offline by Richard (e.g., by-value ->
1492 by value, by-reference -> by reference, etc.) and onlist by James and
1493 Martin. Please refer to the diff for a complete view of editorial
1494 changes.
1496 6) Added text in HTTP binding section to disable HTTP caching
1497 (HELD-04 Issue 5 on the list).
1499 Changes from WG 03 to 04:
1501 1) Terminology: clarified in terminology section that "attribute" and
1502 "element" are used in the strict XML sense and "parameter" is used as
1503 a general protocol term Replaced term "HTTP delivery" with "HTTP
1504 transport". Still have two terms "HTTP transport" and "HTTP
1505 binding", but those are consistent with general uses of HTTP.
1507 2) Editorial changes and clarifications: per Roger Marshall's and
1508 Eric Arolick's comments and subsequent WG mailing list discussion.
1510 3) Changed normative language for describing expected and recommended
1511 LIS behaviors to be non-normative recommendations in cases where the
1512 protocol parameters were not the target of the discussion (e.g., we
1513 can't prescribe to the LIS how it determines location or what it
1514 defines to be an "accurate" location).
1516 4) Clarified responseTime attribute (section 6.1). Changed type from
1517 "decimal" to "nonNegativeInteger" in XML schema (section 7)
1519 5) Updated Table 1 in section 6 to only include top-level parameters
1520 and fixed some errors in that table (i.e., code for locationResponse)
1521 and adding PIDF-LO to the table. Added a detailed section describing
1522 PIDF-LO (section 6.6), moving some of the normative text in the
1523 Protocol Overview to this section.
1525 6) Added schema and description for locationURI to section 6.5.
1526 Added IANA registration for HELD: URI schema.
1528 7) Added IANA registry for error codes.
1530 Changes from WG 02 to 03:
1532 1) Added text to address concern over use of IP address as device
1533 identifier, per long email thread - changes to section 3 (overview)
1534 and section 4 (protocol overview).
1536 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed)
1538 3) Added extensibility to baseRequestType in the schema (an oversight
1539 from previous edits), along with fixing some other nits in schema
1540 (section 7)
1542 4) Moved discussion of Location URI from section 5.3 (Location
1543 Response) to where it rightly belonged in Section 6.5 (Location URI
1544 Parameter).
1546 5) Clarified text for "expires" parameter (6.5.1) - it's an optional
1547 parm, but required for LocationURIs
1549 6) Clarified responseTime parameter: when missing, then the LCS
1550 provides most precise LI, with the time required being implementation
1551 specific.
1553 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST
1554 implement.
1556 8) Updated references (removed unused/added new).
1558 Changes from WG 01 to 02:
1560 1) Updated Terminology to be consistent with WG agreements and other
1561 documents (e.g., LCS -> LIS and removed duplicate terms). In the
1562 end, there are no new terms defined in this document.
1564 2) Modified definition of responseTime to reflect WG consensus.
1566 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving
1567 just "civic").
1569 4) Clarified text that locationType is optional. Fixed table 1 and
1570 text in section 5.2 (locationRequest description). Text in section
1571 6.2 (description of locationType element) already defined the default
1572 to be "any".
1574 5) Simplified error responses. Separated the definition of error
1575 response type from the locationResponse type thus no need for
1576 defining an error code of "success". This simplifies the schema and
1577 processing.
1579 6) Updated schema/examples for the above.
1581 7) Updated Appendix A based on updates to requirements document,
1582 specifically changes to A.1, A.3 and adding A.10.
1584 8) Miscellaneous editorial clarifications.
1586 Changes from WG 00 to 01:
1588 1) heldResponse renamed to locationResponse.
1590 2) Changed namespace references for the PIDF-LO geoShape in the
1591 schema to match the agreed GML PIDF-LO Geometry Shape Application
1592 Schema.
1594 3) Removed "options" element - leaving optionality/extensibility to
1595 XML mechanisms.
1597 4) Changed error codes to be enumerations and not redefinitions of
1598 HTTP response codes.
1600 5) Updated schema/examples for the above and removed some remnants of
1601 the context element.
1603 6) Clarified the definition of "Location Information (LI)" to include
1604 a reference to the location (to match the XML schema and provide
1605 consistency of usage throughout the document). Added an additional
1606 statement in section 7.2 (locationType) to clarify that LCS MAY also
1607 return a Location URI.
1609 7) Modifed the definition of "Location Configuration Server (LCS)" to
1610 be consistent with the current definiton in the requirements
1611 document.
1613 8) Updated Location Response (section 6.3) to remove reference to
1614 context and discuss the used of a local identifier or unlinked
1615 pseudonym in providing privacy/security.
1617 9) Clarified that the source IP address in the request is used as the
1618 identifier for the target/device for the HELD protocol as defined in
1619 this document.
1621 10) Miscellaneous editorial clarifications.
1623 15. References
1625 15.1. Normative References
1627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1628 Requirement Levels", BCP 14, RFC 2119, March 1997.
1630 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1631 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
1633 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1634 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1635 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1637 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1639 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1640 January 2004.
1642 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
1643 Networks", BCP 84, RFC 3704, March 2004.
1645 [I-D.ietf-geopriv-pdif-lo-profile]
1646 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
1647 PIDF-LO Usage Clarification, Considerations and
1648 Recommendations", draft-ietf-geopriv-pdif-lo-profile-13
1649 (work in progress), September 2008.
1651 [W3C.REC-xmlschema-1-20041028]
1652 Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney,
1653 "XML Schema Part 1: Structures Second Edition", World Wide
1654 Web Consortium Recommendation REC-xmlschema-1-20041028,
1655 October 2004,
1656 .
1658 [W3C.REC-xmlschema-2-20041028]
1659 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
1660 Second Edition", World Wide Web Consortium
1661 Recommendation REC-xmlschema-2-20041028, October 2004,
1662 .
1664 [I-D.ietf-geopriv-lis-discovery]
1665 Thomson, M. and J. Winterbottom, "Discovering the Local
1666 Location Information Server (LIS)",
1667 draft-ietf-geopriv-lis-discovery-03 (work in progress),
1668 September 2008.
1670 15.2. Informative References
1672 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
1673 RFC 793, September 1981.
1675 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
1676 Types", RFC 3023, January 2001.
1678 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
1679 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
1681 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
1682 Configuration Protocol Option for Coordinate-based
1683 Location Configuration Information", RFC 3825, July 2004.
1685 [LLDP-MED]
1686 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
1687 Endpoint Discovery".
1689 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1690 Resource Identifier (URI): Generic Syntax", STD 66,
1691 RFC 3986, January 2005.
1693 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
1694 Registration Procedures for New URI Schemes", BCP 115,
1695 RFC 4395, February 2006.
1697 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1698 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1699 May 2008.
1701 [I-D.ietf-geopriv-l7-lcp-ps]
1702 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
1703 Location Configuration Protocol; Problem Statement and
1704 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
1705 progress), June 2008.
1707 [I-D.ietf-geopriv-lbyr-requirements]
1708 Marshall, R., "Requirements for a Location-by-Reference
1709 Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work
1710 in progress), July 2008.
1712 [I-D.ietf-sip-location-conveyance]
1713 Polk, J. and B. Rosen, "Location Conveyance for the
1714 Session Initiation Protocol",
1715 draft-ietf-sip-location-conveyance-10 (work in progress),
1716 September 2008.
1718 [I-D.winterbottom-geopriv-deref-protocol]
1719 Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
1720 Thomson, M., and M. Dawson, "An HTTPS Location
1721 Dereferencing Protocol Using HELD",
1722 draft-winterbottom-geopriv-deref-protocol-02 (work in
1723 progress), July 2008.
1725 Appendix A. HELD Compliance to IETF LCP requirements
1727 This appendix describes HELD's compliance to the requirements
1728 specified in the [I-D.ietf-geopriv-l7-lcp-ps].
1730 A.1. L7-1: Identifier Choice
1732 "The L7 LCP MUST be able to carry different identifiers or MUST
1733 define an identifier that is mandatory to implement. Regarding the
1734 latter aspect, such an identifier is only appropriate if it is from
1735 the same realm as the one for which the location information service
1736 maintains identifier to location mapping."
1738 COMPLY
1740 HELD uses the IP address of the location request message as the
1741 primary source of identity for the requesting device or target. This
1742 identity can be used with other contextual network information to
1743 provide a physical location for the Target for many network
1744 deployments. There may be network deployments where an IP address
1745 alone is insufficient to identify a Target in a network. However,
1746 any necessary identity extensions for these networks is beyond the
1747 scope of this document.
1749 A.2. L7-2: Mobility Support
1751 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
1752 broad range of mobility from devices that can only move between
1753 reboots, to devices that can change attachment points with the impact
1754 that their IP address is changed, to devices that do not change their
1755 IP address while roaming, to devices that continuously move by being
1756 attached to the same network attachment point."
1758 COMPLY
1760 Mobility support is inherently a characteristic of the access network
1761 technology and HELD is designed to be access network agnostic.
1762 Consequently HELD complies with this requirement. In addition HELD
1763 provides specific support for mobile environments by providing an
1764 optional responseTime attribute in location request messages.
1765 Wireless networks often have several different mechanisms at their
1766 disposal for position determination (e.g. Assisted GPS versus
1767 location based on serving base station identity), each providing
1768 different degrees of accuracy and taking different amounts of time to
1769 yield a result. The responseTime parameter provides the LIS with a
1770 criterion which it can use to select a location determination
1771 technique.
1773 A.3. L7-3: ASP and Access Network Provider Relationship
1775 "The design of the L7 LCP MUST NOT assume a business or trust
1776 relationship between the Application Service Provider (ASP) and the
1777 Access Network Provider. Requirements for resolving a reference to
1778 location information are not discussed in this document."
1780 COMPLY
1782 HELD describes a location acquisition protocol between a Device and a
1783 LIS. In the context of HELD, the LIS is within the Access Network.
1784 Thus, HELD is independent of the business or trust relationship
1785 between the Application Service Provider (ASP) and the Access Network
1786 Provider. Location acquisition using HELD is subject to the
1787 restrictions described in Section 9.
1789 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
1791 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1792 MUST assume that there is a trust and business relationship between
1793 the L2 and the L3 provider. The L3 provider operates the LIS and
1794 needs to obtain location information from the L2 provider since this
1795 one is closest to the end host. If the L2 and L3 provider for the
1796 same host are different entities, they cooperate for the purposes
1797 needed to determine end system locations."
1799 COMPLY
1801 HELD was specifically designed with this model in mind and readily
1802 allows itself to chaining requests between operators without a change
1803 in protocol being required. HELD is a webservices protocol which can
1804 be bound to transports other than HTTP, such as BEEP. Using a
1805 protocol such as BEEP offers the option of high request throughput
1806 over a dedicated connection between an L3 provider and an L2 provider
1807 without incurring the serial restriction imposed by HTTP. This is
1808 less easy to do with protocols that do not decouple themselves from
1809 the transport.
1811 A.5. L7-5: Legacy Device Considerations
1813 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1814 MUST consider legacy residential NAT devices and NTEs in an DSL
1815 environment that cannot be upgraded to support additional protocols,
1816 for example to pass additional information through DHCP."
1818 COMPLY
1820 HELD is an application protocol and operates on top of IP. A HELD
1821 request from a host behind a residential NAT will traverse the NAT
1822 acquiring the external address of the home router. The location
1823 provided to the host therefore will be the address of the home router
1824 in this circumstance. No changes are required to the home router in
1825 order to support this function, HELD was designed specifically to
1826 address this deployment scenario.
1828 A.6. L7-6: VPN Awareness
1830 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1831 MUST assume that at least one end of a VPN is aware of the VPN
1832 functionality. In an enterprise scenario, the enterprise side will
1833 provide the LIS used by the client and can thereby detect whether the
1834 LIS request was initiated through a VPN tunnel."
1836 COMPLY
1837 HELD does not preclude a LIS on the far end of a VPN tunnel being
1838 aware that the client request is occurring over that tunnel. It also
1839 does not preclude a client device from accessing a LIS serving the
1840 local physical network and subsequently using the location
1841 information with an application that is accessed over a VPN tunnel.
1843 A.7. L7-7: Network Access Authentication
1845 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1846 MUST NOT assume prior network access authentication."
1848 COMPLY
1850 HELD makes no assumptions about prior network access authentication.
1851 HELD strongly recommends the use of TLS with server-side certificates
1852 for communication between the end-point and the LIS. There is no
1853 requirement for the end-point to authenticate with the LIS.
1855 A.8. L7-8: Network Topology Unawareness
1857 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1858 MUST NOT assume end systems being aware of the access network
1859 topology. End systems are, however, able to determine their public
1860 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
1862 COMPLY
1864 HELD makes no assumption about the network topology. HELD doesn't
1865 require that the device know its external IP address, except where
1866 that is required for discovery of the LIS.
1868 A.9. L7-9: Discovery Mechanism
1870 "The L7 LCP MUST define a single mandatory to implement discovery
1871 mechanism."
1873 COMPLY
1875 HELD uses the discovery mechanism in
1876 [I-D.ietf-geopriv-lis-discovery].
1878 A.10. L7-10: PIDF-LO Creation
1880 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
1881 element into the element of the presence document
1882 (see RFC 4479). This ensures that the resulting PIDF-LO document,
1883 which is subsequently distributed to other entities, conforms to the
1884 rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile]
1885 COMPLY
1887 HELD protocol overview (Section 4 ) describes the requirements on the
1888 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
1889 by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile].
1891 Authors' Addresses
1893 Mary Barnes (editor)
1894 Nortel
1895 2201 Lakeside Blvd
1896 Richardson, TX
1898 Email: mary.barnes@nortel.com
1900 James Winterbottom
1901 Andrew
1902 PO Box U40
1903 Wollongong University Campus, NSW 2500
1904 AU
1906 Phone: +61 2 4221 2938
1907 Email: james.winterbottom@andrew.com
1908 URI: http://www.andrew.com/
1910 Martin Thomson
1911 Andrew
1912 PO Box U40
1913 Wollongong University Campus, NSW 2500
1914 AU
1916 Phone: +61 2 4221 2915
1917 Email: martin.thomson@andrew.com
1918 URI: http://www.andrew.com/
1919 Barbara Stark
1920 BellSouth
1921 Room 7A43
1922 725 W Peachtree St.
1923 Atlanta, GA 30308
1924 US
1926 Email: barbara.stark@att.com
1928 Full Copyright Statement
1930 Copyright (C) The IETF Trust (2008).
1932 This document is subject to the rights, licenses and restrictions
1933 contained in BCP 78, and except as set forth therein, the authors
1934 retain all their rights.
1936 This document and the information contained herein are provided on an
1937 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1938 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1939 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1940 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1941 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1942 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1944 Intellectual Property
1946 The IETF takes no position regarding the validity or scope of any
1947 Intellectual Property Rights or other rights that might be claimed to
1948 pertain to the implementation or use of the technology described in
1949 this document or the extent to which any license under such rights
1950 might or might not be available; nor does it represent that it has
1951 made any independent effort to identify any such rights. Information
1952 on the procedures with respect to rights in RFC documents can be
1953 found in BCP 78 and BCP 79.
1955 Copies of IPR disclosures made to the IETF Secretariat and any
1956 assurances of licenses to be made available, or the result of an
1957 attempt made to obtain a general license or permission for the use of
1958 such proprietary rights by implementers or users of this
1959 specification can be obtained from the IETF on-line IPR repository at
1960 http://www.ietf.org/ipr.
1962 The IETF invites any interested party to bring to its attention any
1963 copyrights, patents or patent applications, or other proprietary
1964 rights that may cover technology that may be required to implement
1965 this standard. Please address the information to the IETF at
1966 ietf-ipr@ietf.org.