draft-ietf-geopriv-http-location-delivery-08.txt   draft-ietf-geopriv-http-location-delivery-09.txt 
GEOPRIV WG M. Barnes, Ed. GEOPRIV WG M. Barnes, Ed.
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track Intended status: Standards Track
Expires: January 11, 2009 Expires: March 12, 2009
July 10, 2008 September 8, 2008
HTTP Enabled Location Delivery (HELD) HTTP Enabled Location Delivery (HELD)
draft-ietf-geopriv-http-location-delivery-08.txt draft-ietf-geopriv-http-location-delivery-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 11, 2009. This Internet-Draft will expire on March 12, 2009.
Abstract Abstract
A Layer 7 Location Configuration Protocol (L7 LCP) is described that A Layer 7 Location Configuration Protocol (L7 LCP) is described that
is used for retrieving location information from a server within an is used for retrieving location information from a server within an
access network. The protocol includes options for retrieving access network. The protocol includes options for retrieving
location information in two forms: by value and by reference. The location information in two forms: by value and by reference. The
protocol is an extensible application-layer protocol that is protocol is an extensible application-layer protocol that is
independent of session-layer. This document describes the use of independent of session-layer. This document describes the use of
HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer
skipping to change at page 2, line 32 skipping to change at page 2, line 32
6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11 6.1. "responseTime" Parameter . . . . . . . . . . . . . . . . . 11
6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12 6.2. "locationType" Parameter . . . . . . . . . . . . . . . . . 12
6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14 6.2.1. "exact" Attribute . . . . . . . . . . . . . . . . . . 14
6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14 6.3. "code" Parameter . . . . . . . . . . . . . . . . . . . . . 14
6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15 6.4. "message" Parameter . . . . . . . . . . . . . . . . . . . 15
6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15 6.5. "locationUriSet" Parameter . . . . . . . . . . . . . . . . 15
6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15 6.5.1. "locationURI" Parameter . . . . . . . . . . . . . . . 15
6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16 6.5.2. "expires" Parameter . . . . . . . . . . . . . . . . . 16
6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16 6.6. "Presence" Parameter (PIDF-LO) . . . . . . . . . . . . . . 16
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. HELD URI Definitions . . . . . . . . . . . . . . . . . . . . . 20 8. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 20
8.1. heldref: URI Definition . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.2. heldrefs: URI Definition . . . . . . . . . . . . . . . . . 21 9.1. Assuring that the proper LIS has been contacted . . . . . 21
9. HTTP/HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . 22 9.2. Protecting responses from modification . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 22
10.1. Assuring that the proper LIS has been contacted . . . . . 24 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.2. Protecting responses from modification . . . . . . . . . . 24 10.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 23
10.3. Privacy and Confidentiality . . . . . . . . . . . . . . . 24 10.2. Simple Location Request Example . . . . . . . . . . . . . 26
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.3. Location Request Example for Multiple Location Types . . . 27
11.1. HTTPS Example Messages . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.2. Simple Location Request Example . . . . . . . . . . . . . 28 11.1. URN Sub-Namespace Registration for
11.3. Location Request Example for Multiple Location Types . . . 29 urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 11.2. XML Schema Registration . . . . . . . . . . . . . . . . . 29
12.1. URN Sub-Namespace Registration for 11.3. MIME Media Type Registration for 'application/held+xml' . 29
urn:ietf:params:xml:ns:geopriv:held . . . . . . . . . . . 30 11.4. Error code Registry . . . . . . . . . . . . . . . . . . . 30
12.2. XML Schema Registration . . . . . . . . . . . . . . . . . 31 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.3. MIME Media Type Registration for 'application/held+xml' . 31 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
12.4. Error code Registry . . . . . . . . . . . . . . . . . . . 32 14. Changes since last Version . . . . . . . . . . . . . . . . . . 32
12.5. URI Registrations . . . . . . . . . . . . . . . . . . . . 33 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.5.1. heldref: URI Registration . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . . 37
12.5.2. heldrefs: URI Registration . . . . . . . . . . . . . . 34 15.2. Informative References . . . . . . . . . . . . . . . . . . 38
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 39
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 39
15. Changes since last Version . . . . . . . . . . . . . . . . . . 35 A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 39
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.3. L7-3: ASP and Access Network Provider Relationship . . . . 40
16.1. Normative References . . . . . . . . . . . . . . . . . . . 40 A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 40
16.2. Informative References . . . . . . . . . . . . . . . . . . 41 A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 41
Appendix A. HELD Compliance to IETF LCP requirements . . . . . . 42 A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 41
A.1. L7-1: Identifier Choice . . . . . . . . . . . . . . . . . 42 A.7. L7-7: Network Access Authentication . . . . . . . . . . . 41
A.2. L7-2: Mobility Support . . . . . . . . . . . . . . . . . . 43 A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 42
A.3. L7-3: ASP and Access Network Provider Relationship . . . . 43 A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 42
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship . . . . . 44 A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 42
A.5. L7-5: Legacy Device Considerations . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
A.6. L7-6: VPN Awareness . . . . . . . . . . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 44
A.7. L7-7: Network Access Authentication . . . . . . . . . . . 45
A.8. L7-8: Network Topology Unawareness . . . . . . . . . . . . 45
A.9. L7-9: Discovery Mechanism . . . . . . . . . . . . . . . . 45
A.10. L7-10: PIDF-LO Creation . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 48
1. Introduction 1. Introduction
The location of a Device is information that is useful for a number The location of a Device is information that is useful for a number
of applications. The L7 Location Configuration Protocol (LCP) of applications. The L7 Location Configuration Protocol (LCP)
problem statement and requirements document problem statement and requirements document
[I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which a
Device might rely on its access network to provide location Device might rely on its access network to provide location
information. The Location Information Server (LIS) service applies information. The Location Information Server (LIS) service applies
to access networks employing both wired technology (e.g. DSL, Cable) to access networks employing both wired technology (e.g. DSL, Cable)
skipping to change at page 6, line 48 skipping to change at page 6, line 48
document. An example of an APP interface between a device and LR can document. An example of an APP interface between a device and LR can
be found in the SIP Location Conveyance document be found in the SIP Location Conveyance document
[I-D.ietf-sip-location-conveyance]. [I-D.ietf-sip-location-conveyance].
4. Protocol Overview 4. Protocol Overview
A device uses the HELD protocol to retrieve its location either A device uses the HELD protocol to retrieve its location either
directly in the form of a PIDF-LO document (by value) and indirectly directly in the form of a PIDF-LO document (by value) and indirectly
as a Location URI (by reference). The security necessary to ensure as a Location URI (by reference). The security necessary to ensure
the accuracy, privacy and confidentiality of the device's location is the accuracy, privacy and confidentiality of the device's location is
described in the Security Considerations (Section 10). described in the Security Considerations (Section 9).
As described in the L7 LCP problem statement and requirements As described in the L7 LCP problem statement and requirements
[I-D.ietf-geopriv-l7-lcp-ps], the Device must first discover the URI [I-D.ietf-geopriv-l7-lcp-ps], the Device must first discover the URI
for the LIS for sending the HELD protocol requests. The discovery for the LIS for sending the HELD protocol requests. The discovery
methods are specified in [I-D.ietf-geopriv-lis-discovery]. methods are specified in [I-D.ietf-geopriv-lis-discovery].
The LIS requires an identifier for the Device in order to determine The LIS requires an identifier for the Device in order to determine
the appropriate location to include in the location response message. the appropriate location to include in the location response message.
In this document, the IP address of the Device, as reflected by the In this document, the IP address of the Device, as reflected by the
source IP address in the location request message, is used as the source IP address in the location request message, is used as the
skipping to change at page 9, line 40 skipping to change at page 9, line 40
Messages are defined as XML documents. Messages are defined as XML documents.
The Location Request (locationRequest) message is described in The Location Request (locationRequest) message is described in
Section 5.2. A Location Request message from a Device indicates Section 5.2. A Location Request message from a Device indicates
whether location in the form of a PIDF-LO document (with specific whether location in the form of a PIDF-LO document (with specific
type(s) of location) and/or Location URI(s) should be returned. The type(s) of location) and/or Location URI(s) should be returned. The
LIS replies with a locationResponse message, including a PIDF-LO LIS replies with a locationResponse message, including a PIDF-LO
document and/or one or more Location URIs in case of success. In the document and/or one or more Location URIs in case of success. In the
case of an error, the LIS replies with an error message. case of an error, the LIS replies with an error message.
A MIME type "application/held+xml" is registered in Section 12.3 to A MIME type "application/held+xml" is registered in Section 11.3 to
distinguish HELD messages from other XML document bodies. This distinguish HELD messages from other XML document bodies. This
specification follows the recommendations and conventions described specification follows the recommendations and conventions described
in [RFC3023], including the naming convention of the type ('+xml' in [RFC3023], including the naming convention of the type ('+xml'
suffix) and the usage of the 'charset' parameter. suffix) and the usage of the 'charset' parameter.
Section 6 contains a more thorough description of the protocol Section 6 contains a more thorough description of the protocol
parameters, valid values, and how each should be handled. Section 7 parameters, valid values, and how each should be handled. Section 7
contains a more specific definition of the structure of these contains a more specific definition of the structure of these
messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028]. messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028].
skipping to change at page 10, line 20 skipping to change at page 10, line 20
This means that any protocol can be used to transport this protocol This means that any protocol can be used to transport this protocol
providing that it can provide a few basic features: providing that it can provide a few basic features:
o The HELD protocol doesn't provide any mechanisms that enable o The HELD protocol doesn't provide any mechanisms that enable
detection of missing messages and retransmission, thus the detection of missing messages and retransmission, thus the
protocol must have acknowledged delivery. protocol must have acknowledged delivery.
o The HELD protocol is a request/response protocol, thus the o The HELD protocol is a request/response protocol, thus the
protocol must be able to correlate a response with a request. protocol must be able to correlate a response with a request.
o The HELD protocol REQUIRES that the underlying transport provide o The HELD protocol REQUIRES that the underlying transport provide
authentication, confidentiality, and protection against authentication, confidentiality, and protection against
modification per Section 10.3. modification per Section 9.3.
This document describes the use of a combination of HTTP [RFC2616], This document describes the use of a combination of HTTP [RFC2616],
TLS [RFC4346] and TCP [RFC0793] in Section 9. TLS [RFC4346] and TCP [RFC0793] in Section 8.
5.2. Location Request 5.2. Location Request
A location request message is sent from the Device to the LIS when A location request message is sent from the Device to the LIS when
the Device requires its own LI. The type of LI that a Device the Device requires its own LI. The type of LI that a Device
requests is determined by the type of LI that is included in the requests is determined by the type of LI that is included in the
"locationType" element. "locationType" element.
The location request is made by sending a document formed of a The location request is made by sending a document formed of a
"locationRequest" element. The LIS uses the source IP address of the "locationRequest" element. The LIS uses the source IP address of the
skipping to change at page 15, line 25 skipping to change at page 15, line 25
additional, human-readable information about the result of the additional, human-readable information about the result of the
request. This message MAY be included in any language, which SHOULD request. This message MAY be included in any language, which SHOULD
be indicated by the "xml:lang", attribute. The default language is be indicated by the "xml:lang", attribute. The default language is
assumed to be English. assumed to be English.
6.5. "locationUriSet" Parameter 6.5. "locationUriSet" Parameter
The "locationUriSet" element, received in a "locationResponse" The "locationUriSet" element, received in a "locationResponse"
message MAY contain any number of "locationURI" elements. It is message MAY contain any number of "locationURI" elements. It is
RECOMMENDED that the LIS allocate a Location URI for each scheme that RECOMMENDED that the LIS allocate a Location URI for each scheme that
it supports and that each scheme is present only once. The helds: it supports and that each scheme is present only once. URI schemes
URI scheme as defined in Section 8 is one possible scheme for the and their secure variants, such as http and https, MUST be regarded
"locationURI" element. URI schemes and their secure variants, such as two separate schemes.
as http and https, MUST be regarded as two separate schemes.
If a "locationUriSet" element is received in a "locationResponse" If a "locationUriSet" element is received in a "locationResponse"
message, it MUST contain an "expires" attribute, which defines the message, it MUST contain an "expires" attribute, which defines the
length of time for which the set of "locationURI" elements are valid. length of time for which the set of "locationURI" elements are valid.
6.5.1. "locationURI" Parameter 6.5.1. "locationURI" Parameter
The "locationURI" element includes a single Location URI. Each The "locationURI" element includes a single Location URI. In order
Location URI that is allocated by the LIS is unique to the device for a URI of any particular scheme to be included in a response,
that is requesting it. there MUST be a specification that defines how that URI can be used
to retrieve location information. The details of the protocol for
dereferencing must meet the location dereference protocol
requirements as specified in [I-D.ietf-geopriv-lbyr-requirements] and
are outside the scope of this base HELD specification.
At the time the location URI is provided in the response, there is Each Location URI that is allocated by the LIS is unique to the
not necessarily a binding to a specific location type. The specific device that is requesting it. At the time the location URI is
location type is determined at the time of dereference. The provided in the response, there is no binding to a specific location
dereference protocol [I-D.winterbottom-geopriv-deref-protocol] allows type and the location URI is totally independent of the specific type
the dereferencer to specify the type of location they prefer. The of location it might reference. The specific location type is
use of the location URI as defined in this base HELD document is determined at the time of dereference.
totally independent of the specific type of location it might
reference.
A "locationURI" SHOULD NOT contain any information that could be used A "locationURI" SHOULD NOT contain any information that could be used
to identify the Device or Target. Thus, it is RECOMMENDED that the to identify the Device or Target. Thus, it is RECOMMENDED that the
"locationURI" element contain a public address for the LIS and an "locationURI" element contain a public address for the LIS and an
anonymous identifier, such as a local identifier or unlinked anonymous identifier, such as a local identifier or unlinked
pseudonym. Further guidelines to ensure the the privacy and pseudonym. Further guidelines to ensure the the privacy and
confidentiality of the information contained in the confidentiality of the information contained in the
"locationResponse" message, including the "locationURI", are included "locationResponse" message, including the "locationURI", are included
in Section 10.3. in Section 9.3.
6.5.2. "expires" Parameter 6.5.2. "expires" Parameter
The "expires" attribute is only included in a "locationResponse" The "expires" attribute is only included in a "locationResponse"
message when a "locationUriSet" element is included. The "expires" message when a "locationUriSet" element is included. The "expires"
attribute indicates the date/time at which the Location URIs provided attribute indicates the date/time at which the Location URIs provided
by the LIS will expire. The "expires" attribute does not define the by the LIS will expire. The "expires" attribute does not define the
length of time a location received by dereferencing the location URI length of time a location received by dereferencing the location URI
will be valid. The "expires" attribute is RECOMMENDED not to exceed will be valid. The "expires" attribute is RECOMMENDED not to exceed
24 hours and SHOULD be a minimum of several minutes. 24 hours and SHOULD be a minimum of several minutes.
skipping to change at page 18, line 8 skipping to change at page 18, line 8
</xs:simpleType> </xs:simpleType>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger"> <xs:restriction base="xs:nonNegativeInteger">
<xs:minInclusive value="0"/> <xs:minInclusive value="0"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:union> </xs:union>
</xs:simpleType> </xs:simpleType>
<!-- Location Type --> <!-- Location Type -->
<!-- Location Type -->
<xs:simpleType name="locationTypeBase"> <xs:simpleType name="locationTypeBase">
<xs:union> <xs:union>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="any"/> <xs:enumeration value="any"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="held:locationTypeList">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="locationTypeList">
<xs:list> <xs:list>
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:enumeration value="civic"/> <xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/> <xs:enumeration value="geodetic"/>
<xs:enumeration value="locationURI"/> <xs:enumeration value="locationURI"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:list> </xs:list>
</xs:simpleType> </xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:complexType name="locationTypeType"> <xs:complexType name="locationTypeType">
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="held:locationTypeBase"> <xs:extension base="held:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean" <xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/> use="optional" default="false"/>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
skipping to change at page 20, line 11 skipping to change at page 20, line 18
</xs:sequence> </xs:sequence>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="locationRequest" <xs:element name="locationRequest"
type="held:locationRequestType"/> type="held:locationRequestType"/>
</xs:schema> </xs:schema>
8. HELD URI Definitions 8. HTTP/HTTPS Binding
This section defines the schemas for heldref: and heldrefs: URIs.
The heldrefs: URI is used in the case where TLS provides secure
transport for HELD messages transported by HTTPS as defined in
Section 9. These URI schemas are just two possible URI schemas for
the "locationURI" element, described in Section 6.5.1, in a HELD
"locationResponse " message. The "locationURI" indicates to the
Device where to obtain the actual location information for a Target.
There are other uses of the heldref:/heldrefs: URIs, such as the use
for dereferencing as described in
[I-D.winterbottom-geopriv-deref-protocol]. Thus, the usages of the
heldref:/heldrefs: URIs described in this document are not intended
to limit the applicability of the heldref:/heldrefs: URIs to other
relevant interfaces, but are necessarily restricted in scope in this
document to the use for the base HELD protocol.
8.1. heldref: URI Definition
The heldref: URI is defined using a subset of the URI schema
specified in Appendix A. of RFC3986 [RFC3986] and the associated URI
Guidelines [RFC4395] per the following ABNF syntax:
HELDREF-URI="helds://" host[ ":" port ][ path-absolute ][ "?" query ]
The following summarizes the primary elements comprising the HELDREF-
URI:
host: As defined in RFC3986 [RFC3986]
port: As defined in RFC3986 [RFC3986]. There is no unique port
associated with location URIs.
path-absolute As defined in RFC3986 [RFC3986].
query: As defined in RFC3986 [RFC3986]. This allows for additional
information associated with the URIs such as a unique anonymous
identifier for the Device associated with the target location.
The heldref: URI is not intended to be human-readable text, therefore
it is encoded entirely in US-ASCII. The following are examples of
heldrefs: URIs:
heldref://ls.example.com:49152/thisLocation?token=xyz987
heldref://ls.example.com:5432/THISLOCATION?foobar=abc123
heldref://ls.example.com:5432/THISlocation?foobar=ABC123
heldref://ls.example.com:9876/civic
Other than the "host" portion, URIs are case sensitive and exact
equivalency is required for HELDREF-URI comparisons. For example, in
the above examples, although similar in information, the 2nd and 3rd
URIs are not considered equivalent.
It is important to note that the heldref:URI, contained in a
"locationURI" element in a HELD locationResponse message, is only
valid for the length of time indicated by the "expires" attribute.
8.2. heldrefs: URI Definition
The heldrefs: URI is defined using a subset of the URI schema
specified in Appendix A. of RFC3986 [RFC3986] and the associated URI
Guidelines [RFC4395] per the following ABNF syntax:
HELDREFS-URI="heldrefs://"host[ ":" port ][ path-absolute ][ "?" query ]
The following summarizes the primary elements comprising the
HELDREFS-URI:
host: As defined in RFC3986 [RFC3986]
port: As defined in RFC3986 [RFC3986]. There is no unique port
associated with location URIs.
path-absolute As defined in RFC3986 [RFC3986].
query: As defined in RFC3986 [RFC3986]. This allows for additional
information associated with the URIs such as a unique anonymous
identifier for the Device associated with the target location.
The heldrefs: URI is not intended to be human-readable text,
therefore it is encoded entirely in US-ASCII. The following are
examples of heldrefs: URIs:
heldrefs://ls.example.com:49152/thisLocation?token=xyz987
heldrefs://ls.example.com:5432/THISLOCATION?foobar=abc123
heldrefs://ls.example.com:5432/THISlocation?foobar=ABC123
heldrefs://ls.example.com:9876/civic
Other than the "host" portion, URIs are case sensitive and exact
equivalency is required for HELDREFS-URI comparisons. For example,
in the above examples, although similar in information, the 2nd and
3rd URIs are not considered equivalent.
It is important to note that the heldrefs: URI, contained in a
"locationURI" element in a HELD locationResponse message, is only
valid for the length of time indicated by the "expires" attribute.
9. HTTP/HTTPS Binding
This section describes the use of HTTP [RFC2616] and HTTPS [RFC2818] This section describes the use of HTTP [RFC2616] and HTTPS [RFC2818]
as transport mechanisms for the HELD protocol, which all conforming as transport mechanisms for the HELD protocol, which all conforming
implementations MUST support. implementations MUST support.
The request is carried in the body of an HTTP/HTTPS POST request. The request is carried in the body of an HTTP/HTTPS POST request.
The MIME type of both request and response bodies should be The MIME type of both request and response bodies should be
"application/held+xml". This should be reflected in the HTTP "application/held+xml". This should be reflected in the HTTP
Content-Type and Accept header fields. Content-Type and Accept header fields.
skipping to change at page 23, line 11 skipping to change at page 20, line 44
allows the LIS to control any caching with the "expires" parameter. allows the LIS to control any caching with the "expires" parameter.
The HTTP/HTTPS status code MUST indicate a 2xx series response for The HTTP/HTTPS status code MUST indicate a 2xx series response for
all HELD locationResponse and error messages. all HELD locationResponse and error messages.
The use of HTTP/HTTPS also includes a default behaviour, which is The use of HTTP/HTTPS also includes a default behaviour, which is
triggered by a GET request, or a POST with no request body. If triggered by a GET request, or a POST with no request body. If
either of these queries are received, the LIS MUST attempt to provide either of these queries are received, the LIS MUST attempt to provide
either a PIDF-LO document or a Location URI, as if the request was a either a PIDF-LO document or a Location URI, as if the request was a
location request. location request.
The implementation of HTTPS as a transport mechanism MUST implement Implementation of HELD that implement HTTP transport MUST implement a
TLS as described in [RFC2818]. TLS provides message integrity and transport over HTTPS [RFC2818]. TLS provides message integrity and
confidentiality between Device and LIS. The LIS MUST implement the confidentiality between Device and LIS. The LIS MUST implement the
server authentication method described in [RFC2818]. The device uses server authentication method described in [RFC2818]. The device uses
the URI obtained during LIS discovery to authenticate the server. the URI obtained during LIS discovery to authenticate the server.
When TLS is used, the Device SHOULD fail a request if server The details of this authentication method are provided in section 3.1
authentication fails, except in the event of an emergency. of [RFC2818]. When TLS is used, the Device SHOULD fail a request if
server authentication fails, except in the event of an emergency.
10. Security Considerations 9. Security Considerations
HELD is a location acquisition protocol whereby the a client requests HELD is a location acquisition protocol whereby the a client requests
its location from a LIS. Specific requirements and security its location from a LIS. Specific requirements and security
considerations for location acquisition protocols are provided in considerations for location acquisition protocols are provided in
[I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security [I-D.ietf-geopriv-l7-lcp-ps]. An in-depth discussion of the security
considerations applicable to the use of Location URIs and by considerations applicable to the use of Location URIs and by
reference provision of LI is included in reference provision of LI is included in
[I-D.ietf-geopriv-lbyr-requirements]. [I-D.ietf-geopriv-lbyr-requirements].
By using the HELD protocol, the client and the LIS expose themselves By using the HELD protocol, the client and the LIS expose themselves
skipping to change at page 24, line 6 skipping to change at page 21, line 42
and the client. and the client.
Of these, only the second, third and the fifth are within the scope Of these, only the second, third and the fifth are within the scope
of this document. The first step is based on either manual of this document. The first step is based on either manual
configuration or on the LIS discovery defined in configuration or on the LIS discovery defined in
[I-D.ietf-geopriv-lis-discovery], in which appropriate security [I-D.ietf-geopriv-lis-discovery], in which appropriate security
considerations are already discussed. The fourth step is dependent considerations are already discussed. The fourth step is dependent
on the specific positioning capabilities of the LIS, and is thus on the specific positioning capabilities of the LIS, and is thus
outside the scope of this document. outside the scope of this document.
10.1. Assuring that the proper LIS has been contacted 9.1. Assuring that the proper LIS has been contacted
This document assumes that the LIS to be contacted is identified This document assumes that the LIS to be contacted is identified
either by an IP address or a domain name, as is the case for a LIS either by an IP address or a domain name, as is the case for a LIS
discovered as described in LIS Discovery discovered as described in LIS Discovery
[I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is [I-D.ietf-geopriv-lis-discovery]. When the HELD transaction is
conducted using TLS [RFC4346], the LIS can authenticate its identity, conducted using TLS [RFC4346], the LIS can authenticate its identity,
either as a domain name or as an IP address, to the client by either as a domain name or as an IP address, to the client by
presenting a certificate containing that identifier as a presenting a certificate containing that identifier as a
subjectAltName (i.e., as an iPAddress or dNSName, respectively). In subjectAltName (i.e., as an iPAddress or dNSName, respectively). In
the case of the HTTP binding described above, this is exactly the the case of the HTTP binding described above, this is exactly the
authentication described by TLS [RFC2818]. Any binding of HELD MUST authentication described by TLS [RFC2818]. Any binding of HELD MUST
be capable of being transacted over TLS so that the client can be capable of being transacted over TLS so that the client can
request the above authentication, and a LIS implementation for a request the above authentication, and a LIS implementation for a
binding MUST include this feature. Note that in order for the binding MUST include this feature. Note that in order for the
presented certificate to be valid at the client, the client must be presented certificate to be valid at the client, the client must be
able to validate the certificate. In particular, the validation path able to validate the certificate. In particular, the validation path
of the certificate must end in one of the client's trust anchors, of the certificate must end in one of the client's trust anchors,
even if that trust anchor is the LIS certificate itself. even if that trust anchor is the LIS certificate itself.
10.2. Protecting responses from modification 9.2. Protecting responses from modification
In order to prevent that response from being modified en route, In order to prevent that response from being modified en route,
messages must be transmitted over an integrity-protected channel. messages must be transmitted over an integrity-protected channel.
When the transaction is being conducted over TLS (a required feature When the transaction is being conducted over TLS (a required feature
per Section 10.1), the channel will be integrity protected by per Section 9.1), the channel will be integrity protected by
appropriate ciphersuites. When TLS is not used, this protection will appropriate ciphersuites. When TLS is not used, this protection will
vary depending on the binding; in most cases, without protection from vary depending on the binding; in most cases, without protection from
TLS, the response will not be protected from modification en route. TLS, the response will not be protected from modification en route.
10.3. Privacy and Confidentiality 9.3. Privacy and Confidentiality
Location information returned by the LIS must be protected from Location information returned by the LIS must be protected from
access by unauthorized parties, whether those parties request the access by unauthorized parties, whether those parties request the
location from the LIS or intercept it en route. As in section location from the LIS or intercept it en route. As in section
Section 10.2, transactions conducted over TLS with appropriate Section 9.2, transactions conducted over TLS with appropriate
ciphersuites are protected from access by unauthorized parties en ciphersuites are protected from access by unauthorized parties en
route. Conversely, in most cases, when not conducted over TLS, the route. Conversely, in most cases, when not conducted over TLS, the
response will be accessible while en route from the LIS to the response will be accessible while en route from the LIS to the
requestor. requestor.
Because HELD is an LCP and identifies clients and targets by IP Because HELD is an LCP and identifies clients and targets by IP
addresses, a requestor is authorized to access location for an IP addresses, a requestor is authorized to access location for an IP
address only if it is the holder of that IP address. The LIS MUST address only if it is the holder of that IP address. The LIS MUST
verify that the client is the target of the returned location, i.e., verify that the client is the target of the returned location, i.e.,
the LIS MUST NOT provide location to other entities than the target. the LIS MUST NOT provide location to other entities than the target.
skipping to change at page 25, line 47 skipping to change at page 23, line 35
in it no longer being able to determine the location of the in it no longer being able to determine the location of the
Device, then all location URIs for that Device SHOULD be Device, then all location URIs for that Device SHOULD be
invalidated. invalidated.
The above measures are dependent on network configuration, which The above measures are dependent on network configuration, which
SHOULD be considered. For instance, in a fixed internet access, SHOULD be considered. For instance, in a fixed internet access,
providers may be able to restrict the allocation of IP addresses to a providers may be able to restrict the allocation of IP addresses to a
single physical line, ensuring that spoofing is not possible; in such single physical line, ensuring that spoofing is not possible; in such
an environment, additional measures may not be necessary. an environment, additional measures may not be necessary.
11. Examples 10. Examples
The following sections provide basic HTTP/HTTPS examples, a simple The following sections provide basic HTTP/HTTPS examples, a simple
location request example and a location request for multiple location location request example and a location request for multiple location
types example along with the relevant location responses. To focus types example along with the relevant location responses. To focus
on important portions of messages, the examples in Section 11.2 and on important portions of messages, the examples in Section 10.2 and
Section 11.3 do not show HTTP/HTTPS headers or the XML prologue. In Section 10.3 do not show HTTP/HTTPS headers or the XML prologue. In
addition, sections of XML not relevant to the example are replaced addition, sections of XML not relevant to the example are replaced
with comments. with comments.
11.1. HTTPS Example Messages 10.1. HTTPS Example Messages
The examples in this section show a complete HTTPS message that The examples in this section show a complete HTTPS message that
includes the HELD request or response document. includes the HELD request or response document.
This example shows the most basic request for a LO. This uses the This example shows the most basic request for a LO. This uses the
GET feature described by the HTTP binding. This example assumes that GET feature described by the HTTP binding.
the LIS service exists at the URL "https://lis.example.com/location".
GET heldrefs://lis.example.com:49152/location HTTP/1.1 GET https://lis.example.com:49152/location HTTP/1.1
Accept:application/held+xml, Accept:application/held+xml,
application/xml;q=0.8, application/xml;q=0.8,
text/xml;q=0.7 text/xml;q=0.7
Accept-Charset: UTF-8,* Accept-Charset: UTF-8,*
The GET request is exactly identical to a minimal POST request that The GET request is exactly identical to a minimal POST request that
includes an empty "locationRequest" element. includes an empty "locationRequest" element.
POST heldrefs://lis.example.com:49152/location HTTP/1.1 POST https://lis.example.com:49152/location HTTP/1.1
Accept: application/held+xml, Accept: application/held+xml,
application/xml;q=0.8, application/xml;q=0.8,
text/xml;q=0.7 text/xml;q=0.7
Accept-Charset: UTF-8,* Accept-Charset: UTF-8,*
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 87 Content-Length: 87
<?xml version="1.0"?> <?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Since neither of these requests includes a "locationType" element, Since neither of these requests includes a "locationType" element,
skipping to change at page 28, line 7 skipping to change at page 26, line 7
<method>Wiremap</method> <method>Wiremap</method>
</geopriv> </geopriv>
</status> </status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp> <timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
The error response to either of these requests is an error document. The error response to either of these requests is an error document.
The following response shows an example error response. The following response shows an example error response.
HTTP/1.x 200 OK HTTP/1.1 200 OK
Server: Example LIS Server: Example LIS
Expires: Tue, 10 Jan 2006 03:49:20 GMT Expires: Tue, 10 Jan 2006 03:49:20 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 135 Content-Length: 135
<?xml version="1.0"?> <?xml version="1.0"?>
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown" code="locationUnknown"
message="Unable to determine location"/> message="Unable to determine location"/>
11.2. Simple Location Request Example 10.2. Simple Location Request Example
The location request shown below doesn't specify any location types The location request shown below doesn't specify any location types
or response time. or response time.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
The example response to this location request contains a list of The example response to this location request contains a list of
Location URIs. Location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00"> <locationUriSet expires="2006-01-01T13:00:00">
<locationURI>heldrefs://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com <locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
</locationResponse> </locationResponse>
An error response to this location request is shown below: An error response to this location request is shown below:
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown" code="locationUnknown"
message="Location not available"/> message="Location not available"/>
11.3. Location Request Example for Multiple Location Types 10.3. Location Request Example for Multiple Location Types
The following Location Request message includes a request for The following Location Request message includes a request for
geodetic, civic and any Location URIs. geodetic, civic and any Location URIs.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true"> <locationType exact="true">
geodetic geodetic
civic civic
locationURI locationURI
</locationType> </locationType>
</locationRequest> </locationRequest>
The corresponding Location Response message includes the requested The corresponding Location Response message includes the requested
location information, including two location URIs. location information, including two location URIs.
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2006-01-01T13:00:00"> <locationUriSet expires="2006-01-01T13:00:00">
<locationURI>helds://ls.example.com:9768/357yc6s64ceyoiuy5ax3o <locationURI>https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
<locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: <locationURI>sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
<presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10" <presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
entity="pres:ae3be8585902e2253ce2@10.102.23.9"> entity="pres:ae3be8585902e2253ce2@10.102.23.9">
<tuple id="lisLocation"> <tuple id="lisLocation">
<status> <status>
<geopriv> <geopriv>
<location-info> <location-info>
skipping to change at page 30, line 35 skipping to change at page 28, line 35
</retention-expiry> </retention-expiry>
</usage-rules> </usage-rules>
<method>Wiremap</method> <method>Wiremap</method>
</geopriv> </geopriv>
</status> </status>
<timestamp>2007-05-24T12:35:02+10:00</timestamp> <timestamp>2007-05-24T12:35:02+10:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
12. IANA Considerations 11. IANA Considerations
This document requires several IANA registrations detailed in the This document requires several IANA registrations detailed in the
following sections. following sections.
12.1. URN Sub-Namespace Registration for 11.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held urn:ietf:params:xml:ns:geopriv:held
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held", per the guidelines in "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held URI: urn:ietf:params:xml:ns:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com). (geopriv@ietf.org), Mary Barnes (mary.barnes@nortel.com).
XML: XML:
skipping to change at page 31, line 26 skipping to change at page 29, line 26
<body> <body>
<h1>Namespace for HELD Messages</h1> <h1>Namespace for HELD Messages</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held</h2> <h2>urn:ietf:params:xml:ns:geopriv:held</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.] with the RFC number for this specification.]
<p>See RFCXXXX</p> <p>See RFCXXXX</p>
</body> </body>
</html> </html>
END END
12.2. XML Schema Registration 11.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held URI: urn:ietf:params:xml:schema:geopriv:held
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
Mary Barnes (mary.barnes@nortel.com). Mary Barnes (mary.barnes@nortel.com).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 7 of this document. Section 7 of this document.
12.3. MIME Media Type Registration for 'application/held+xml' 11.3. MIME Media Type Registration for 'application/held+xml'
This section registers the "application/held+xml" MIME type. This section registers the "application/held+xml" MIME type.
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/held+xml Subject: Registration of MIME media type application/held+xml
MIME media type name: application MIME media type name: application
MIME subtype name: held+xml MIME subtype name: held+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Default is Indicates the character encoding of enclosed XML. Default is
skipping to change at page 32, line 30 skipping to change at page 30, line 30
File extension(s): .xml File extension(s): .xml
Macintosh File Type Code(s): (none) Macintosh File Type Code(s): (none)
Person & email address to contact for further information: Mary Person & email address to contact for further information: Mary
Barnes <mary.barnes@nortel.com> Barnes <mary.barnes@nortel.com>
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author/Change controller: The IETF Author/Change controller: The IETF
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml [RFC3023], and many of the considerations application/xml [RFC3023], and many of the considerations
described there also apply to application/held+xml. described there also apply to application/held+xml.
12.4. Error code Registry 11.4. Error code Registry
This document requests that the IANA create a new registry for the This document requests that the IANA create a new registry for the
HELD protocol including an initial registry for error codes. The HELD protocol including an initial registry for error codes. The
error codes are included in HELD error messages as described in error codes are included in HELD error messages as described in
Section 6.3 and defined in the schema in the 'codeType' token in the Section 6.3 and defined in the schema in the 'codeType' token in the
XML schema in (Section 7) XML schema in (Section 7)
The following summarizes the requested registry: The following summarizes the requested registry:
Related Registry: Geopriv HELD Registries, Error codes for HELD Related Registry: Geopriv HELD Registries, Error codes for HELD
skipping to change at page 33, line 36 skipping to change at page 31, line 36
provide LI of the type or types requested. This code is used when provide LI of the type or types requested. This code is used when
the "exact" attribute on the "locationType" parameter is set to the "exact" attribute on the "locationType" parameter is set to
"true". "true".
notLocatable: This code indicates that the LIS is unable to locate notLocatable: This code indicates that the LIS is unable to locate
the Device, and that the Device MUST NOT make further attempts to the Device, and that the Device MUST NOT make further attempts to
retrieve LI from this LIS. This error code is used to indicate retrieve LI from this LIS. This error code is used to indicate
that the Device is outside the access network served by the LIS; that the Device is outside the access network served by the LIS;
for instance, the VPN and NAT scenarios discussed in for instance, the VPN and NAT scenarios discussed in
Section 4.1.2. Section 4.1.2.
12.5. URI Registrations 12. Contributors
The following summarizes the information necessary to register the
heldref: and heldrefs: URIs. [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number for this specification in the
following list.]
12.5.1. heldref: URI Registration
URI Scheme Name: heldref
Status: permanent
URI Scheme syntax: See section Section 8.1.
URI Scheme Semantics: The heldref: URI is intended to be used as a
reference to a location object or a location information server.
Further detail is provided in Section 8 of RFC XXXX.
Encoding Considerations: The heldref: URI is not intended to be
human-readable text, therefore they are encoded entirely in US-
ASCII.
Applications/protocols that use this URI scheme: The HELD protocol
described in RFC XXXX and the GEOPRIV Location De-reference
Protocol [I-D.winterbottom-geopriv-deref-protocol].
Interoperability considerations: This URI may be used as a parameter
for the HELD protocol in the locationResponse message. This URI
is also used as an input parameter for the GEOPRIV Location De-
reference Protocol [I-D.winterbottom-geopriv-deref-protocol].
Refer to Section 8 in RFC XXXX for further detail and a particular
example on the lack of permanence of a specific heldref: URI and
thus the importance of using these URIs only within the specific
contexts outlined in the references.
Security considerations: Section 10 in RFC XXXX addresses the
necessary security associated with the transport of location
information between a Device and the LIS to ensure the privacy and
integrity of the heldref: URI. Section 6.5.1 in RFC XXXX also
recommends that the URI be allocated such that it does not reveal
any detail at all about the content of the PIDF-LO that it may
indirectly reference.
Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
Barnes (mary.barnes@nortel.com).
Author/Change controller: This scheme is registered under the IETF
tree. As such, IETF maintains change control.
References: RFC XXXX, GEOPRIV Location De-reference Protocol
[I-D.winterbottom-geopriv-deref-protocol]
12.5.2. heldrefs: URI Registration
URI Scheme Name: heldrefs
Status: permanent
URI Scheme syntax: See section Section 8.2.
URI Scheme Semantics: The heldrefs: URI is intended to be used as a
reference to a location object or a location information server.
Further detail is provided in Section 8 of RFC XXXX.
Encoding Considerations: The HELDS: URI is not intended to be human-
readable text, therefore they are encoded entirely in US-ASCII.
Applications/protocols that use this URI scheme: The HELD protocol
described in RFC XXXX and the GEOPRIV Location De-reference
Protocol [I-D.winterbottom-geopriv-deref-protocol].
Interoperability considerations: This URI may be used as a parameter
for the HELD protocol in the locationResponse message. This URI
is also used as an input parameter for the GEOPRIV Location De-
reference Protocol [I-D.winterbottom-geopriv-deref-protocol].
Refer to Section 8 in RFC XXXX for further detail and a particular
example on the lack of permanence of a specific heldrefs: URI and
thus the importance of using these URIs only within the specific
contexts outlined in the references.
Security considerations: Section 10 in RFC XXXX addresses the
necessary security associated with the transport of location
information between a Device and the LIS to ensure the privacy and
integrity of the heldrefs: URI. Section 6.5.1 in RFC XXXX also
recommends that the URI be allocated such that it does not reveal
any detail at all about the content of the PIDF-LO that it may
indirectly reference.
Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Mary
Barnes (mary.barnes@nortel.com).
Author/Change controller: This scheme is registered under the IETF
tree. As such, IETF maintains change control.
References: RFC XXXX, GEOPRIV Location De-reference Protocol
[I-D.winterbottom-geopriv-deref-protocol]
13. Contributors
James Winterbottom, Martin Thomson and Barbara Stark are the authors James Winterbottom, Martin Thomson and Barbara Stark are the authors
of the original document, from which this WG document was derived. of the original document, from which this WG document was derived.
Their contact information is included in the Author's address Their contact information is included in the Author's address
section. In addition, they also contributed to the WG document, section. In addition, they also contributed to the WG document,
including the XML schema. including the XML schema.
14. Acknowledgements 13. Acknowledgements
The author/contributors would like to thank the participants in the The author/contributors would like to thank the participants in the
GEOPRIV WG and the following people for their constructive input and GEOPRIV WG and the following people for their constructive input and
feedback on this document (in alphabetical order): Nadine Abbott, feedback on this document (in alphabetical order): Nadine Abbott,
Eric Arolick, Richard Barnes (in particular the security section), Eric Arolick, Richard Barnes (in particular the security section),
Peter Blatherwick, Ben Campbell, Guy Caron, Martin Dawson, Lisa Peter Blatherwick, Ben Campbell, Guy Caron, Martin Dawson, Lisa
Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil Dusseault, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil
Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall, Justusson, Tat Lam, Marc Linsner, Patti McCalmont, Roger Marshall,
Perry Prozeniuk, Carl Reed, Eric Rescorla, Brian Rosen, John Perry Prozeniuk, Carl Reed, Julian Reschke, Eric Rescorla, Brian
Schnizlein, Shida Schubert, Henning Schulzrinne, Ed Shrum, Doug Rosen, John Schnizlein, Shida Schubert, Henning Schulzrinne, Ed
Stuard, Hannes Tschofenig and Karl Heinz Wolf. Shrum, Doug Stuard, Hannes Tschofenig and Karl Heinz Wolf.
15. Changes since last Version 14. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from WG 08 to 09 (Post-IETF LC: continued resolution of sec-
dir and gen-art review comments, along with apps-area feedback):
1) Removed heldref/heldrefs URIs, including fixing examples (which
were buggy anyways).
2) Clarified text for locationURI - specifying that the deref
protocol must define or appropriately restrict and clarifying that
requirements for deref must be met and that deref details are out of
scope for this document.
3) Clarified text in security section for support of both HTTP/HTTPS.
4) Changed definition for Location Type to force the specification of
at least one location type.
Changes from WG 07 to 08 (IETF LC: sec-dir and gen-art review Changes from WG 07 to 08 (IETF LC: sec-dir and gen-art review
comments): comments):
1) Fix editorial nits: rearranging sections in 4.1 for readibility, 1) Fix editorial nits: rearranging sections in 4.1 for readibility,
etc. etc.
2) Added back text in Device and VPN section referencing DHCP and 2) Added back text in Device and VPN section referencing DHCP and
LLDP-MED when a VPN device serves as a LIS. LLDP-MED when a VPN device serves as a LIS.
3) Clarified the use of both HTTP and HTTPS. 3) Clarified the use of both HTTP and HTTPS.
skipping to change at page 40, line 26 skipping to change at page 37, line 11
8) Updated Location Response (section 6.3) to remove reference to 8) Updated Location Response (section 6.3) to remove reference to
context and discuss the used of a local identifier or unlinked context and discuss the used of a local identifier or unlinked
pseudonym in providing privacy/security. pseudonym in providing privacy/security.
9) Clarified that the source IP address in the request is used as the 9) Clarified that the source IP address in the request is used as the
identifier for the target/device for the HELD protocol as defined in identifier for the target/device for the HELD protocol as defined in
this document. this document.
10) Miscellaneous editorial clarifications. 10) Miscellaneous editorial clarifications.
16. References 15. References
16.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
skipping to change at page 41, line 8 skipping to change at page 37, line 40
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11
(work in progress), February 2008. (work in progress), February 2008.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Thompson, H., Maloney, M., Beech, D., and N. Mendelsohn, Maloney, M., Thompson, H., Mendelsohn, N., and D. Beech,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-01 (work in progress), draft-ietf-geopriv-lis-discovery-02 (work in progress),
June 2008. July 2008.
16.2. Informative References 15.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
skipping to change at page 42, line 30 skipping to change at page 39, line 15
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-10 (work in progress), draft-ietf-sip-location-conveyance-10 (work in progress),
February 2008. February 2008.
[I-D.winterbottom-geopriv-deref-protocol] [I-D.winterbottom-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "An HTTPS Location Thomson, M., and M. Dawson, "An HTTPS Location
Dereferencing Protocol Using HELD", Dereferencing Protocol Using HELD",
draft-winterbottom-geopriv-deref-protocol-01 (work in draft-winterbottom-geopriv-deref-protocol-02 (work in
progress), July 2008. progress), July 2008.
Appendix A. HELD Compliance to IETF LCP requirements Appendix A. HELD Compliance to IETF LCP requirements
This appendix describes HELD's compliance to the requirements This appendix describes HELD's compliance to the requirements
specified in the [I-D.ietf-geopriv-l7-lcp-ps]. specified in the [I-D.ietf-geopriv-l7-lcp-ps].
A.1. L7-1: Identifier Choice A.1. L7-1: Identifier Choice
"The L7 LCP MUST be able to carry different identifiers or MUST "The L7 LCP MUST be able to carry different identifiers or MUST
skipping to change at page 43, line 47 skipping to change at page 40, line 31
Access Network Provider. Requirements for resolving a reference to Access Network Provider. Requirements for resolving a reference to
location information are not discussed in this document." location information are not discussed in this document."
COMPLY COMPLY
HELD describes a location acquisition protocol between a Device and a HELD describes a location acquisition protocol between a Device and a
LIS. In the context of HELD, the LIS is within the Access Network. LIS. In the context of HELD, the LIS is within the Access Network.
Thus, HELD is independent of the business or trust relationship Thus, HELD is independent of the business or trust relationship
between the Application Service Provider (ASP) and the Access Network between the Application Service Provider (ASP) and the Access Network
Provider. Location acquisition using HELD is subject to the Provider. Location acquisition using HELD is subject to the
restrictions described in Section 10. restrictions described in Section 9.
A.4. L7-4: Layer 2 and Layer 3 Provider Relationship A.4. L7-4: Layer 2 and Layer 3 Provider Relationship
"The design of the GEOPRIV Layer 7 Location Configuration Protocol "The design of the GEOPRIV Layer 7 Location Configuration Protocol
MUST assume that there is a trust and business relationship between MUST assume that there is a trust and business relationship between
the L2 and the L3 provider. The L3 provider operates the LIS and the L2 and the L3 provider. The L3 provider operates the LIS and
needs to obtain location information from the L2 provider since this needs to obtain location information from the L2 provider since this
one is closest to the end host. If the L2 and L3 provider for the one is closest to the end host. If the L2 and L3 provider for the
same host are different entities, they cooperate for the purposes same host are different entities, they cooperate for the purposes
needed to determine end system locations." needed to determine end system locations."
 End of changes. 54 change blocks. 
282 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/