Internet DRAFT - draft-hdesinen-geopriv-pidflo-extn
draft-hdesinen-geopriv-pidflo-extn
Network Working Group H. Desineni
Internet-Draft Qualcomm
Expires: December 7, 2006 June 5, 2006
Location capabilities extension to pidf-lo object
draft-hdesinen-geopriv-pidflo-extn-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Presence Information Data Format Location Object (PIDF-LO)
specification provides a flexible and versatile means to represent
location information. The XML Schema presented in this memo extends
the 'geopriv' element defined in PIDF-LO with a complex XML element
called "device-loc-capabilities". A device can specify this element
inside a 'geopriv' element to communicate the position determination
methods and the location solutions supported by it to a location
server. Knowledge of the device's location capabilities can permit a
server along the path of an emergency voice over IP call to
Desineni Expires December 7, 2006 [Page 1]
Internet-Draft Extension to pidf-lo object June 2006
immediately initiate position determination update procedures when
needed.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Extensions to PIDF-LO to convey device location
capabilities . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. location-method . . . . . . . . . . . . . . . . . . . . . 6
4.2. location-signalling . . . . . . . . . . . . . . . . . . . 6
4.3. Schema Definition . . . . . . . . . . . . . . . . . . . . 7
5. Example usage of 'device-capabilities' element . . . . . . . . 8
6. IANA Considerations for the 'location-signalling' element
values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Desineni Expires December 7, 2006 [Page 2]
Internet-Draft Extension to pidf-lo object June 2006
1. Introduction
The Presence Information Data Format Location Object (PIDF-LO)
described in [2] is the IETF recommended way of encoding location
information and associated privacy policies. The current schema
defined for PIDF-LO lacks the ability to specify the supported
location methods and solutions by a device. The XML schema extension
described in this document extends the 'geopriv' element described in
PIDF-LO with a complex XML element called "device-loc-capabilities".
A device can use this element inside a 'geopriv' element to specify
the position determination methods and the location solutions
supported by it. This may be useful to enable the most appropriate
location method and solution to be selected by a network server for
any later positioning.
Desineni Expires December 7, 2006 [Page 3]
Internet-Draft Extension to pidf-lo object June 2006
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Desineni Expires December 7, 2006 [Page 4]
Internet-Draft Extension to pidf-lo object June 2006
3. Use Case
A device making an emergency call can use the "device-loc-
capabilities" extension to convey the position determination methods
and solutions supported by it. A location server can use this
information to communicate with the device and extract the position
details of the device. During an emergency call, a location server
may be able to determine that the currently provided location is
insufficient or out of date; knowing the client's capabilities allows
it to initiate the appropriate signalling to update the location
without wasting time trying mechanisms which the client does not
support or communicating with other network entities to determine the
client's capabilities.
Desineni Expires December 7, 2006 [Page 5]
Internet-Draft Extension to pidf-lo object June 2006
4. Extensions to PIDF-LO to convey device location capabilities
The XML Schema presented in Section 4.3 extends the 'geopriv' element
of PIDF with a complex element called 'device-loc-capabilities'.
There are two subelements that are encapsulated within device-loc-
capabilities: one for supported position determination methods, and
one for supported location solutions. Both of these subelements are
mandatory, and are described in subsequent sections. Each subelement
can be repeated multiple times to specify multiple position
determination methods and solutions supported by the device.
4.1. location-method
Each 'device-loc-capabilities' element MUST contain at least one
'location-method' element. Multiple 'location-method' elements can
be listed to convey multiple position determination methods supported
by the device.
An example of this element is:
<location-method> A-GPS </location-method>
The possible values of the 'location-method' element are enumerated
within an IANA registry. The IANA registry for these values is
located at http://www.iana.org/assignments/method-tokens.
Implementations MUST limit the use of this method to the values
listed by IANA.
4.2. location-signalling
Each 'device-loc-capabilities' element MUST contain at least one
'location-signalling' element. Multiple 'location-signalling'
elements can be listed to convey multiple location solutions
supported by the device. Each 'location-signalling' element
identifies a specific position determination signalling procedure as
specified by an appropriate standards body. The value combines a
descriptive name for the signalling procedure and where appropriate a
version for the published specification. The version identifier
specifies an initial version; it implicitly includes all subsequent
backwards-compatible updates, revisions, and versions.
An example of this element is:
<location-signalling> 3GPP_CP_UMTS_1.0 </location-signalling>
The possible values of the 'location-signalling' element are
enumerated within an IANA registry. Implementations MUST limit the
use of this method to the values limited by IANA. This document pre-
Desineni Expires December 7, 2006 [Page 6]
Internet-Draft Extension to pidf-lo object June 2006
populates the IANA registry with eight possible values; see section
Section 6 for more information.
4.3. Schema Definition
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:loccap"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:loccap"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="locap" type="tns:loccap"/>
<xs:complexType name="loccap">
<xs:sequence>
<xs:element name="location-method" type="tns:locMethod"
minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="location-signalling" type="tns:locSolution"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="locMethod">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="locSolution">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
Desineni Expires December 7, 2006 [Page 7]
Internet-Draft Extension to pidf-lo object June 2006
5. Example usage of 'device-capabilities' element
The following XML instance document is an example of the use of the
'device-capabilities' element.
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:lc="urn:ietf:params:xml:ns:pidf:geopriv10:loccap"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point1" srsName="epsg:4326">
<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
<lc:device-capabilities>
<lc:location-method> A-GPS </lc:location-method>
<lc:location-method> A-FLT </lc:location-method>
<lc:location-signalling>OMA_SUPL_1.0 </lc:location-signalling>
<lc:location-signalling>3GPP_CP_UMTS_1.0</lc:location-signalling>
</lc:device-capabilities>
</gp:geopriv>
</status>
<timestamp>2006-03-22T20:57:29Z</timestamp>
</tuple>
</presence>
Desineni Expires December 7, 2006 [Page 8]
Internet-Draft Extension to pidf-lo object June 2006
6. IANA Considerations for the 'location-signalling' element values
This document requests that the IANA create a new registry for the
values of 'location-signalling' element. The 'location-signalling'
element value is a text string. The value string specifies a
position determination signalling procedure and combines a
descriptive name for the signalling procedure and where appropriate a
version for the published specification. The version identifier
specifies an initial version; it implicitly includes all subsequent
backwards-compatible updates, revisions, and versions.
This section pre-registers eight new values for this element.
Following are the location signalling values to be registered with
the IANA.
o OMA_SUPL_1.0 (SUPL 1.0)
o OMA_SUPL_2.0 (SUPL 2.0)
o 3GPP_CP_GSM_1.0 (3GPP Control Plane for GSM starting with R98).
See [4]
o 3GPP_CP_GPRS_1.0 (3GPP Control Plane for GPRS starting with
Rel-5). See [5]
o 3GPP_CP_UMTS_1.0 (3GPP Control Plane for UMTS starting with R99).
See [6]
o 3GPP2_CP_Rev0 (3GPP2 Control Plane Revision 0). See [7]
o 3GPP2_UP_X.S0024_Rev0 (3GPP2 User Plane X.S0024 Revision 0). See
[8]
o 3GPP2_UP_V1_V2 (3GPP2 User Plane V1/V2). See [9]
Further entries may be registered following the "Specification
Required" rules as defined in RFC 2434 [3]. For each new
registration, it is mandatory that a permanent, stable, and publicly
accessible document exists.
New values for the 'location-signalling' element SHOULD NOT be
registered just because an updated version of the referenced
specification is published. New values SHOULD only be registered
when the new version is not backwards compatible with an existing
registered value.
This document does not require IANA to assign any values in existing
registries.
Desineni Expires December 7, 2006 [Page 9]
Internet-Draft Extension to pidf-lo object June 2006
7. Security Considerations
Information about the client's capability may provide a hint that
obfuscation or coarsening has occurred. (This is also the case with
the existing 'method' value.) However, the client capability fields
are not intended for general dissemination to location recipients;
this information is primarily of value to a location server. During
an emergency call, the location server may be able to determine that
the currently provided location is insufficient or out of date;
knowing the client's capability allows it to initiate the appropriate
signalling to update the location without wasting time and any
resources while trying mechanisms which the client does not support
or communicating with other network entities to determine the
client's capabilities.
Location servers SHOULD delete the 'device-capabilities' element
before distributing the pidf-lo object except in the case where the
location server is aware that an emergency call is being made and a
downstream server may be able to make use of the information.
8. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Peterson, J., "A Presence-based GEOPRIV Location Object Format",
RFC 4119, December 2005.
[3] Narten, T., "Guidelines for Writing an IANA Considerations
Section in RFCs", RFC 2434, October 1998.
[4] "3GPP TS 03.71, Location Services (LCS); Functional description;
Stage 2".
[5] "3GPP TS 43.059, Radio Access Network; Functional stage 2
description of Location Services (LCS) in GERAN".
[6] "3GPP TS 25.305, Stage 2 functional specification of User
Equipment (UE) positioning in UTRAN".
[7] "C.S0022-0, Position Determination Service Standards for Dual
Mode Spread Spectrum Systems; April 2001.".
[8] "X.S0002-0, TIA/EIA-41-D Location Services Enhancements; March
2004".
[9] "J-STD-036, Enhanced Wireless 9-1-1, Phase 2; June 2005".
Desineni Expires December 7, 2006 [Page 10]
Internet-Draft Extension to pidf-lo object June 2006
Author's Address
Harikishan Desineni
Qualcomm
5775 Morehouse Drive
San Diego, CA 92126
USA
Phone: +1 858 964 8952
Email: hd@qualcomm.com
URI: http://www.qualcomm.com
Desineni Expires December 7, 2006 [Page 11]
Internet-Draft Extension to pidf-lo object June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Desineni Expires December 7, 2006 [Page 12]
