idnits 2.17.1
draft-ietf-geopriv-http-location-delivery-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 17.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 1874.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1885.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1892.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1898.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (April 17, 2008) is 5852 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110)
== Outdated reference: A later version (-14) exists of
draft-ietf-geopriv-pdif-lo-profile-11
== Outdated reference: A later version (-15) exists of
draft-ietf-geopriv-lis-discovery-00
-- Obsolete informational reference (is this intentional?): RFC 793
(Obsoleted by RFC 9293)
-- Obsolete informational reference (is this intentional?): RFC 3023
(Obsoleted by RFC 7303)
-- Obsolete informational reference (is this intentional?): RFC 4395
(Obsoleted by RFC 7595)
== Outdated reference: A later version (-10) exists of
draft-ietf-geopriv-l7-lcp-ps-07
== Outdated reference: A later version (-09) exists of
draft-ietf-geopriv-lbyr-requirements-02
== Outdated reference: A later version (-13) exists of
draft-ietf-sip-location-conveyance-10
== Outdated reference: A later version (-05) exists of
draft-winterbottom-geopriv-deref-protocol-00
Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV WG M. Barnes, Ed.
3 Internet-Draft Nortel
4 Intended status: Standards Track
5 Expires: October 19, 2008
7 April 17, 2008
9 HTTP Enabled Location Delivery (HELD)
10 draft-ietf-geopriv-http-location-delivery-07.txt
12 Status of this Memo
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
22 Drafts.
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on October 19, 2008.
37 Abstract
39 A Layer 7 Location Configuration Protocol (L7 LCP) is described that
40 is used for retrieving location information from a server within an
41 access network. The protocol includes options for retrieving
42 location information in two forms: by value and by reference. The
43 protocol is an extensible application-layer protocol that is
44 independent of session-layer. This document describes the use of
45 Hypertext Transfer Protocol (HTTP) as a transport for the protocol.
47 Table of Contents
49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
50 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
51 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5
52 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
53 4.1. Location by Value . . . . . . . . . . . . . . . . . . . . 7
54 4.2. Location by Reference . . . . . . . . . . . . . . . . . . 7
55 4.3. Device Identifiers, NAT and VPNs . . . . . . . . . . . . . 7
56 4.3.1. Devices and VPNs . . . . . . . . . . . . . . . . . . . 8
57 4.3.2. LIS Handling of NATs and VPNs . . . . . . . . . . . . 8
58 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9
59 5.1. Delivery Protocol . . . . . . . . . . . . . . . . . . . . 9
60 5.2. Location Request . . . . . . . . . . . . . . . . . . . . . 10
61 5.3. Location Response . . . . . . . . . . . . . . . . . . . . 10
62 5.4. Indicating Errors . . . . . . . . . . . . . . . . . . . . 10
63 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10
64 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
65 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
66 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 12
67 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
68 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 13
69 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 14
70 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 14
71 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 14
72 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 14
73 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
74 8. HELDS: URI Definition . . . . . . . . . . . . . . . . . . . . 18
75 9. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19
76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
77 10.1. Assuring that the proper LIS has been contacted . . . . . 21
78 10.2. Protecting responses from modification . . . . . . . . . . 21
79 10.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 21
80 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
81 11.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 23
82 11.2. Simple Location Request Example . . . . . . . . . . . . . 25
83 11.3. Location Request Example for Multiple Location Types . . . 26
84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
85 12.1. URN Sub-Namespace Registration for
86 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 27
87 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 28
88 12.3. MIME Media Type Registration for 'application/held+xml' . 28
89 12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 29
90 12.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 30
91 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
92 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
93 15. Changes since last Version . . . . . . . . . . . . . . . . . . 31
94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
95 16.1. Normative References . . . . . . . . . . . . . . . . . . . 35
96 16.2. Informative References . . . . . . . . . . . . . . . . . . 36
97 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 37
98 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 38
99 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 38
100 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 38
101 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 39
102 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 39
103 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 40
104 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 40
105 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 40
106 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 40
107 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 41
108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
109 Intellectual Property and Copyright Statements . . . . . . . . . . 43
111 1. Introduction
113 The location of a Device is information that is useful for a number
114 of applications. The L7 Location Configuration Protocol (LCP)
115 problem statement and requirements document
116 [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which the
117 Device might rely on its access network to provide location
118 information. The LIS service applies to access networks employing
119 both wired technology (e.g. DSL, Cable) and wireless technology
120 (e.g. WiMAX) with varying degrees of Device mobility. This document
121 describes a protocol that can be used to acquire Location Information
122 (LI) from a Location Information Server (LIS) within an access
123 network.
125 This specification identifies two types of location information that
126 may be retrieved from the LIS. Location may be retrieved from the
127 LIS by value, that is, the Device may acquire a literal location
128 object describing the location of the Device. The Device may also
129 request that the LIS provide a location reference in the form of a
130 location URI or set of location URIs, allowing the Device to
131 distribute its LI by reference. Both of these methods can be
132 provided concurrently from the same LIS to accommodate application
133 requirements for different types of location information.
135 This specification defines an extensible XML-based protocol that
136 enables the retrieval of LI from a LIS by a Device. This protocol
137 can be bound to any session-layer protocol, particularly those
138 capable of MIME transport. This document describes the use of
139 Hypertext Transfer Protocol (HTTP) as a transport for the protocol.
141 2. Conventions & Terminology
143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
145 document are to be interpreted as described in [RFC2119].
147 This document uses the terms (and their acronym forms) Access
148 Provider (AP), Location Information (LI), Location Object (LO),
149 Device, Target, Location Generator (LG), Location Recipient (LR),
150 Rule Maker (RM) and Rule Holder (RH) as defined in RFC 3693, GEOPRIV
151 Requirements [RFC3693] . The terms Location Information Server
152 (LIS), Access Network, Access Provider (AP) and Access Network
153 Provider are used in the same context as defined in the L7 LCP
154 Problem statement and Requirements document
155 [I-D.ietf-geopriv-l7-lcp-ps]. The usage of the terms, Civic
156 Location/Address and Geodetic Location follows the usage in many of
157 the referenced documents.
159 In describing the protocol, the terms "attribute" and "element" are
160 used according to their context in XML. The term "parameter" is used
161 in a more general protocol context and can refer to either an XML
162 "attribute" or "element".
164 3. Overview and Scope
166 This document describes an interface between a Device and a Location
167 Information Server (LIS). This document assumes that the LIS is
168 present within the same administrative domain as the Device (e.g.,
169 the access network). An Access Provider (AP) operates the LIS so
170 that Devices (and Targets) can retrieve their LI. The LIS exists
171 because not all Devices are capable of determining LI, and because,
172 even if a device is able to determine its own LI, it may be more
173 efficient with assistance. This document does not specify how LI is
174 determined.
176 This document is based on the attribution of the LI to a Device and
177 not specifically a person (end user) or Target, based on the premise
178 that location determination technologies are generally designed to
179 locate a device and not a person. It is expected that, for most
180 applications, LI for the device can be used as an adequate substitute
181 for the end user's LI. Since revealing the location of the device
182 almost invariably reveals some information about the location of the
183 user of the device, the same level of privacy protection demanded by
184 a user is required for the device. This approach may require either
185 some additional assurances about the link between device and target,
186 or an acceptance of the limitation that unless the device requires
187 active user authentication, there is no guarantee that any particular
188 individual is using the device at that instant.
190 The following diagram shows the logical configuration of some of the
191 functional elements identified in [RFC3693] and the LIS defined in
192 [I-D.ietf-geopriv-l7-lcp-ps] and where this protocol applies, with
193 the Rule Maker and Target represented by the role of the Device.
194 Note that only the interfaces relevant to the Device are identified
195 in the diagram.
197 +---------------------------------------------+
198 | Access Network Provider |
199 | |
200 | +--------------------------------------+ |
201 | | Location Information Server | |
202 | | | |
203 | | | |
204 | | | |
205 | | | |
206 | +------|-------------------------------+ |
207 +----------|----------------------------------+
208 |
209 |
210 HELD
211 |
212 Rule Maker - _ +-----------+ +-----------+
213 o - - | Device | | Location |
214
638
646
647
648 This document (RFC xxxx) defines HELD messages.
649
651
652
654
657
658
659
660
661
662
664
665
667
668
669
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
688
689
690
691
692
693
694
695
696
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
715
716
717
719
720
721
722
723
724
726
727
728
729
731
732
733
734
735
737
739
740
741
742
744
746
747
748
749
750
751
754
756
758
759
760
762
765
767
768
769
770
771
774
776
777
778
779
781
784
786 8. HELDS: URI Definition
788 This section defines the schema for a helds: URI. This URI schema is
789 one possible URI scheme for the "locationURI" element, described in
790 Section 6.5.1, in a HELD "locationResponse " message. In this case,
791 the helds: URI indicates to the Device where to obtain the actual
792 location information for a Target. In addition, the helds: URI can
793 be the result of the LIS discovery process
794 [I-D.ietf-geopriv-lis-discovery] and indicates to the Device the LIS
795 from which LI should be requested.
797 The helds: URI is defined using a subset of the URI schema specified
798 in Appendix A. of RFC3986 [RFC3986] and the associated URI
799 Guidelines [RFC4395] per the following ABNF syntax:
801 HELD-URI = "helds://" host [ ":" port ] [ path-absolute ] [ "?" query ]
802 The following summarizes the primary elements comprising the HELD-
803 URI:
805 host: As defined in RFC3986 [RFC3986]
806 port: As defined in RFC3986 [RFC3986]. There is no unique port
807 associated with location URIs.
808 path-absolute As defined in RFC3986 [RFC3986].
809 query: As defined in RFC3986 [RFC3986]. This allows for additional
810 information associated with the URIs such as a unique anonymous
811 identifier for the Device associated with the target location.
813 The helds: URI is not intended to be human-readable text, therefore
814 it is encoded entirely in US-ASCII. The following are examples of
815 helds: URIs:
817 helds://ls.example.com:49152/thisLocation?token=xyz987
818 helds://ls.example.com:5432/THISLOCATION?foobar=abc123
819 helds://ls.example.com:5432/THISlocation?foobar=ABC123
820 helds://ls.example.com:9876/civic
822 Other than the "host" portion, URIs are case sensitive and exact
823 equivalency is required for HELD-URI comparisons. For example, in
824 the above examples, although similar in information, the 2nd and 3rd
825 URIs are not considered equivalent.
827 In the case where the helds: URI is contained in a "locationURI"
828 element in a HELD locationResponse message, it is important to note
829 that the URI is only valid for the length of time indicated by the
830 "expires" attribute.
832 9. HTTP Binding
834 This section describes the use of HTTP [RFC2616] as a transport
835 mechanism for this protocol, which all conforming implementations
836 MUST support.
838 The request is carried in the body of an HTTP POST request. The MIME
839 type of both request and response bodies should be
840 "application/held+xml". This should be reflected in the HTTP
841 Content-Type and Accept header fields.
843 The LIS populates the HTTP headers so that they are consistent with
844 the contents of the message. In particular, the cache control header
845 SHOULD be set to disable the HTTP caching of any PIDF-LO document or
846 Location URIs. Otherwise, there is the risk of stale locations
847 and/or the unauthorized disclosure of the LI. This also allows the
848 LIS to control any caching with the "expires" parameter. The HTTP
849 status code MUST indicate a 2xx series response for all HELD
850 locationResponse and error messages.
852 The use of HTTP also includes a default behaviour, which is triggered
853 by a GET request, or a POST with no request body. If either of these
854 queries are received, the LIS MUST attempt to provide either a
855 PIDF-LO document or a Location URI, as if the request was a location
856 request.
858 The implementation of HTTP as a transport mechanism MUST implement
859 TLS as described in [RFC2818]. TLS provides message integrity and
860 privacy between Device and LIS. The LIS MUST use the server
861 authentication method described in [RFC2818]; the Device MUST fail a
862 request if server authentication fails, except in the event of an
863 emergency.
865 10. Security Considerations
867 HELD is a location acquisition protocol whereby the a client requests
868 its location from a LIS. Specific requirements and security
869 considerations for location acquisition protocols are provided in
870 [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security
871 considerations applicable to the use of Location URIs and by
872 reference provision of LI is included in
873 [I-D.ietf-geopriv-lbyr-requirements].
875 By using the HELD protocol, the client and the LIS expose themselves
876 to two types of risk:
878 Accuracy: Client receives incorrect location information
879 Privacy: An unauthorized entity receives location information
881 The provision of an accurate and privacy/confidentiality protected
882 location to the requestor depends on the success of five steps:
884 1. The client must determine the proper LIS.
885 2. The client must connect to the proper LIS.
886 3. The LIS must be able to identify the device by its identifier
887 (IP Address).
888 4. The LIS must be able to return the desired location.
889 5. HELD messages must be transmitted unmodified between the LIS
890 and the client.
892 Of these, only the second, third and the fifth are within the scope
893 of this document. The first step is based on either manual
894 configuration or on the LIS discovery defined in
895 [I-D.ietf-geopriv-lis-discovery], in which appropriate security
896 considerations are already discussed. The fourth step is dependent
897 on the specific positioning capabilities of the LIS, and is thus
898 outside the scope of this document.
900 10.1. Assuring that the proper LIS has been contacted
902 This document assumes that the LIS to be contacted is identified
903 either by an IP address or a domain name, as is the case for a LIS
904 discovered as described in LIS Discovery
905 [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is
906 conducted using TLS [RFC4346], the LIS can authenticate its identity,
907 either as a domain name or as an IP address, to the client by
908 presenting a certificate containing that identifier as a
909 subjectAltName (i.e., as an iPAddress or dNSName, respectively). In
910 the case of the HTTP binding described above, this is exactly the
911 authentication described by TLS [RFC2818]. Any binding of HELD MUST
912 be capable of being transacted over TLS so that the client can
913 request the above authentication, and a LIS implementation for a
914 binding MUST include this feature. Note that in order for the
915 presented certificate to be valid at the client, the client must be
916 able to validate the certificate. In particular, the validation path
917 of the certificate must end in one of the client's trust anchors,
918 even if that trust anchor is the LIS certificate itself.
920 10.2. Protecting responses from modification
922 In order to prevent that response from being modified en route,
923 messages must be transmitted over an integrity-protected channel.
924 When the transaction is being conducted over TLS (a required feature
925 per Section 10.1), the channel will be integrity protected by
926 appropriate ciphersuites. When TLS is not used, this protection will
927 vary depending on the binding; in most cases, without protection from
928 TLS, the response will not be protected from modification en route.
930 10.3. Privacy and Confidentiality
932 Location information returned by the LIS must be protected from
933 access by unauthorized parties, whether those parties request the
934 location from the LIS or intercept it en route. As in section
935 Section 10.2, transactions conducted over TLS with appropriate
936 ciphersuites are protected from access by unauthorized parties en
937 route. Conversely, in most cases, when not conducted over TLS, the
938 response will be accessible while en route from the LIS to the
939 requestor.
941 Because HELD is an LCP and identifies clients and targets by IP
942 addresses, a requestor is authorized to access location for an IP
943 address only if it is the holder of that IP address. The LIS MUST
944 verify that the client is the target of the returned location, i.e.,
945 the LIS MUST NOT provide location to other entities than the target.
946 Note that this is a necessary, but not sufficient criterion for
947 authorization. A LIS MAY deny requests according to any local
948 policy.
950 A prerequisite for meeting this requirement is that the LIS must have
951 some assurance of the identity of the client. Since the target of
952 the returned location is identified by an IP address, simply sending
953 the response to this IP address will provide sufficient assurance in
954 many cases. This is the default mechanism in HELD for assuring that
955 location is given only to authorized clients; LIS implementations
956 MUST support a mode of operation in which this is the only client
957 authentication.
959 Using IP return routability as an authenticator means that location
960 information is vulnerable to exposure through IP address spoofing
961 attacks. A temporary spoofing of IP address could mean that a device
962 could request a Location Object or Location URI that would result in
963 another Device's location. In addition, in cases where a Device
964 drops off the network for various reasons, the re-use of the Device's
965 IP address could result in another Device receiving the original
966 Device's location rather than its own location. One or more of the
967 following approaches are RECOMMENDED to limit these exposures:
969 o Location URIs SHOULD have a limited lifetime, as reflected by the
970 value for the expires element in Section 6.5.2.
971 o The network SHOULD have mechanisms that protect against IP address
972 spoofing, such as those defined in [RFC3704].
973 o The LIS and network SHOULD be configured so that the LIS is made
974 aware of Device movement within the network and addressing
975 changes. If the LIS detects a change in the network that results
976 in it no longer being able to determine the location of the
977 Device, then all location URIs for that Device SHOULD be
978 invalidated.
980 The above measures are dependent on network configuration, which
981 SHOULD be considered. For instance, in a fixed internet access,
982 providers may be able to restrict the allocation of IP addresses to a
983 single physical line, ensuring that spoofing is not possible; in such
984 an environment, other measures may not be necessary.
986 When there are further mechanisms available to authenticate ownership
987 of the IP address, the LIS SHOULD use them to authenticate that the
988 client is the owner of the target IP address. For example, in a TLS
989 transaction, the client could present a certificate with a public key
990 bound to an IPv6 Cryptographically Generated Address, and the LIS
991 could verify this binding.
993 11. Examples
995 The following sections provide basic HTTP examples, a simple location
996 request example and a location request for multiple location types
997 example along with the relevant location responses. To focus on
998 important portions of messages, the examples in Section 11.2 and
999 Section 11.3 do not show HTTP headers or the XML prologue. In
1000 addition, sections of XML not relevant to the example are replaced
1001 with comments.
1003 11.1. HTTP Example Messages
1005 The examples in this section show a complete HTTP message that
1006 includes the HELD request or response document.
1008 This example shows the most basic request for a LO. This uses the
1009 GET feature described by the HTTP binding. This example assumes that
1010 the LIS service exists at the URL "https://lis.example.com/location".
1012 GET /location HTTP/1.1
1013 Host: lis.example.com
1014 Accept:application/held+xml,
1015 application/xml;q=0.8,
1016 text/xml;q=0.7
1017 Accept-Charset: UTF-8,*
1019 The GET request is exactly identical to a minimal POST request that
1020 includes an empty "locationRequest" element.
1022 POST /location HTTP/1.1
1023 Host: lis.example.com
1024 Accept: application/held+xml,
1025 application/xml;q=0.8,
1026 text/xml;q=0.7
1027 Accept-Charset: UTF-8,*
1028 Content-Type: application/held+xml
1029 Content-Length: 87
1031
1032
1034 Since neither of these requests includes a "locationType" element,
1035 the successful response to either of these requests may contain any
1036 type of location. The following shows a response containing a
1037 minimal PIDF-LO.
1039 HTTP/1.x 200 OK
1040 Server: Example LIS
1041 Date: Tue, 10 Jan 2006 03:42:29 GMT
1042 Expires: Tue, 10 Jan 2006 03:42:29 GMT
1043 Cache-control: private
1044 Content-Type: application/held+xml
1045 Content-Length: 594
1047
1048
1049
1051
1052
1053
1054
1055
1057 -34.407 150.88001
1058
1059
1060
1061
1062 2006-01-11T03:42:28+00:00
1063
1064 Wiremap
1065
1066
1067 2006-01-10T03:42:28+00:00
1068
1069
1070
1072 The error response to either of these requests is an error document.
1073 The following response shows an example error response.
1075 HTTP/1.x 200 OK
1076 Server: Example LIS
1077 Expires: Tue, 10 Jan 2006 03:49:20 GMT
1078 Cache-control: private
1079 Content-Type: application/held+xml
1080 Content-Length: 135
1082
1083
1087 11.2. Simple Location Request Example
1089 The location request shown below doesn't specify any location types
1090 or response time.
1092
1094 The example response to this location request contains a list of
1095 Location URIs.
1097
1098
1099 helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
1100
1101 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
1102
1103
1104
1106 An error response to this location request is shown below:
1108
1112 11.3. Location Request Example for Multiple Location Types
1114 The following Location Request message includes a request for
1115 geodetic, civic and any Location URIs.
1117
1118
1119 geodetic
1120 civic
1121 locationURI
1122
1123
1125 The corresponding Location Response message includes the requested
1126 location information, including two location URIs.
1128
1129
1130 helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
1131
1132 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
1133
1134
1135
1137
1138
1139
1140
1141
1145 -34.407242 150.882518
1146 30
1147
1149
1150
1153 AU
1154 NSW
1155 Wollongong
1156 Gwynneville
1157 Northfield Avenue
1158 University of Wollongong
1159 2
1160 Andrew Corporation
1161 2500
1162 39
1163 WS-183
1164 U40
1165
1166
1167
1168 false
1169 2007-05-25T12:35:02+10:00
1170
1171
1172 Wiremap
1173
1174
1175 2007-05-24T12:35:02+10:00
1176
1177
1178
1180 12. IANA Considerations
1182 This document requires several IANA registrations detailed in the
1183 following sections.
1185 12.1. URN Sub-Namespace Registration for
1186 urn:ietf:params:xml:ns:geopriv:held
1188 This section registers a new XML namespace,
1189 "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in
1190 [RFC3688].
1192 URI: urn:ietf:params:xml:ns:geopriv:held
1193 Registrant Contact: IETF, GEOPRIV working group,
1194 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
1195 XML:
1197 BEGIN
1198
1199
1201
1202
1203 HELD Messages
1204
1205
1206 Namespace for HELD Messages
1207 urn:ietf:params:xml:ns:geopriv:held
1208 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1209 with the RFC number for this specification.]
1210
See RFCXXXX
1211
1212
1213 END
1215 12.2. XML Schema Registration
1217 This section registers an XML schema as per the guidelines in
1218 [RFC3688].
1220 URI: urn:ietf:params:xml:schema:geopriv:held
1221 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1222 Mary Barnes (mary.barnes@nortel.com).
1223 Schema: The XML for this schema can be found as the entirety of
1224 Section 7 of this document.
1226 12.3. MIME Media Type Registration for 'application/held+xml'
1228 This section registers the "application/held+xml" MIME type.
1230 To: ietf-types@iana.org
1231 Subject: Registration of MIME media type application/held+xml
1232 MIME media type name: application
1233 MIME subtype name: held+xml
1234 Required parameters: (none)
1235 Optional parameters: charset
1236 Indicates the character encoding of enclosed XML. Default is
1237 UTF-8.
1239 Encoding considerations: Uses XML, which can employ 8-bit
1240 characters, depending on the character encoding used. See RFC
1241 3023 [RFC3023], section 3.2.
1242 Security considerations: This content type is designed to carry
1243 protocol data related to the location of an entity, which could
1244 include information that is considered private. Appropriate
1245 precautions should be taken to limit disclosure of this
1246 information.
1247 Interoperability considerations: This content type provides a basis
1248 for a protocol
1249 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
1250 replace XXXX with the RFC number for this specification.]
1251 Applications which use this media type: Location information
1252 providers and consumers.
1253 Additional Information: Magic Number(s): (none)
1254 File extension(s): .xml
1255 Macintosh File Type Code(s): (none)
1256 Person & email address to contact for further information: Mary
1257 Barnes
1258 Intended usage: LIMITED USE
1259 Author/Change controller: The IETF
1260 Other information: This media type is a specialization of
1261 application/xml [RFC3023], and many of the considerations
1262 described there also apply to application/held+xml.
1264 12.4. Error code Registry
1266 This document requests that the IANA create a new registry for the
1267 HELD protocol including an initial registry for error codes. The
1268 error codes are included in HELD error messages as described in
1269 Section 6.3 and defined in the schema in the 'codeType' token in the
1270 XML schema in (Section 7)
1272 The following summarizes the requested registry:
1274 Related Registry: Geopriv HELD Registries, Error codes for HELD
1275 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1276 with the RFC number for this specification.]
1277 Registration/Assignment Procedures: Following the policies outlined
1278 in [I-D.narten-iana-considerations-rfc2434bis], the IANA policy
1279 for assigning new values for the Error codes for HELD shall be
1280 Specification Required: values and their meanings must be
1281 documented in an RFC or in some other permanent and readily
1282 available reference, in sufficient detail that interoperability
1283 between independent implementations is possible.
1285 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1286 Mary Barnes (mary.barnes@nortel.com).
1288 This section pre-registers the following seven initial error codes as
1289 described above in Section 6.3:
1291 requestError: This code indicates that the request was badly formed
1292 in some fashion.
1293 xmlError: This code indicates that the XML content of the request
1294 was either badly formed or invalid.
1295 generalLisError: This code indicates that an unspecified error
1296 occurred at the LIS.
1297 locationUnknown: This code indicates that the LIS could not
1298 determine the location of the Device.
1299 unsupportedMessage: This code indicates that the request was not
1300 supported or understood by the LIS.
1301 timeout: This code indicates that the LIS could not satisfy the
1302 request within the time specified in the "responseTime" parameter.
1303 cannotProvideLiType: This code indicates that the LIS was unable to
1304 provide LI of the type or types requested. This code is used when
1305 the "exact" attribute on the "locationType" parameter is set to
1306 "true".
1308 12.5. URI Registration
1310 The following summarizes the information necessary to register the
1311 helds: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the
1312 RFC number for this specification in the following list.]
1314 URI Scheme Name: helds
1315 Status: permanent
1316 URI Scheme syntax: See section
1317 URI Scheme Semantics: The helds: URI is intended to be used as a
1318 reference to a location object or a location information server.
1319 Further detail is provided in Section 8 of RFC XXXX.
1320 Encoding Considerations: The HELDS: URI is not intended to be human-
1321 readable text, therefore they are encoded entirely in US-ASCII.
1322 Applications/protocols that use this URI scheme: The HELD protocol
1323 described in RFC XXXX, the GEOPRIV Location De-reference Protocol
1324 [I-D.winterbottom-geopriv-deref-protocol] and GEOPRIV Location
1325 Information Server Discovery [I-D.ietf-geopriv-lis-discovery].
1326 Interoperability considerations: This URI may be used as a parameter
1327 for the HELD protocol in the locationResponse message. This URI
1328 is also used as an input parameter for the GEOPRIV Location De-
1329 reference Protocol [I-D.winterbottom-geopriv-deref-protocol].
1330 This URI may also be a result of the GEOPRIV Location Information
1331 Server Discovery [I-D.ietf-geopriv-lis-discovery] and thus used as
1332 the target for the HELD protocol request messages. Refer to
1333 Section 8 in RFC XXXX for further detail and a particular example
1334 on the lack of permanence of a specific HELDS: URI and thus the
1335 importance of using these URIs only within the specific contexts
1336 outlined in the references.
1337 Security considerations: Section 10 in RFC XXXX addresses the
1338 necessary security associated with the transport of location
1339 information between a Device and the LIS to ensure the privacy and
1340 integrity of the helds: URI. Section 6.5.1 in RFC XXXX also
1341 recommends that the URI be allocated such that it does not reveal
1342 any detail at all about the content of the PIDF-LO that it may
1343 indirectly reference.
1344 Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
1345 Barnes (mary.barnes@nortel.com).
1346 Author/Change controller: This scheme is registered under the IETF
1347 tree. As such, IETF maintains change control.
1348 References: RFC XXXX, GEOPRIV Location De-reference Protocol
1349 [I-D.winterbottom-geopriv-deref-protocol], GEOPRIV Location
1350 Information Server Discovery [I-D.ietf-geopriv-lis-discovery]
1352 13. Contributors
1354 James Winterbottom, Martin Thomson and Barbara Stark are the authors
1355 of the original document, from which this WG document was derived.
1356 Their contact information is included in the Author's address
1357 section. In addition, they also contributed to the WG document,
1358 including the XML schema.
1360 14. Acknowledgements
1362 The author/contributors would like to thank the participants in the
1363 GEOPRIV WG and the following people for their constructive input and
1364 feedback on this document (in alphabetical order): Nadine Abbott,
1365 Eric Arolick, Richard Barnes (in particular the security section),
1366 Peter Blatherwick, Guy Caron, Martin Dawson, Lisa Dusseault, Jerome
1367 Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc
1368 Linsner, Patti McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed,
1369 Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
1370 Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf.
1372 15. Changes since last Version
1374 NOTE TO THE RFC-Editor: Please remove this section prior to
1375 publication as an RFC.
1377 Changes from WG 06 to 07 (PROTO review comments):
1379 1) Fix nits: remove unused references, move requirements to
1380 Informational References section, fix long line in ABNF, fix ABNF
1381 (quotes around '?'), add schemaLocation to import namespace in XML
1382 schema.
1384 2) Remove text in Device and VPN section referencing DHCP and LLDP-
1385 MED when a VPN device serves as a LIS, per Issue 1 resolution at
1386 IETF-71. (Editorial oversight in producing version 06).
1388 Changes from WG 05 to 06 (2nd WGLC comments):
1390 1) Updated security section based on WG feedback, including
1391 condensing section 10.1.1 (Assuring the proper LIS has been
1392 contacted), restructuring sections by flattening, adding an
1393 additional step to the list that had been in the Accuracy section and
1394 removing summary section.
1396 2) Changed URI schema to "helds" to address concerns over referential
1397 integrity and for consistency with mandate of TLS for HELD.
1399 3) Editorial clarifications including fixing examples to match HELD
1400 URI definition (e.g., adding port, adding randomness to URI examples,
1401 etc.)
1403 4) Updated references removing unused references and moving
1404 requirements docs to Informational Reference section to avoid
1405 downrefs.
1407 Changes from WG 04 to 05 (WGLC comments):
1409 1) Totally replaced the security section with the details provided by
1410 Richard Barnes so that we don't need a reference to the location
1411 security document.
1413 2) Fixed error codes in schema to allow extensibility. Change the
1414 IANA registration to be "specification required".
1416 3) Cleaned up the HELD: URI description, per comments from Martin and
1417 James and partially addressing HELD-04 Issue 1. Put the definition
1418 in a separate section and clarified the applicability (to also
1419 include being a results of the discovery process) and fixed examples.
1421 4) Updated the LocationURI section to be more accurate, address
1422 HELD-04 Issue 3, and include the reference to the new HELD:URI
1423 section. Also, fixed an error in the doc in that the top level parm
1424 in the locationResponse is actually locationUriSet, which contains
1425 any number of locationURI elements and the "expires" parameter. So,
1426 Table 1 was also updated and a new section for the LocationURISet was
1427 added that includes the subsections for the "locationURI" and
1428 "expires". And, then clarified that "expires" applies to
1429 "locationURISet" and not per "locationURI".
1431 5) Editorial nits: pointed out offline by Richard (e.g., by-value ->
1432 by value, by-reference -> by reference, etc.) and onlist by James and
1433 Martin. Please refer to the diff for a complete view of editorial
1434 changes.
1436 6) Added text in HTTP binding section to disable HTTP caching
1437 (HELD-04 Issue 5 on the list).
1439 Changes from WG 03 to 04:
1441 1) Terminology: clarified in terminology section that "attribute" and
1442 "element" are used in the strict XML sense and "parameter" is used as
1443 a general protocol term Replaced term "HTTP delivery" with "HTTP
1444 transport". Still have two terms "HTTP transport" and "HTTP
1445 binding", but those are consistent with general uses of HTTP.
1447 2) Editorial changes and clarifications: per Roger Marshall's and
1448 Eric Arolick's comments and subsequent WG mailing list discussion.
1450 3) Changed normative language for describing expected and recommended
1451 LIS behaviors to be non-normative recommendations in cases where the
1452 protocol parameters were not the target of the discussion (e.g., we
1453 can't prescribe to the LIS how it determines location or what it
1454 defines to be an "accurate" location).
1456 4) Clarified responseTime attribute (section 6.1). Changed type from
1457 "decimal" to "nonNegativeInteger" in XML schema (section 7)
1459 5) Updated Table 1 in section 6 to only include top-level parameters
1460 and fixed some errors in that table (i.e., code for locationResponse)
1461 and adding PIDF-LO to the table. Added a detailed section describing
1462 PIDF-LO (section 6.6), moving some of the normative text in the
1463 Protocol Overview to this section.
1465 6) Added schema and description for locationURI to section 6.5.
1466 Added IANA registration for HELD: URI schema.
1468 7) Added IANA registry for error codes.
1470 Changes from WG 02 to 03:
1472 1) Added text to address concern over use of IP address as device
1473 identifier, per long email thread - changes to section 3 (overview)
1474 and section 4 (protocol overview).
1476 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed)
1478 3) Added extensibility to baseRequestType in the schema (an oversight
1479 from previous edits), along with fixing some other nits in schema
1480 (section 7)
1482 4) Moved discussion of Location URI from section 5.3 (Location
1483 Response) to where it rightly belonged in Section 6.5 (Location URI
1484 Parameter).
1486 5) Clarified text for "expires" parameter (6.5.1) - it's an optional
1487 parm, but required for LocationURIs
1489 6) Clarified responseTime parameter: when missing, then the LCS
1490 provides most precise LI, with the time required being implementation
1491 specific.
1493 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST
1494 implement.
1496 8) Updated references (removed unused/added new).
1498 Changes from WG 01 to 02:
1500 1) Updated Terminology to be consistent with WG agreements and other
1501 documents (e.g., LCS -> LIS and removed duplicate terms). In the
1502 end, there are no new terms defined in this document.
1504 2) Modified definition of responseTime to reflect WG consensus.
1506 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving
1507 just "civic").
1509 4) Clarified text that locationType is optional. Fixed table 1 and
1510 text in section 5.2 (locationRequest description). Text in section
1511 6.2 (description of locationType element) already defined the default
1512 to be "any".
1514 5) Simplified error responses. Separated the definition of error
1515 response type from the locationResponse type thus no need for
1516 defining an error code of "success". This simplifies the schema and
1517 processing.
1519 6) Updated schema/examples for the above.
1521 7) Updated Appendix A based on updates to requirements document,
1522 specifically changes to A.1, A.3 and adding A.10.
1524 8) Miscellaneous editorial clarifications.
1526 Changes from WG 00 to 01:
1528 1) heldResponse renamed to locationResponse.
1530 2) Changed namespace references for the PIDF-LO geoShape in the
1531 schema to match the agreed GML PIDF-LO Geometry Shape Application
1532 Schema.
1534 3) Removed "options" element - leaving optionality/extensibility to
1535 XML mechanisms.
1537 4) Changed error codes to be enumerations and not redefinitions of
1538 HTTP response codes.
1540 5) Updated schema/examples for the above and removed some remnants of
1541 the context element.
1543 6) Clarified the definition of "Location Information (LI)" to include
1544 a reference to the location (to match the XML schema and provide
1545 consistency of usage throughout the document). Added an additional
1546 statement in section 7.2 (locationType) to clarify that LCS MAY also
1547 return a Location URI.
1549 7) Modifed the definition of "Location Configuration Server (LCS)" to
1550 be consistent with the current definiton in the requirements
1551 document.
1553 8) Updated Location Response (section 6.3) to remove reference to
1554 context and discuss the used of a local identifier or unlinked
1555 pseudonym in providing privacy/security.
1557 9) Clarified that the source IP address in the request is used as the
1558 identifier for the target/device for the HELD protocol as defined in
1559 this document.
1561 10) Miscellaneous editorial clarifications.
1563 16. References
1565 16.1. Normative References
1567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1568 Requirement Levels", BCP 14, RFC 2119, March 1997.
1570 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1571 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
1573 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1574 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1575 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1577 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1579 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1580 January 2004.
1582 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
1583 Networks", BCP 84, RFC 3704, March 2004.
1585 [I-D.ietf-geopriv-pdif-lo-profile]
1586 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
1587 PIDF-LO Usage Clarification, Considerations and
1588 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11
1589 (work in progress), February 2008.
1591 [W3C.REC-xmlschema-1-20041028]
1592 Mendelsohn, N., Thompson, H., Beech, D., and M. Maloney,
1593 "XML Schema Part 1: Structures Second Edition", World Wide
1594 Web Consortium Recommendation REC-xmlschema-1-20041028,
1595 October 2004,
1596 .
1598 [W3C.REC-xmlschema-2-20041028]
1599 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
1600 Second Edition", World Wide Web Consortium
1601 Recommendation REC-xmlschema-2-20041028, October 2004,
1602 .
1604 [I-D.ietf-geopriv-lis-discovery]
1605 Thomson, M. and J. Winterbottom, "Discovering the Local
1606 Location Information Server (LIS)",
1607 draft-ietf-geopriv-lis-discovery-00 (work in progress),
1608 December 2007.
1610 16.2. Informative References
1612 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
1613 RFC 793, September 1981.
1615 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
1616 Types", RFC 3023, January 2001.
1618 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
1619 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
1621 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1622 Resource Identifier (URI): Generic Syntax", STD 66,
1623 RFC 3986, January 2005.
1625 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
1626 Registration Procedures for New URI Schemes", BCP 115,
1627 RFC 4395, February 2006.
1629 [I-D.narten-iana-considerations-rfc2434bis]
1630 Narten, T. and H. Alvestrand, "Guidelines for Writing an
1631 IANA Considerations Section in RFCs",
1632 draft-narten-iana-considerations-rfc2434bis-09 (work in
1633 progress), March 2008.
1635 [I-D.ietf-geopriv-l7-lcp-ps]
1636 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
1637 Location Configuration Protocol; Problem Statement and
1638 Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in
1639 progress), March 2008.
1641 [I-D.ietf-geopriv-lbyr-requirements]
1642 Marshall, R., "Requirements for a Location-by-Reference
1643 Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work
1644 in progress), February 2008.
1646 [I-D.ietf-sip-location-conveyance]
1647 Polk, J. and B. Rosen, "Location Conveyance for the
1648 Session Initiation Protocol",
1649 draft-ietf-sip-location-conveyance-10 (work in progress),
1650 February 2008.
1652 [I-D.winterbottom-geopriv-deref-protocol]
1653 Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
1654 Thomson, M., and M. Dawson, "An HTTPS Location
1655 Dereferencing Protocol Using HELD",
1656 draft-winterbottom-geopriv-deref-protocol-00 (work in
1657 progress), November 2007.
1659 Appendix A. HELD Compliance to IETF LCP requirements
1661 This appendix describes HELD's compliance to the requirements
1662 specified in the [I-D.ietf-geopriv-l7-lcp-ps].
1664 A.1. L7-1: Identifier Choice
1666 "The L7 LCP MUST be able to carry different identifiers or MUST
1667 define an identifier that is mandatory to implement. Regarding the
1668 latter aspect, such an identifier is only appropriate if it is from
1669 the same realm as the one for which the location information service
1670 maintains identifier to location mapping."
1672 COMPLY
1674 HELD uses the IP address of the location request message as the
1675 primary source of identity for the requesting device or target. This
1676 identity can be used with other contextual network information to
1677 provide a physical location for the Target for many network
1678 deployments. There may be network deployments where an IP address
1679 alone is insufficient to identify a Target in a network. However,
1680 any necessary identity extensions for these networks is beyond the
1681 scope of this document.
1683 A.2. L7-2: Mobility Support
1685 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
1686 broad range of mobility from devices that can only move between
1687 reboots, to devices that can change attachment points with the impact
1688 that their IP address is changed, to devices that do not change their
1689 IP address while roaming, to devices that continuously move by being
1690 attached to the same network attachment point."
1692 COMPLY
1694 Mobility support is inherently a characteristic of the access network
1695 technology and HELD is designed to be access network agnostic.
1696 Consequently HELD complies with this requirement. In addition HELD
1697 provides specific support for mobile environments by providing an
1698 optional responseTime attribute in location request messages.
1699 Wireless networks often have several different mechanisms at their
1700 disposal for position determination (e.g. Assisted GPS versus
1701 location based on serving base station identity), each providing
1702 different degrees of accuracy and taking different amounts of time to
1703 yield a result. The responseTime parameter provides the LIS with a
1704 criterion which it can use to select a location determination
1705 technique.
1707 A.3. L7-3: ASP and Access Network Provider Relationship
1709 "The design of the L7 LCP MUST NOT assume a business or trust
1710 relationship between the Application Service Provider (ASP) and the
1711 Access Network Provider. Requirements for resolving a reference to
1712 location information are not discussed in this document."
1714 COMPLY
1716 HELD describes a location acquisition protocol and has no
1717 dependencies on the business or trust relationship between the ASP
1718 and the Access Network Provider. Location acquisition using HELD is
1719 subject to the restrictions described in Section 10.
1721 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
1723 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1724 MUST assume that there is a trust and business relationship between
1725 the L2 and the L3 provider. The L3 provider operates the LIS and
1726 needs to obtain location information from the L2 provider since this
1727 one is closest to the end host. If the L2 and L3 provider for the
1728 same host are different entities, they cooperate for the purposes
1729 needed to determine end system locations."
1731 COMPLY
1733 HELD was specifically designed with this model in mind and readily
1734 allows itself to chaining requests between operators without a change
1735 in protocol being required. HELD is a webservices protocol it can be
1736 bound to transports other than HTTP. Using o offers the option of
1737 high request throughput over a dedicated connection between an L3
1738 provider and an L2 provider without incurring the serial restriction
1739 imposed by HTTP. This is less easy to do with protocols that do not
1740 decouple themselves from the transport.
1742 A.5. L7-5: Legacy Device Considerations
1744 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1745 MUST consider legacy residential NAT devices and NTEs in an DSL
1746 environment that cannot be upgraded to support additional protocols,
1747 for example to pass additional information through DHCP."
1749 COMPLY
1751 HELD is an application protocol and operates on top of IP. A HELD
1752 request from a host behind a residential NAT will traverse the NAT
1753 acquiring the external address of the home router. The location
1754 provided to the host therefore will be the address of the home router
1755 in this circumstance. No changes are required to the home router in
1756 order to support this function, HELD was designed specifically to
1757 address this deployment scenario.
1759 A.6. L7-6: VPN Awareness
1761 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1762 MUST assume that at least one end of a VPN is aware of the VPN
1763 functionality. In an enterprise scenario, the enterprise side will
1764 provide the LIS used by the client and can thereby detect whether the
1765 LIS request was initiated through a VPN tunnel."
1767 COMPLY
1769 HELD does not preclude a LIS on the far end of a VPN tunnel being
1770 aware that the client request is occurring over that tunnel. It also
1771 does not preclude a client device from accessing a LIS serving the
1772 local physical network and subsequently using the location
1773 information with an application that is accessed over a VPN tunnel.
1775 A.7. L7-7: Network Access Authentication
1777 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1778 MUST NOT assume prior network access authentication."
1780 COMPLY
1782 HELD makes no assumptions about prior network access authentication.
1783 HELD strongly recommends the use of TLS with server-side certificates
1784 for communication between the end-point and the LIS. There is no
1785 requirement for the end-point to authenticate with the LIS.
1787 A.8. L7-8: Network Topology Unawareness
1789 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1790 MUST NOT assume end systems being aware of the access network
1791 topology. End systems are, however, able to determine their public
1792 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
1794 COMPLY
1796 HELD makes no assumption about the network topology. HELD doesn't
1797 require that the device know its external IP address, except where
1798 that is required for discovery of the LIS.
1800 A.9. L7-9: Discovery Mechanism
1802 "The L7 LCP MUST define a single mandatory to implement discovery
1803 mechanism."
1805 COMPLY
1806 HELD uses the discovery mechanism in
1807 [I-D.ietf-geopriv-lis-discovery].
1809 A.10. L7-10: PIDF-LO Creation
1811 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
1812 element into the element of the presence document
1813 (see RFC 4479). This ensures that the resulting PIDF-LO document,
1814 which is subsequently distributed to other entities, conforms to the
1815 rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile]
1817 COMPLY
1819 HELD protocol overview (Section 4 ) describes the requirements on the
1820 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
1821 by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile].
1823 Authors' Addresses
1825 Mary Barnes (editor)
1826 Nortel
1827 2201 Lakeside Blvd
1828 Richardson, TX
1830 Email: mary.barnes@nortel.com
1832 James Winterbottom
1833 Andrew
1834 PO Box U40
1835 Wollongong University Campus, NSW 2500
1836 AU
1838 Phone: +61 2 4221 2938
1839 Email: james.winterbottom@andrew.com
1840 URI: http://www.andrew.com/
1841 Martin Thomson
1842 Andrew
1843 PO Box U40
1844 Wollongong University Campus, NSW 2500
1845 AU
1847 Phone: +61 2 4221 2915
1848 Email: martin.thomson@andrew.com
1849 URI: http://www.andrew.com/
1851 Barbara Stark
1852 BellSouth
1853 Room 7A41
1854 725 W Peachtree St.
1855 Atlanta, GA 30308
1856 US
1858 Email: barbara.stark@bellsouth.com
1860 Full Copyright Statement
1862 Copyright (C) The IETF Trust (2008).
1864 This document is subject to the rights, licenses and restrictions
1865 contained in BCP 78, and except as set forth therein, the authors
1866 retain all their rights.
1868 This document and the information contained herein are provided on an
1869 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1870 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1871 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1872 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1873 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1874 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1876 Intellectual Property
1878 The IETF takes no position regarding the validity or scope of any
1879 Intellectual Property Rights or other rights that might be claimed to
1880 pertain to the implementation or use of the technology described in
1881 this document or the extent to which any license under such rights
1882 might or might not be available; nor does it represent that it has
1883 made any independent effort to identify any such rights. Information
1884 on the procedures with respect to rights in RFC documents can be
1885 found in BCP 78 and BCP 79.
1887 Copies of IPR disclosures made to the IETF Secretariat and any
1888 assurances of licenses to be made available, or the result of an
1889 attempt made to obtain a general license or permission for the use of
1890 such proprietary rights by implementers or users of this
1891 specification can be obtained from the IETF on-line IPR repository at
1892 http://www.ietf.org/ipr.
1894 The IETF invites any interested party to bring to its attention any
1895 copyrights, patents or patent applications, or other proprietary
1896 rights that may cover technology that may be required to implement
1897 this standard. Please address the information to the IETF at
1898 ietf-ipr@ietf.org.