idnits 2.17.1
draft-ietf-geopriv-http-location-delivery-06.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 1885.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1896.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1903.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1909.
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 :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 3 characters in excess of 72.
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 9, 2008) is 5859 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: 'RFC2827' is defined on line 1575, but no explicit
reference was found in the text
== Unused Reference: 'RFC4119' is defined on line 1588, 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)
** Downref: Normative reference to an Informational RFC: RFC 3693
== 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 3825
(Obsoleted by RFC 6225)
-- 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: 6 errors (**), 0 flaws (~~), 9 warnings (==), 11 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 11, 2008
7 April 9, 2008
9 HTTP Enabled Location Delivery (HELD)
10 draft-ietf-geopriv-http-location-delivery-06.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 11, 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 . . . . . . . . . . . . . . . . . . . . . 11
64 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
65 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
66 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 13
67 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 13
68 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 14
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) . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . 22
80 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
81 11.1. HTTP Example Messages . . . . . . . . . . . . . . . . . . 23
82 11.2. Simple Location Request Example . . . . . . . . . . . . . 26
83 11.3. Location Request Example for Multiple Location Types . . . 27
84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
85 12.1. URN Sub-Namespace Registration for
86 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
87 12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
88 12.3. MIME Media Type Registration for 'application/held+xml' . 29
89 12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30
90 12.5. URI Registration . . . . . . . . . . . . . . . . . . . . . 31
91 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
92 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
93 15. Changes since last Version . . . . . . . . . . . . . . . . . . 32
94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
95 16.1. Normative References . . . . . . . . . . . . . . . . . . . 36
96 16.2. Informative References . . . . . . . . . . . . . . . . . . 37
97 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 38
98 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 39
99 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 39
100 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 39
101 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 40
102 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 40
103 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 41
104 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 41
105 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 41
106 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 41
107 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 42
108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
109 Intellectual Property and Copyright Statements . . . . . . . . . . 44
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
645
653
654
655 This document (RFC xxxx) defines HELD messages.
656
658
659
661
662
663
664
665
666
667
669
670
672
673
674
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
693
694
695
696
697
698
699
700
701
703
704
705
706
707
708
709
711
712
713
714
715
717
718
719
720
722
723
724
726
727
728
729
730
731
733
734
735
736
738
739
740
741
742
744
746
747
748
749
751
753
754
755
756
757
758
761
763
764
765
766
768
771
773
774
775
776
777
780
782
783
784
785
787
790
792 8. HELDS: URI Definition
794 This section defines the schema for a helds: URI. This URI schema is
795 one possible URI scheme for the "locationURI" element, described in
796 Section 6.5.1, in a HELD "locationResponse " message. In this case,
797 the helds: URI indicates to the Device where to obtain the actual
798 location information for a Target. In addition, the helds: URI can
799 be the result of the LIS discovery process
800 [I-D.ietf-geopriv-lis-discovery] and indicates to the Device the LIS
801 from which LI should be requested.
803 The helds: URI is defined using a subset of the URI schema specified
804 in Appendix A. of RFC3986 [RFC3986] and the associated URI
805 Guidelines [RFC4395] per the following ABNF syntax:
807 HELD-URI = "helds" ":" "//" host [":" port] [ path-absolute ] [? query]
809 The following summarizes the primary elements comprising the HELD-
810 URI:
812 host: As defined in RFC3986 [RFC3986]
813 port: As defined in RFC3986 [RFC3986]. There is no unique port
814 associated with location URIs.
815 path-absolute As defined in RFC3986 [RFC3986].
816 query: As defined in RFC3986 [RFC3986]. This allows for additional
817 information associated with the URIs such as a unique anonymous
818 identifier for the Device associated with the target location.
820 The helds: URI is not intended to be human-readable text, therefore
821 it is encoded entirely in US-ASCII. The following are examples of
822 helds: URIs:
824 helds://ls.example.com:49152/thisLocation?token=xyz987
825 helds://ls.example.com:5432/THISLOCATION?foobar=abc123
826 helds://ls.example.com:5432/THISlocation?foobar=ABC123
827 helds://ls.example.com:9876/civic
829 Other than the "host" portion, URIs are case sensitive and exact
830 equivalency is required for HELD-URI comparisons. For example, in
831 the above examples, although similar in information, the 2nd and 3rd
832 URIs are not considered equivalent.
834 In the case where the helds: URI is contained in a "locationURI"
835 element in a HELD locationResponse message, it is important to note
836 that the URI is only valid for the length of time indicated by the
837 "expires" attribute.
839 9. HTTP Binding
841 This section describes the use of HTTP [RFC2616] as a transport
842 mechanism for this protocol, which all conforming implementations
843 MUST support.
845 The request is carried in the body of an HTTP POST request. The MIME
846 type of both request and response bodies should be
847 "application/held+xml". This should be reflected in the HTTP
848 Content-Type and Accept header fields.
850 The LIS populates the HTTP headers so that they are consistent with
851 the contents of the message. In particular, the cache control header
852 SHOULD be set to disable the HTTP caching of any PIDF-LO document or
853 Location URIs. Otherwise, there is the risk of stale locations
854 and/or the unauthorized disclosure of the LI. This also allows the
855 LIS to control any caching with the "expires" parameter. The HTTP
856 status code MUST indicate a 2xx series response for all HELD
857 locationResponse and error messages.
859 The use of HTTP also includes a default behaviour, which is triggered
860 by a GET request, or a POST with no request body. If either of these
861 queries are received, the LIS MUST attempt to provide either a
862 PIDF-LO document or a Location URI, as if the request was a location
863 request.
865 The implementation of HTTP as a transport mechanism MUST implement
866 TLS as described in [RFC2818]. TLS provides message integrity and
867 privacy between Device and LIS. The LIS MUST use the server
868 authentication method described in [RFC2818]; the Device MUST fail a
869 request if server authentication fails, except in the event of an
870 emergency.
872 10. Security Considerations
874 HELD is a location acquisition protocol whereby the a client requests
875 its location from a LIS. Specific requirements and security
876 considerations for location acquisition protocols are provided in
877 [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security
878 considerations applicable to the use of Location URIs and by
879 reference provision of LI is included in
880 [I-D.ietf-geopriv-lbyr-requirements].
882 By using the HELD protocol, the client and the LIS expose themselves
883 to two types of risk:
885 Accuracy: Client receives incorrect location information
886 Privacy: An unauthorized entity receives location information
888 The provision of an accurate and privacy/confidentiality protected
889 location to the requestor depends on the success of five steps:
891 1. The client must determine the proper LIS.
892 2. The client must connect to the proper LIS.
893 3. The LIS must be able to identify the device by its identifier
894 (IP Address).
895 4. The LIS must be able to return the desired location.
896 5. HELD messages must be transmitted unmodified between the LIS
897 and the client.
899 Of these, only the second, third and the fifth are within the scope
900 of this document. The first step is based on either manual
901 configuration or on the LIS discovery defined in
902 [I-D.ietf-geopriv-lis-discovery], in which appropriate security
903 considerations are already discussed. The fourth step is dependent
904 on the specific positioning capabilities of the LIS, and is thus
905 outside the scope of this document.
907 10.1. Assuring that the proper LIS has been contacted
909 This document assumes that the LIS to be contacted is identified
910 either by an IP address or a domain name, as is the case for a LIS
911 discovered as described in LIS Discovery
912 [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is
913 conducted using TLS [RFC4346], the LIS can authenticate its identity,
914 either as a domain name or as an IP address, to the client by
915 presenting a certificate containing that identifier as a
916 subjectAltName (i.e., as an iPAddress or dNSName, respectively). In
917 the case of the HTTP binding described above, this is exactly the
918 authentication described by TLS [RFC2818]. Any binding of HELD MUST
919 be capable of being transacted over TLS so that the client can
920 request the above authentication, and a LIS implementation for a
921 binding MUST include this feature. Note that in order for the
922 presented certificate to be valid at the client, the client must be
923 able to validate the certificate. In particular, the validation path
924 of the certificate must end in one of the client's trust anchors,
925 even if that trust anchor is the LIS certificate itself.
927 10.2. Protecting responses from modification
929 In order to prevent that response from being modified en route,
930 messages must be transmitted over an integrity-protected channel.
931 When the transaction is being conducted over TLS (a required feature
932 per Section 10.1), the channel will be integrity protected by
933 appropriate ciphersuites. When TLS is not used, this protection will
934 vary depending on the binding; in most cases, without protection from
935 TLS, the response will not be protected from modification en route.
937 10.3. Privacy and Confidentiality
939 Location information returned by the LIS must be protected from
940 access by unauthorized parties, whether those parties request the
941 location from the LIS or intercept it en route. As in section
942 Section 10.2, transactions conducted over TLS with appropriate
943 ciphersuites are protected from access by unauthorized parties en
944 route. Conversely, in most cases, when not conducted over TLS, the
945 response will be accessible while en route from the LIS to the
946 requestor.
948 Because HELD is an LCP and identifies clients and targets by IP
949 addresses, a requestor is authorized to access location for an IP
950 address only if it is the holder of that IP address. The LIS MUST
951 verify that the client is the target of the returned location, i.e.,
952 the LIS MUST NOT provide location to other entities than the target.
953 Note that this is a necessary, but not sufficient criterion for
954 authorization. A LIS MAY deny requests according to any local
955 policy.
957 A prerequisite for meeting this requirement is that the LIS must have
958 some assurance of the identity of the client. Since the target of
959 the returned location is identified by an IP address, simply sending
960 the response to this IP address will provide sufficient assurance in
961 many cases. This is the default mechanism in HELD for assuring that
962 location is given only to authorized clients; LIS implementations
963 MUST support a mode of operation in which this is the only client
964 authentication.
966 Using IP return routability as an authenticator means that location
967 information is vulnerable to exposure through IP address spoofing
968 attacks. A temporary spoofing of IP address could mean that a device
969 could request a Location Object or Location URI that would result in
970 another Device's location. In addition, in cases where a Device
971 drops off the network for various reasons, the re-use of the Device's
972 IP address could result in another Device receiving the original
973 Device's location rather than its own location. One or more of the
974 following approaches are RECOMMENDED to limit these exposures:
976 o Location URIs SHOULD have a limited lifetime, as reflected by the
977 value for the expires element in Section 6.5.2.
978 o The network SHOULD have mechanisms that protect against IP address
979 spoofing, such as those defined in [RFC3704].
980 o The LIS and network SHOULD be configured so that the LIS is made
981 aware of Device movement within the network and addressing
982 changes. If the LIS detects a change in the network that results
983 in it no longer being able to determine the location of the
984 Device, then all location URIs for that Device SHOULD be
985 invalidated.
987 The above measures are dependent on network configuration, which
988 SHOULD be considered. For instance, in a fixed internet access,
989 providers may be able to restrict the allocation of IP addresses to a
990 single physical line, ensuring that spoofing is not possible; in such
991 an environment, other measures may not be necessary.
993 When there are further mechanisms available to authenticate ownership
994 of the IP address, the LIS SHOULD use them to authenticate that the
995 client is the owner of the target IP address. For example, in a TLS
996 transaction, the client could present a certificate with a public key
997 bound to an IPv6 Cryptographically Generated Address, and the LIS
998 could verify this binding.
1000 11. Examples
1002 The following sections provide basic HTTP examples, a simple location
1003 request example and a location request for multiple location types
1004 example along with the relevant location responses. To focus on
1005 important portions of messages, the examples in Section 11.2 and
1006 Section 11.3 do not show HTTP headers or the XML prologue. In
1007 addition, sections of XML not relevant to the example are replaced
1008 with comments.
1010 11.1. HTTP Example Messages
1012 The examples in this section show a complete HTTP message that
1013 includes the HELD request or response document.
1015 This example shows the most basic request for a LO. This uses the
1016 GET feature described by the HTTP binding. This example assumes that
1017 the LIS service exists at the URL "https://lis.example.com/location".
1019 GET /location HTTP/1.1
1020 Host: lis.example.com
1021 Accept:application/held+xml,
1022 application/xml;q=0.8,
1023 text/xml;q=0.7
1024 Accept-Charset: UTF-8,*
1026 The GET request is exactly identical to a minimal POST request that
1027 includes an empty "locationRequest" element.
1029 POST /location HTTP/1.1
1030 Host: lis.example.com
1031 Accept: application/held+xml,
1032 application/xml;q=0.8,
1033 text/xml;q=0.7
1034 Accept-Charset: UTF-8,*
1035 Content-Type: application/held+xml
1036 Content-Length: 87
1038
1039
1041 Since neither of these requests includes a "locationType" element,
1042 the successful response to either of these requests may contain any
1043 type of location. The following shows a response containing a
1044 minimal PIDF-LO.
1046 HTTP/1.x 200 OK
1047 Server: Example LIS
1048 Date: Tue, 10 Jan 2006 03:42:29 GMT
1049 Expires: Tue, 10 Jan 2006 03:42:29 GMT
1050 Cache-control: private
1051 Content-Type: application/held+xml
1052 Content-Length: 594
1054
1055
1056
1058
1059
1060
1061
1062
1064 -34.407 150.88001
1065
1066
1067
1068
1069 2006-01-11T03:42:28+00:00
1070
1071 Wiremap
1072
1073
1074 2006-01-10T03:42:28+00:00
1075
1076
1077
1079 The error response to either of these requests is an error document.
1080 The following response shows an example error response.
1082 HTTP/1.x 200 OK
1083 Server: Example LIS
1084 Expires: Tue, 10 Jan 2006 03:49:20 GMT
1085 Cache-control: private
1086 Content-Type: application/held+xml
1087 Content-Length: 135
1089
1090
1094 11.2. Simple Location Request Example
1096 The location request shown below doesn't specify any location types
1097 or response time.
1099
1101 The example response to this location request contains a list of
1102 Location URIs.
1104
1105
1106 helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
1107
1108 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
1109
1110
1111
1113 An error response to this location request is shown below:
1115
1119 11.3. Location Request Example for Multiple Location Types
1121 The following Location Request message includes a request for
1122 geodetic, civic and any Location URIs.
1124
1125
1126 geodetic
1127 civic
1128 locationURI
1129
1130
1132 The corresponding Location Response message includes the requested
1133 location information, including two location URIs.
1135
1136
1137 helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
1138
1139 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
1140
1141
1142
1144
1145
1146
1147
1148
1152 -34.407242 150.882518
1153 30
1154
1156
1157
1160 AU
1161 NSW
1162 Wollongong
1163 Gwynneville
1164 Northfield Avenue
1165 University of Wollongong
1166 2
1167 Andrew Corporation
1168 2500
1169 39
1170 WS-183
1171 U40
1172
1173
1174
1175 false
1176 2007-05-25T12:35:02+10:00
1177
1178
1179 Wiremap
1180
1181
1182 2007-05-24T12:35:02+10:00
1183
1184
1185
1187 12. IANA Considerations
1189 This document requires several IANA registrations detailed in the
1190 following sections.
1192 12.1. URN Sub-Namespace Registration for
1193 urn:ietf:params:xml:ns:geopriv:held
1195 This section registers a new XML namespace,
1196 "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in
1197 [RFC3688].
1199 URI: urn:ietf:params:xml:ns:geopriv:held
1200 Registrant Contact: IETF, GEOPRIV working group,
1201 (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
1202 XML:
1204 BEGIN
1205
1206
1208
1209
1210 HELD Messages
1211
1212
1213 Namespace for HELD Messages
1214 urn:ietf:params:xml:ns:geopriv:held
1215 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1216 with the RFC number for this specification.]
1217
See RFCXXXX
1218
1219
1220 END
1222 12.2. XML Schema Registration
1224 This section registers an XML schema as per the guidelines in
1225 [RFC3688].
1227 URI: urn:ietf:params:xml:schema:geopriv:held
1228 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1229 Mary Barnes (mary.barnes@nortel.com).
1230 Schema: The XML for this schema can be found as the entirety of
1231 Section 7 of this document.
1233 12.3. MIME Media Type Registration for 'application/held+xml'
1235 This section registers the "application/held+xml" MIME type.
1237 To: ietf-types@iana.org
1238 Subject: Registration of MIME media type application/held+xml
1239 MIME media type name: application
1240 MIME subtype name: held+xml
1241 Required parameters: (none)
1242 Optional parameters: charset
1243 Indicates the character encoding of enclosed XML. Default is
1244 UTF-8.
1246 Encoding considerations: Uses XML, which can employ 8-bit
1247 characters, depending on the character encoding used. See RFC
1248 3023 [RFC3023], section 3.2.
1249 Security considerations: This content type is designed to carry
1250 protocol data related to the location of an entity, which could
1251 include information that is considered private. Appropriate
1252 precautions should be taken to limit disclosure of this
1253 information.
1254 Interoperability considerations: This content type provides a basis
1255 for a protocol
1256 Published specification: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please
1257 replace XXXX with the RFC number for this specification.]
1258 Applications which use this media type: Location information
1259 providers and consumers.
1260 Additional Information: Magic Number(s): (none)
1261 File extension(s): .xml
1262 Macintosh File Type Code(s): (none)
1263 Person & email address to contact for further information: Mary
1264 Barnes
1265 Intended usage: LIMITED USE
1266 Author/Change controller: The IETF
1267 Other information: This media type is a specialization of
1268 application/xml [RFC3023], and many of the considerations
1269 described there also apply to application/held+xml.
1271 12.4. Error code Registry
1273 This document requests that the IANA create a new registry for the
1274 HELD protocol including an initial registry for error codes. The
1275 error codes are included in HELD error messages as described in
1276 Section 6.3 and defined in the schema in the 'codeType' token in the
1277 XML schema in (Section 7)
1279 The following summarizes the requested registry:
1281 Related Registry: Geopriv HELD Registries, Error codes for HELD
1282 Defining RFC: RFC XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
1283 with the RFC number for this specification.]
1284 Registration/Assignment Procedures: Following the policies outlined
1285 in [I-D.narten-iana-considerations-rfc2434bis], the IANA policy
1286 for assigning new values for the Error codes for HELD shall be
1287 Specification Required: values and their meanings must be
1288 documented in an RFC or in some other permanent and readily
1289 available reference, in sufficient detail that interoperability
1290 between independent implementations is possible.
1292 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
1293 Mary Barnes (mary.barnes@nortel.com).
1295 This section pre-registers the following seven initial error codes as
1296 described above in Section 6.3:
1298 requestError: This code indicates that the request was badly formed
1299 in some fashion.
1300 xmlError: This code indicates that the XML content of the request
1301 was either badly formed or invalid.
1302 generalLisError: This code indicates that an unspecified error
1303 occurred at the LIS.
1304 locationUnknown: This code indicates that the LIS could not
1305 determine the location of the Device.
1306 unsupportedMessage: This code indicates that the request was not
1307 supported or understood by the LIS.
1308 timeout: This code indicates that the LIS could not satisfy the
1309 request within the time specified in the "responseTime" parameter.
1310 cannotProvideLiType: This code indicates that the LIS was unable to
1311 provide LI of the type or types requested. This code is used when
1312 the "exact" attribute on the "locationType" parameter is set to
1313 "true".
1315 12.5. URI Registration
1317 The following summarizes the information necessary to register the
1318 helds: URI. [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the
1319 RFC number for this specification in the following list.]
1321 URI Scheme Name: helds
1322 Status: permanent
1323 URI Scheme syntax: See section
1324 URI Scheme Semantics: The helds: URI is intended to be used as a
1325 reference to a location object or a location information server.
1326 Further detail is provided in Section 8 of RFC XXXX.
1327 Encoding Considerations: The HELDS: URI is not intended to be human-
1328 readable text, therefore they are encoded entirely in US-ASCII.
1329 Applications/protocols that use this URI scheme: The HELD protocol
1330 described in RFC XXXX, the GEOPRIV Location De-reference Protocol
1331 [I-D.winterbottom-geopriv-deref-protocol] and GEOPRIV Location
1332 Information Server Discovery [I-D.ietf-geopriv-lis-discovery].
1333 Interoperability considerations: This URI may be used as a parameter
1334 for the HELD protocol in the locationResponse message. This URI
1335 is also used as an input parameter for the GEOPRIV Location De-
1336 reference Protocol [I-D.winterbottom-geopriv-deref-protocol].
1337 This URI may also be a result of the GEOPRIV Location Information
1338 Server Discovery [I-D.ietf-geopriv-lis-discovery] and thus used as
1339 the target for the HELD protocol request messages. Refer to
1340 Section 8 in RFC XXXX for further detail and a particular example
1341 on the lack of permanence of a specific HELDS: URI and thus the
1342 importance of using these URIs only within the specific contexts
1343 outlined in the references.
1344 Security considerations: Section 10 in RFC XXXX addresses the
1345 necessary security associated with the transport of location
1346 information between a Device and the LIS to ensure the privacy and
1347 integrity of the helds: URI. Section 6.5.1 in RFC XXXX also
1348 recommends that the URI be allocated such that it does not reveal
1349 any detail at all about the content of the PIDF-LO that it may
1350 indirectly reference.
1351 Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
1352 Barnes (mary.barnes@nortel.com).
1353 Author/Change controller: This scheme is registered under the IETF
1354 tree. As such, IETF maintains change control.
1355 References: RFC XXXX, GEOPRIV Location De-reference Protocol
1356 [I-D.winterbottom-geopriv-deref-protocol], GEOPRIV Location
1357 Information Server Discovery [I-D.ietf-geopriv-lis-discovery]
1359 13. Contributors
1361 James Winterbottom, Martin Thomson and Barbara Stark are the authors
1362 of the original document, from which this WG document was derived.
1363 Their contact information is included in the Author's address
1364 section. In addition, they also contributed to the WG document,
1365 including the XML schema.
1367 14. Acknowledgements
1369 The author/contributors would like to thank the participants in the
1370 GEOPRIV WG and the following people for their constructive input and
1371 feedback on this document (in alphabetical order): Nadine Abbott,
1372 Eric Arolick, Richard Barnes (in particular the security section),
1373 Peter Blatherwick, Guy Caron, Martin Dawson, Lisa Dusseault, Jerome
1374 Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, Tat Lam, Marc
1375 Linsner, Patti McCalmont, Roger Marshall, Perry Prozeniuk, Carl Reed,
1376 Brian Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
1377 Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf.
1379 15. Changes since last Version
1381 NOTE TO THE RFC-Editor: Please remove this section prior to
1382 publication as an RFC.
1384 Changes from WG 05 to 06 (2nd WGLC comments):
1386 1) Updated security section based on WG feedback, including
1387 condensing section 10.1.1 (Assuring the proper LIS has been
1388 contacted), restructuring sections by flattening, adding an
1389 additional step to the list that had been in the Accuracy section and
1390 removing summary section.
1392 2) Changed URI schema to "helds" to address concerns over referential
1393 integrity and for consistency with mandate of TLS for HELD.
1395 3) Editorial clarifications including fixing examples to match HELD
1396 URI definition (e.g., adding port, adding randomness to URI examples,
1397 etc.)
1399 4) Updated references removing unused references and moving
1400 requirements docs to Informational Reference section to avoid
1401 downrefs.
1403 Changes from WG 04 to 05 (WGLC comments):
1405 1) Totally replaced the security section with the details provided by
1406 Richard Barnes so that we don't need a reference to the location
1407 security document.
1409 2) Fixed error codes in schema to allow extensibility. Change the
1410 IANA registration to be "specification required".
1412 3) Cleaned up the HELD: URI description, per comments from Martin and
1413 James and partially addressing HELD-04 Issue 1. Put the definition
1414 in a separate section and clarified the applicability (to also
1415 include being a results of the discovery process) and fixed examples.
1417 4) Updated the LocationURI section to be more accurate, address
1418 HELD-04 Issue 3, and include the reference to the new HELD:URI
1419 section. Also, fixed an error in the doc in that the top level parm
1420 in the locationResponse is actually locationUriSet, which contains
1421 any number of locationURI elements and the "expires" parameter. So,
1422 Table 1 was also updated and a new section for the LocationURISet was
1423 added that includes the subsections for the "locationURI" and
1424 "expires". And, then clarified that "expires" applies to
1425 "locationURISet" and not per "locationURI".
1427 5) Editorial nits: pointed out offline by Richard (e.g., by-value ->
1428 by value, by-reference -> by reference, etc.) and onlist by James and
1429 Martin. Please refer to the diff for a complete view of editorial
1430 changes.
1432 6) Added text in HTTP binding section to disable HTTP caching
1433 (HELD-04 Issue 5 on the list).
1435 Changes from WG 03 to 04:
1437 1) Terminology: clarified in terminology section that "attribute" and
1438 "element" are used in the strict XML sense and "parameter" is used as
1439 a general protocol term Replaced term "HTTP delivery" with "HTTP
1440 transport". Still have two terms "HTTP transport" and "HTTP
1441 binding", but those are consistent with general uses of HTTP.
1443 2) Editorial changes and clarifications: per Roger Marshall's and
1444 Eric Arolick's comments and subsequent WG mailing list discussion.
1446 3) Changed normative language for describing expected and recommended
1447 LIS behaviors to be non-normative recommendations in cases where the
1448 protocol parameters were not the target of the discussion (e.g., we
1449 can't prescribe to the LIS how it determines location or what it
1450 defines to be an "accurate" location).
1452 4) Clarified responseTime attribute (section 6.1). Changed type from
1453 "decimal" to "nonNegativeInteger" in XML schema (section 7)
1455 5) Updated Table 1 in section 6 to only include top-level parameters
1456 and fixed some errors in that table (i.e., code for locationResponse)
1457 and adding PIDF-LO to the table. Added a detailed section describing
1458 PIDF-LO (section 6.6), moving some of the normative text in the
1459 Protocol Overview to this section.
1461 6) Added schema and description for locationURI to section 6.5.
1462 Added IANA registration for HELD: URI schema.
1464 7) Added IANA registry for error codes.
1466 Changes from WG 02 to 03:
1468 1) Added text to address concern over use of IP address as device
1469 identifier, per long email thread - changes to section 3 (overview)
1470 and section 4 (protocol overview).
1472 2) Removed WSDL (section 8 updated, section 8.1 and 10.4 removed)
1474 3) Added extensibility to baseRequestType in the schema (an oversight
1475 from previous edits), along with fixing some other nits in schema
1476 (section 7)
1478 4) Moved discussion of Location URI from section 5.3 (Location
1479 Response) to where it rightly belonged in Section 6.5 (Location URI
1480 Parameter).
1482 5) Clarified text for "expires" parameter (6.5.1) - it's an optional
1483 parm, but required for LocationURIs
1485 6) Clarified responseTime parameter: when missing, then the LCS
1486 provides most precise LI, with the time required being implementation
1487 specific.
1489 7) Clarified that the MUST use in section 8 (HTTP binding) is a MUST
1490 implement.
1492 8) Updated references (removed unused/added new).
1494 Changes from WG 01 to 02:
1496 1) Updated Terminology to be consistent with WG agreements and other
1497 documents (e.g., LCS -> LIS and removed duplicate terms). In the
1498 end, there are no new terms defined in this document.
1500 2) Modified definition of responseTime to reflect WG consensus.
1502 3) Removed jurisdictionalCivic and postalCivic locationTypes (leaving
1503 just "civic").
1505 4) Clarified text that locationType is optional. Fixed table 1 and
1506 text in section 5.2 (locationRequest description). Text in section
1507 6.2 (description of locationType element) already defined the default
1508 to be "any".
1510 5) Simplified error responses. Separated the definition of error
1511 response type from the locationResponse type thus no need for
1512 defining an error code of "success". This simplifies the schema and
1513 processing.
1515 6) Updated schema/examples for the above.
1517 7) Updated Appendix A based on updates to requirements document,
1518 specifically changes to A.1, A.3 and adding A.10.
1520 8) Miscellaneous editorial clarifications.
1522 Changes from WG 00 to 01:
1524 1) heldResponse renamed to locationResponse.
1526 2) Changed namespace references for the PIDF-LO geoShape in the
1527 schema to match the agreed GML PIDF-LO Geometry Shape Application
1528 Schema.
1530 3) Removed "options" element - leaving optionality/extensibility to
1531 XML mechanisms.
1533 4) Changed error codes to be enumerations and not redefinitions of
1534 HTTP response codes.
1536 5) Updated schema/examples for the above and removed some remnants of
1537 the context element.
1539 6) Clarified the definition of "Location Information (LI)" to include
1540 a reference to the location (to match the XML schema and provide
1541 consistency of usage throughout the document). Added an additional
1542 statement in section 7.2 (locationType) to clarify that LCS MAY also
1543 return a Location URI.
1545 7) Modifed the definition of "Location Configuration Server (LCS)" to
1546 be consistent with the current definiton in the requirements
1547 document.
1549 8) Updated Location Response (section 6.3) to remove reference to
1550 context and discuss the used of a local identifier or unlinked
1551 pseudonym in providing privacy/security.
1553 9) Clarified that the source IP address in the request is used as the
1554 identifier for the target/device for the HELD protocol as defined in
1555 this document.
1557 10) Miscellaneous editorial clarifications.
1559 16. References
1561 16.1. Normative References
1563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1564 Requirement Levels", BCP 14, RFC 2119, March 1997.
1566 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1567 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
1569 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1570 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1571 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1573 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1575 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
1576 Defeating Denial of Service Attacks which employ IP Source
1577 Address Spoofing", BCP 38, RFC 2827, May 2000.
1579 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1580 January 2004.
1582 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
1583 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
1585 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
1586 Networks", BCP 84, RFC 3704, March 2004.
1588 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
1589 Format", RFC 4119, December 2005.
1591 [I-D.ietf-geopriv-pdif-lo-profile]
1592 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
1593 PIDF-LO Usage Clarification, Considerations and
1594 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11
1595 (work in progress), February 2008.
1597 [W3C.REC-xmlschema-1-20041028]
1598 Maloney, M., Thompson, H., Beech, D., and N. Mendelsohn,
1599 "XML Schema Part 1: Structures Second Edition", World Wide
1600 Web Consortium Recommendation REC-xmlschema-1-20041028,
1601 October 2004,
1602 .
1604 [W3C.REC-xmlschema-2-20041028]
1605 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
1606 Second Edition", World Wide Web Consortium
1607 Recommendation REC-xmlschema-2-20041028, October 2004,
1608 .
1610 [I-D.ietf-geopriv-lis-discovery]
1611 Thomson, M. and J. Winterbottom, "Discovering the Local
1612 Location Information Server (LIS)",
1613 draft-ietf-geopriv-lis-discovery-00 (work in progress),
1614 December 2007.
1616 16.2. Informative References
1618 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
1619 RFC 793, September 1981.
1621 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
1622 Types", RFC 3023, January 2001.
1624 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1625 Resource Identifier (URI): Generic Syntax", STD 66,
1626 RFC 3986, January 2005.
1628 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
1629 Configuration Protocol Option for Coordinate-based
1630 Location Configuration Information", RFC 3825, July 2004.
1632 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
1633 Registration Procedures for New URI Schemes", BCP 115,
1634 RFC 4395, February 2006.
1636 [I-D.narten-iana-considerations-rfc2434bis]
1637 Narten, T. and H. Alvestrand, "Guidelines for Writing an
1638 IANA Considerations Section in RFCs",
1639 draft-narten-iana-considerations-rfc2434bis-09 (work in
1640 progress), March 2008.
1642 [I-D.ietf-geopriv-l7-lcp-ps]
1643 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
1644 Location Configuration Protocol; Problem Statement and
1645 Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in
1646 progress), March 2008.
1648 [I-D.ietf-geopriv-lbyr-requirements]
1649 Marshall, R., "Requirements for a Location-by-Reference
1650 Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work
1651 in progress), February 2008.
1653 [I-D.ietf-sip-location-conveyance]
1654 Polk, J. and B. Rosen, "Location Conveyance for the
1655 Session Initiation Protocol",
1656 draft-ietf-sip-location-conveyance-10 (work in progress),
1657 February 2008.
1659 [I-D.winterbottom-geopriv-deref-protocol]
1660 Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
1661 Thomson, M., and M. Dawson, "An HTTPS Location
1662 Dereferencing Protocol Using HELD",
1663 draft-winterbottom-geopriv-deref-protocol-00 (work in
1664 progress), November 2007.
1666 [LLDP-MED]
1667 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
1668 Endpoint Discovery".
1670 Appendix A. HELD Compliance to IETF LCP requirements
1672 This appendix describes HELD's compliance to the requirements
1673 specified in the [I-D.ietf-geopriv-l7-lcp-ps].
1675 A.1. L7-1: Identifier Choice
1677 "The L7 LCP MUST be able to carry different identifiers or MUST
1678 define an identifier that is mandatory to implement. Regarding the
1679 latter aspect, such an identifier is only appropriate if it is from
1680 the same realm as the one for which the location information service
1681 maintains identifier to location mapping."
1683 COMPLY
1685 HELD uses the IP address of the location request message as the
1686 primary source of identity for the requesting device or target. This
1687 identity can be used with other contextual network information to
1688 provide a physical location for the Target for many network
1689 deployments. There may be network deployments where an IP address
1690 alone is insufficient to identify a Target in a network. However,
1691 any necessary identity extensions for these networks is beyond the
1692 scope of this document.
1694 A.2. L7-2: Mobility Support
1696 "The GEOPRIV Layer 7 Location Configuration Protocol MUST support a
1697 broad range of mobility from devices that can only move between
1698 reboots, to devices that can change attachment points with the impact
1699 that their IP address is changed, to devices that do not change their
1700 IP address while roaming, to devices that continuously move by being
1701 attached to the same network attachment point."
1703 COMPLY
1705 Mobility support is inherently a characteristic of the access network
1706 technology and HELD is designed to be access network agnostic.
1707 Consequently HELD complies with this requirement. In addition HELD
1708 provides specific support for mobile environments by providing an
1709 optional responseTime attribute in location request messages.
1710 Wireless networks often have several different mechanisms at their
1711 disposal for position determination (e.g. Assisted GPS versus
1712 location based on serving base station identity), each providing
1713 different degrees of accuracy and taking different amounts of time to
1714 yield a result. The responseTime parameter provides the LIS with a
1715 criterion which it can use to select a location determination
1716 technique.
1718 A.3. L7-3: ASP and Access Network Provider Relationship
1720 "The design of the L7 LCP MUST NOT assume a business or trust
1721 relationship between the Application Service Provider (ASP) and the
1722 Access Network Provider. Requirements for resolving a reference to
1723 location information are not discussed in this document."
1725 COMPLY
1727 HELD describes a location acquisition protocol and has no
1728 dependencies on the business or trust relationship between the ASP
1729 and the Access Network Provider. Location acquisition using HELD is
1730 subject to the restrictions described in Section 10.
1732 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
1734 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1735 MUST assume that there is a trust and business relationship between
1736 the L2 and the L3 provider. The L3 provider operates the LIS and
1737 needs to obtain location information from the L2 provider since this
1738 one is closest to the end host. If the L2 and L3 provider for the
1739 same host are different entities, they cooperate for the purposes
1740 needed to determine end system locations."
1742 COMPLY
1744 HELD was specifically designed with this model in mind and readily
1745 allows itself to chaining requests between operators without a change
1746 in protocol being required. HELD is a webservices protocol it can be
1747 bound to transports other than HTTP. Using o offers the option of
1748 high request throughput over a dedicated connection between an L3
1749 provider and an L2 provider without incurring the serial restriction
1750 imposed by HTTP. This is less easy to do with protocols that do not
1751 decouple themselves from the transport.
1753 A.5. L7-5: Legacy Device Considerations
1755 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1756 MUST consider legacy residential NAT devices and NTEs in an DSL
1757 environment that cannot be upgraded to support additional protocols,
1758 for example to pass additional information through DHCP."
1760 COMPLY
1762 HELD is an application protocol and operates on top of IP. A HELD
1763 request from a host behind a residential NAT will traverse the NAT
1764 acquiring the external address of the home router. The location
1765 provided to the host therefore will be the address of the home router
1766 in this circumstance. No changes are required to the home router in
1767 order to support this function, HELD was designed specifically to
1768 address this deployment scenario.
1770 A.6. L7-6: VPN Awareness
1772 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1773 MUST assume that at least one end of a VPN is aware of the VPN
1774 functionality. In an enterprise scenario, the enterprise side will
1775 provide the LIS used by the client and can thereby detect whether the
1776 LIS request was initiated through a VPN tunnel."
1778 COMPLY
1780 HELD does not preclude a LIS on the far end of a VPN tunnel being
1781 aware that the client request is occurring over that tunnel. It also
1782 does not preclude a client device from accessing a LIS serving the
1783 local physical network and subsequently using the location
1784 information with an application that is accessed over a VPN tunnel.
1786 A.7. L7-7: Network Access Authentication
1788 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1789 MUST NOT assume prior network access authentication."
1791 COMPLY
1793 HELD makes no assumptions about prior network access authentication.
1794 HELD strongly recommends the use of TLS with server-side certificates
1795 for communication between the end-point and the LIS. There is no
1796 requirement for the end-point to authenticate with the LIS.
1798 A.8. L7-8: Network Topology Unawareness
1800 "The design of the GEOPRIV Layer 7 Location Configuration Protocol
1801 MUST NOT assume end systems being aware of the access network
1802 topology. End systems are, however, able to determine their public
1803 IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP."
1805 COMPLY
1807 HELD makes no assumption about the network topology. HELD doesn't
1808 require that the device know its external IP address, except where
1809 that is required for discovery of the LIS.
1811 A.9. L7-9: Discovery Mechanism
1813 "The L7 LCP MUST define a single mandatory to implement discovery
1814 mechanism."
1816 COMPLY
1817 HELD uses the discovery mechanism in
1818 [I-D.ietf-geopriv-lis-discovery].
1820 A.10. L7-10: PIDF-LO Creation
1822 "When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the
1823 element into the element of the presence document
1824 (see RFC 4479). This ensures that the resulting PIDF-LO document,
1825 which is subsequently distributed to other entities, conforms to the
1826 rules outlined in ". [I-D.ietf-geopriv-pdif-lo-profile]
1828 COMPLY
1830 HELD protocol overview (Section 4 ) describes the requirements on the
1831 LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated
1832 by the LIS MUST conform to [I-D.ietf-geopriv-pdif-lo-profile].
1834 Authors' Addresses
1836 Mary Barnes (editor)
1837 Nortel
1838 2201 Lakeside Blvd
1839 Richardson, TX
1841 Email: mary.barnes@nortel.com
1843 James Winterbottom
1844 Andrew
1845 PO Box U40
1846 Wollongong University Campus, NSW 2500
1847 AU
1849 Phone: +61 2 4221 2938
1850 Email: james.winterbottom@andrew.com
1851 URI: http://www.andrew.com/
1852 Martin Thomson
1853 Andrew
1854 PO Box U40
1855 Wollongong University Campus, NSW 2500
1856 AU
1858 Phone: +61 2 4221 2915
1859 Email: martin.thomson@andrew.com
1860 URI: http://www.andrew.com/
1862 Barbara Stark
1863 BellSouth
1864 Room 7A41
1865 725 W Peachtree St.
1866 Atlanta, GA 30308
1867 US
1869 Email: barbara.stark@bellsouth.com
1871 Full Copyright Statement
1873 Copyright (C) The IETF Trust (2008).
1875 This document is subject to the rights, licenses and restrictions
1876 contained in BCP 78, and except as set forth therein, the authors
1877 retain all their rights.
1879 This document and the information contained herein are provided on an
1880 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1881 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1882 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1883 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1884 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1885 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1887 Intellectual Property
1889 The IETF takes no position regarding the validity or scope of any
1890 Intellectual Property Rights or other rights that might be claimed to
1891 pertain to the implementation or use of the technology described in
1892 this document or the extent to which any license under such rights
1893 might or might not be available; nor does it represent that it has
1894 made any independent effort to identify any such rights. Information
1895 on the procedures with respect to rights in RFC documents can be
1896 found in BCP 78 and BCP 79.
1898 Copies of IPR disclosures made to the IETF Secretariat and any
1899 assurances of licenses to be made available, or the result of an
1900 attempt made to obtain a general license or permission for the use of
1901 such proprietary rights by implementers or users of this
1902 specification can be obtained from the IETF on-line IPR repository at
1903 http://www.ietf.org/ipr.
1905 The IETF invites any interested party to bring to its attention any
1906 copyrights, patents or patent applications, or other proprietary
1907 rights that may cover technology that may be required to implement
1908 this standard. Please address the information to the IETF at
1909 ietf-ipr@ietf.org.