Geopriv WG James Polk
Internet-Draft Jay Iyer
Expires: January 7, 2009 Cisco Systems
Intended Status: Standards Track (PS) July 7, 2008
Updates: RFC 4119 and [ID-SIP-GET] (if published as an RFC)
Extending the Presence Information Data Format - Location Object
(PIDF-LO) for Assisted Global Positioning System (A-GPS) Data
draft-polk-geopriv-pidf-lo-4-agps-00
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 January 7, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines how a device encapsulates Assisted Global
Positioning System (A-GPS) data to ask a Location Information Server
(LIS) to calculate the device's position, and return that
information to the device. This communication will be completed
using the Session Initiation Protocol (SIP), using Presence Filters
specific to A-GPS in a (SUBSCRIBE) request, and a Presence
Information Data Format - Location Object (PIDF-LO) as the (NOTIFY)
reply.
Polk Expires January 7, 2009 [Page 1]
Internet-Draft PIDF-LO with A-GPS Data July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology and Acronym Explosion . . . . . . . . . . . . 3
2. Assisted-GPS Communications Overview . . . . . . . . . . . . 4
3. A-GPS Elements Defined . . . . . . . . . . . . . . . . . . . 5
3.1 Message Type=0 Assist Request . . . . . . . . . . . . . 6
3.2 Message Type=1 Assist Response . . . . . . . . . . . . . 7
3.3 Message Type=2 Location Request . . . . . . . . . . . . 9
3.4 Message Type=3 Location Response . . . . . . . . . . . . 9
4. XML Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
5. XML Schema for A-GPS within PIDF-LO . . . . . . . . . . . . . 14
6. Filters to ask for A-GPS within SUBSCRIBE . . . . . . . . . . 14
7. Known Open Issues . . . . . . . . . . . . . . . . . . . . . .14
8. Security considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement and Intellectual Property . . . . . 16
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 [RFC2119].
1. Introduction
US Global Positioning System (GPS) is widely accepted to enable
clients to calculate their location based on data the device
receives from satellites. In order to compute the location, an
entity must triangulate data received from at least three
satellites. For an initial cold start, the GPS device must wait a
certain time called the Time-to-First-Fix (TTFF), before it can
successfully begin reporting the location. Under certain
circumstances, this time can be as long as 12 minutes. The device
must also have a line of site view to at least three satellites to
successfully get a position fix. This also causes additional battery
drain on mobile devices.
In order to address these line of site and timing problems,
primarily to reduce the TTFF, a solution called the Assisted GPS
(A-GPS) has been deployed [IEEE-1]. A-GPS works by allowing devices
to obtain ephemeris data from an Assisted GPS server.
Assisted GPS enables faster computation of the location information
at the clients. This document describes the messaging required to
enable Assisted GPS computation on client devices - based on the SIP
subscription model established in RFC 3265 [RFC3265], as well as
Polk Expires January 7, 2009 [Page 2]
Internet-Draft PIDF-LO with A-GPS Data July 2008
augmenting the PIDF-LO, as defined in RFC 4119 [RFC4119], to
encapsulate additional location related data to a Assisted GPS
server. Additionally, this document will define a set of Presence
filters to identify within the SIP SUBSCRIBE what is wanted in the
NOTIFY. This set of filters is an extension of the SIP 'Location
Get' filters first described in here [ID-SIP-GET].
1.1 Terminology and Acronym Explosion
The following terms will be used within this document
A-GPS Assisted Global Positioning System - A method
of GPS positioning where the receiver is
assisted through a means other than directly
from the GPS satellites.
BS Base Station [RFC5154] - A generalized
equipment set that provides connectivity,
management, and control between the subscriber
station and IEEE 802.16 network. The term BS
can also be applied to cellular systems
DGPS Differential Global Positioning System (DGPS)
is an enhancement to Global Positioning System
that uses a network of fixed, ground-based
reference stations to broadcast the difference
between the positions indicated by the
satellite systems and the known fixed positions
Ephemeris An ephemeris is a table of values that gives
the positions of astronomical objects in the
sky at a given time or times
LIS Location Information Server - a special
instance of a Location Server that consolidates
locations of endpoints and responds to queries
for locations of devices.
LBS Location Based Services
LS Location Server. Defined in RFC 3693 as a
device that receives location from a Location
Target directly, or from another LS in a chain
of LSs, and transmits location to another LS.
An LS does not response to queries about a
Target's location.
MAC Media Access Protocol.
MS, SS, MSS: Mobile Station (MS),
Subscriber station (SS),
Polk Expires January 7, 2009 [Page 3]
Internet-Draft PIDF-LO with A-GPS Data July 2008
Mobile Node (MN) [RFC5121] - The terms
subscriber station, mobile station, and mobile
node are used to convey the same semantics in
this document and refer to an IP host.
TTFF Time to First Fix. The time required by a GPS
receiver to first calculate its position.
UTC Coordinated Universal Time
2. Assisted-GPS Communications Overview
The GPS devices must have network connectivity for the 'A' in A-GPS
in order to get this ephemeris data from the server. These devices
usually have a cellular or wireless LAN connection in order to
contact the Assisted GPS server. The Assisted GPS server, with good
satellite reception and computational power, can assist the client
devices to obtain satellite constellation information known as the
almanac, satellite ephemeris data, thereby reducing the TTFF. In
addition to improving the TTFF, A-GPS requires less computational
power and consumes less power at client devices when compared to
traditional GPS.
A device capable of using Assisted GPS obtains dynamic assistance
information from the Location Information Server (LIS), and requires
connectivity or attachment to the network. The A-GPS capable device
can take advantage of assists during at least the following
scenarios:
1. during boot time - when a device initially powers up
2. at network attachment time - when a device detects attachment to
a network
3. Periodically, while attached to the network.
4. On demand, while attached to the network.
The type of server that does this calculation is some form of a LIS,
one that is A-GPS capable. The device needs to contact a LIS, and
request that it do the conversion. The answer from the LIS will be
the conversion that is used.
A-GPS does not have to be a one-time only communication (see Figure
1.). The device can create a subscription with the LIS for periodic
or triggered updates (see Figure 2). If triggered updates are a
requirement, then SIP appears to be the only IETF protocol (to date)
that can accomplish this function, based on the subscription model
it has.
Polk Expires January 7, 2009 [Page 4]
Internet-Draft PIDF-LO with A-GPS Data July 2008
A-GPS Device LIS
| |
| A-GPS Request |
|------------------------------------>|
| |
| A-GPS Response |
|<------------------------------------|
Figure 1. Single Request for A-GPS
A-GPS Device LIS
| |
| A-GPS Request |
|------------------------------------>|
| |
| A-GPS Response |
|<------------------------------------|
| |
| A-GPS Update |
|<------------------------------------|
| |
| A-GPS Update |
|<------------------------------------|
| |
| ********************** |
| * some time might be * |
| * between updates * |
| ********************** |
| |
| A-GPS Update |
|<------------------------------------|
| |
Figure 2. Single Request, Multiple Responses for A-GPS
In Figure 2, the request might create a subscription, asking that
more than one notification be sent back to the device. These
notifications can be periodic, meaning at a certain interval in time
until the subscription is updated or terminated. These
notifications can be triggered by the device moving, or thinks it
has moved. How a device detects this is out of scope of this
document.
3. A-GPS Elements Defined
RFC 4119 extended the PIDF [RFC3863] <status> element with a complex
element called <geopriv>. PIDF-LO also created two major
subselements which are encapsulated within <geopriv>: one for
location information and one for usage rules. This document does
not affect the usage rules subelement. The <location-info> element
Polk Expires January 7, 2009 [Page 5]
Internet-Draft PIDF-LO with A-GPS Data July 2008
MUST contain one or more directives indicating the XML schema(s)
that are used for geographic location formats, according to RFC
4119. This document creates a new schema under the <location-info>
element, effectively lateral to geo-coordinate location and civic
location already established within RFC 4119.
This extension to PIDF-LO creates the <gp:a-gps> element. Below are
the mandatory and optional XML subelements contained within the
<gp:a-gps> element, with definitions and value ranges. Out of
respect for the WiMAX Forum, this payload will be minimal in size,
because WiMAX deals with power constrained devices communicating
over low speed links (or high speed links shared by many devices -
sometimes allowing for each to only have a small part of the
available bandwidth), therefore this needs to be thought of in terms
of how the XML can be placed into a binary bit-map.
There are 4 message types for adding A-GPS to the PIDF-LO,
Location-Request,
Location-Response,
Assisted-Request and
Assisted-Response.
Some of the individual fields are mandatory (M), and some are
optional (O). Each of the message types starts the same 3 elements,
with the following elements:
A-GPS Header (Mandatory fields)
Message length (4 bytes) Length of the SIP Payload in bytes
Transaction ID (2 bytes)
Message Type (1 byte) MT = 0 for Assist-REQ
MT = 1 for Assist-RSP
MT = 2 for LOC-REQ
MT = 3 for LOC-RSP
The next set of elements within the XML depends on which of the 4
message types is being communicated. One, and only one of the
following message types MUST appear as the next XML elements within
the same PIDF-LO.
(M) means an element is mandatory in the message type.
(O) means the element is optional in the message type.
3.1 Message Type=0 Assist Request
Satellite System Type (M) This is set to the type of GPS
Polk Expires January 7, 2009 [Page 6]
Internet-Draft PIDF-LO with A-GPS Data July 2008
satellite system in place. Choices for
this element are Navstar, or Galileo.
1 byte :
Local Reference Identifier (M) This is set to the local reference
identifier, known to the client at the
time of the query. A client accessing
this over a wireless LAN network item 1
Local Reference ID (M) For WiMAX or cellular systems, this can
be set to the Base-station ID, or for
WiFi systems, this can be set to the
Access Point MAC address.
Assist-REQ from LS (M) (2 Bytes) bit map of the requested info:
Bit 0: Location aid: coarse location
aiding to assist the GPS
measurements
Bit 1: coarse time aid
Bit 2: DGPS corrections
Bit 3: navigational model
Bit 4: Acquisition assistance
Bit 5: Satellite health
Bit 6: Ionospheric model
Bit 7: UTC Model
Bit 8: Almanac
Bits 9-15: Reserved
Aiding Mask (O) Aiding Mask for the satellites (32 bit
quantity, 1 bit per satellite)
Bit set => ephemeris for the satellite
requested
Periodicity (O) Periodicity of the response as expected
by the Mobile System. Expressed in
terms of time interval (minutes)
between two consecutive Responses by
LS. Needed only for periodic location
Duration (O) Total duration for which the assist-REQ
is valid (in minutes). Needed only for
periodic location
3.2 Message Type=1 Assist Response
> Satellite System Type (O) Local reference Identifier. Included
if location aiding is requested by the
Polk Expires January 7, 2009 [Page 7]
Internet-Draft PIDF-LO with A-GPS Data July 2008
MS for MS initiated TTFF enhancements.
For network initiated TTFF enhancement,
this parameter is always included.
>sign of latitude (O) North or south
>latitude (O) Integer (0..2^23-1).
The latitude encoded value (N) is
derived from the actual latitude X in
degrees (0..90) by this formula:
N <= 2^23 X /90 < N+1
>longitude (O) Integer (-2^23.. 2^23-1).
The longitude encoded value (N) is
derived from the actual longitude X in
degrees (-180..+180) by this formula:
N <= 2^24 X /360 < N+1
>uncertainty ellipse (O) semi major, semi minor, major axis.
Refer to Annex A in the LBS Spec
>confidence level (O) Represents the confidence by which the
position of a target entity is known to
be within the shape description (i.e.,
uncertainty ellipse for 2D description,
uncertainty ellipsoid for 3D
description) and is expressed as a
percentage.
This is an integer (0..100).
>Z height (O) Provides altitude information in meters
Integer (0..2^15-1). Refer to annex A
for details
>Z height uncertainty (O) Contains the altitude uncertainty code.
Refer to Annex A for details
Time aid (O) Included if time aiding is requested by
the MS for MS initiated TTFF
enhancements. For network initiated
TTFF enhancement, this parameter is
always included.
Assistance Data (O) Included, if requested by MS, based on
the bit map set by the MS in the
Assist-REQ message
Polk Expires January 7, 2009 [Page 8]
Internet-Draft PIDF-LO with A-GPS Data July 2008
Error code (O) Included in the event of an error.
Please see LBS document for the codes
3.3 Message Type=2 Location Request
(Optional unless otherwise indicated)
Periodicity (O) Periodicity of the response as expected
by the MS. Expressed in terms of time
interval (seconds) between two
consecutive Responses by LS. Needed
only for periodic location.
Duration (O) Total duration for which the LOC-REQ is
valid (in seconds). Needed only for
periodic location.
Location capabilities (M) Indicates the capabilities of the MS. A
bit vector:
Bit 0: Uplink (TDOA) Time Difference of
Arrival
Bit 1: Down Link (DL) Round Trip Delay
(RTD) measurements only
Bit 2: DL RD measurements only
Bit 3: DL Receive Signal Strength
Indication (RSSI) measurements
only
Bits 4-7: reserved.
Accuracy (O) Desired accuracy of the location
response
Latency (O) Desired Latency for the location
response
3.4 Message Type=3 location Response
MS location (M) Location of the MS as calculated by it.
>Timestamp (M) Timestamp when location was calculated
>sign of latitude (M) North or south
>latitude (M) Integer (0..2^23-1).
The latitude encoded value (N) is
derived from the actual latitude X in
degrees (0..90) by this formula:
Polk Expires January 7, 2009 [Page 9]
Internet-Draft PIDF-LO with A-GPS Data July 2008
N <= 2^23 X /90 < N+1
>longitude (M) Integer (-2^23.. 2^23-1).
The longitude encoded value (N) is
derived from the actual longitude X in
degrees (-180..+180) by this formula:
N <= 2^24 X /360 < N+1
>uncertainty ellipse (O) semi major, semi minor, major axis.
Refer to Annex A in the LBS Spec
>confidence level (O) Represents the confidence by which the
position of a target entity is known to
be within the shape description (i.e.,
uncertainty ellipse for 2D description,
uncertainty ellipsoid for 3D
description) and is expressed as a
percentage.
This is an integer (0..100).
>Z height (O) Provides altitude information in meters
Integer (0..2^15-1). Refer to annex A
for details
>Z height uncertainty (O) Contains the altitude uncertainty code.
Refer to Annex A for details
Error code (O) Included in the event of an error.
Please see LBS document for the codes
4. XML Examples
The following is an example taken from RFC4119 [RFC4119] (with an
updated times) which provides GPS coordinates as its location
format. All the security and privacy rules apply to this PIDF-LO
extension as they do to RFC 4119, including any retransmission and
retention-expiry elements.
<?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:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="pres:geotarget@example.com">
<tuple id="sg89ae">
<status>
Polk Expires January 7, 2009 [Page 10]
Internet-Draft PIDF-LO with A-GPS Data July 2008
<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>2008-08-03T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2008-07-28T20:57:29Z</timestamp>
</tuple>
</presence>
Removing the non-location specific (i.e., header) elements, we have
above this:
<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>2008-08-03T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
This A-GPS extension will fit **here** in the schema below
<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:a-gps>
**here** ...
\ </gp:a-gps>
</gp:location-info>
<gp:usage-rules>
Polk Expires January 7, 2009 [Page 11]
Internet-Draft PIDF-LO with A-GPS Data July 2008
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2008-08-03T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
4.1 Example XML for Message Type=0 Assist Request
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
</gml:location>
<gp:a-gps>
<messageLength>(4 bytes)</messageLength>
<transactionID>(2 bytes)</transactionID>
<messageType>(4 values)</messageType>
<servingBsId></servingBsId>
<requestedAssistFromLS>(2 bytes)</requestedAssistFromLS>
<aidingMask>(4 bytes)</aidingMask>
<periodicity>(range)</periodicity>
<duration>(range)</duration>
</gp:a-gps>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
</gp:geopriv>
</status>
4.2 Example XML for Message Type=1 Assist Response
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
</gml:location>
<gp:a-gps>
<messageLength>(4 bytes)</messageLength>
<transactionID>(2 bytes)</transactionID>
<messageType>(4 values)</messageType>
<serving_scannedBsIDloc></serving_scannedBsIDloc>
<signOfLatitude></signOfLatitude>
<latitude></latitude>
<longitude></longitude>
<uncertaintyEllipse></uncertaintyEllipse>
<confidenceLevel></confidenceLevel>
<zHeight></zHeight>
<zHeightUncertainty></zHeightUncertainty>
<timeAid></timeAid>
Polk Expires January 7, 2009 [Page 12]
Internet-Draft PIDF-LO with A-GPS Data July 2008
<assistanceData></assistanceData>
<errorCode></errorCode>
</gp:a-gps>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
</gp:geopriv>
</status>
4.3 Example XML for Message Type=2 Location Request
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
</gml:location>
<gp:a-gps>
<messageLength>(4 bytes)</messageLength>
<transactionID>(2 bytes)</transactionID>
<messageType>(4 values)</messageType>
<periodicity></periodicity>
<duration></>duration>
<locationCapabilities></locationCapabilities>
<accuracy></accuracy>
<latency></latency>
</gp:a-gps>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
</gp:geopriv>
</status>
4.4 Example XML for Message Type=3 Location Response
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
</gml:location>
<gp:a-gps>
<messageLength>(4 bytes)</messageLength>
<transactionID>(2 bytes)</transactionID>
<messageType>(4 values)</messageType>
<msLocation></msLocation>
<timestamp></timestamp>
<signOfLatitude></signOfLatitude>
<latitude></latitude>
<longitude></longitude>
<uncertaintyEllipse></uncertaintyEllipse>
<confidenceLevel></confidenceLevel>
Polk Expires January 7, 2009 [Page 13]
Internet-Draft PIDF-LO with A-GPS Data July 2008
<zHeight></zHeight>
<zHeightUncertainty></zHeightUncertainty>
<errorCode></errorCode>
</gp:a-gps>
</gp:location-info>
<gp:usage-rules>
</gp:usage-rules>
</gp:geopriv>
</status>
5. XML Schema for A-GPS within PIDF-LO
TBD
6. Filters to ask for A-GPS within SUBSCRIBE
TBD
7. Known Open Issues
This document is admittedly incomplete. There are many fields and
definitions that are not expanded or explained. Part of this is due
to synchronizing this document with the WiMAX Forum's WiMAX Location
Protocol (WLP), which is still be worked on. Part of this is due to
there not being enough time to complete this document.
- does this extension to RFC 4119 necessitate extending the
<provided-by> element to include the URI of the LIS?
8. Security considerations
This document introduces no new security considerations from that in
RFC 4119 [RFC4119].
9. IANA considerations
TBD
(the modified PIDF-LO schema, the A-GPS filters, and the <method>
element will be listed here)
10. Acknowledgments
Your name here... or if you contribute a fair amount of text, you
can be a co-author.
Polk Expires January 7, 2009 [Page 14]
Internet-Draft PIDF-LO with A-GPS Data July 2008
11. References
11.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[IEEE-1] Djuknic, G. and R. Richton, "Geolocation and Assisted GPS",
IEEE Computer, Feb 2001.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005
[ID-SIP-GET] J. Polk, "Session Initiation Protocol (SIP) Location Get
Function", draft-polk-sip-location-get-00, "work in
progress", July 2008
[RFC5154] J. Jee et al, "IP over IEEE 802.16 Problem
Statement and Goals", RFC 5154,
[RFC5121] B. Patil, et al, "Transmission of IPv6 via the
IPv6 Convergence Sub-layer over IEEE 802.16 networks",
RFC 5121,
[RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J.
Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004
[3GPP-1] 3GPP TS 44.031, Location Services (LCS); Mobile Station (MS)
- Serving Mobile Location Center (SMLC) Radio Resource LCS
Protocol (RRLP)
11.2. Informative References
none
Authors' Addresses
James Polk
3913 Treemont Circle
Colleyville, Texas, USA
+1.817.271.3552
mailto: jmpolk@cisco.com
Polk Expires January 7, 2009 [Page 15]
Internet-Draft PIDF-LO with A-GPS Data July 2008
Jay Iyer
3625 Cisco Way
San Jose , CALIFORNIA 95134
+1 408 527 2214
mailto: jiyer@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE
IETF TRUST 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.
Intellectual Property
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.
Polk Expires January 7, 2009 [Page 16]
Internet-Draft PIDF-LO with A-GPS Data July 2008
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Polk Expires January 7, 2009 [Page 17]