One document matched: draft-marshall-geopriv-lbyr-requirements-02.txt
Differences from draft-marshall-geopriv-lbyr-requirements-01.txt
GeoPriv R. Marshall, Ed.
Internet-Draft TCS
Intended status: Informational July 9, 2007
Expires: January 10, 2008
Requirements for a Location-by-Reference Mechanism used in Location
Configuration and Conveyance
draft-marshall-geopriv-lbyr-requirements-02
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 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Marshall Expires January 10, 2008 [Page 1]
Internet-Draft GEOPRIV LbyR Requirements July 2007
Abstract
This document defines terminology and enumerates requirements for a
Location-by-Reference approach to the configuration, dereferencing,
and conveyance of location for SIP signaling, and other Internet
messaging, including for emergency call routing for voice-over-IP
(VoIP) and general Internet multimedia systems, where Internet
protocols are used end-to-end.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Routing Models . . . . . . . . . . . . . . . . . . . . . . . . 9
5. LbyR Basic Actors . . . . . . . . . . . . . . . . . . . . . . 10
6. LbyR Actions . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. LbyR via L7LCP . . . . . . . . . . . . . . . . . . . . . . . . 13
8. LbyR via DHCP . . . . . . . . . . . . . . . . . . . . . . . . 16
9. LbyR via LLDP-MED . . . . . . . . . . . . . . . . . . . . . . 17
10. LbyR via SUPL . . . . . . . . . . . . . . . . . . . . . . . . 18
11. High-Level Requirements . . . . . . . . . . . . . . . . . . . 19
12. Security Considerations . . . . . . . . . . . . . . . . . . . 22
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
16.1. Normative References . . . . . . . . . . . . . . . . . . . 26
16.2. Informative References . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
Marshall Expires January 10, 2008 [Page 2]
Internet-Draft GEOPRIV LbyR Requirements July 2007
1. Introduction
Any location-based service which utilizes SIP signaling, needs to
have some form of location information available, to serve as the
basis of performing a location-based mapping operation in order to
know where to route. To enable any location-based service, whether
for an end device or middlebox, (e.g., SIP Proxy), location must be
acquired, either directly or indirectly, location information, either
in the form of a PIDF-LO or a Location Reference Identifier.
This document defines the requirements for a Location-by-Reference
mechanism, its use, and its alternatives. It contrasts the Location-
by-Reference routing model to the Location-by-Value model, and
describes the ways in which a Location-by-Reference mechanism is
used, such as for requesting a reference, resolving a reference, and
conveying a reference.
The document also talks about the two primary network models which
may use Location-by-Reference, "Edge" routed and "Proxy" routed
scenarios.
When describing the use of location within messaging, it is essential
to discuss the scope of how location is handled within this document.
We talk about how location is 'acquired', or 'configured' within a
host, but we do not address the mechanisms involved in
'determinining' (i.e., the methods or process of coming up with the
location information).
The action of passing location from one entity to another entity
along a SIP signaling path is referred to as "conveyance", and is
discussed separately from that of configuration. The commonly used
example of a SIP-based emergency call may include both elements of
configuration and conveyance, in order to be able to appropriately
route and deliver location to an IP-enabled PSAP.
Location determination, which may include the processes of manual
provisioning, automated measurements, or derivation steps (e.g., geo-
coding/reverse geo-coding), is out of scope for this document.
A detailed description and usage guidelines for Location-by-Value are
out of scope in this document.
This document identifies the individual requirements underlying how a
Location-by-Reference (LbyR) mechanism is to be used over the
Internet, applied to either a Dereference protocol, Conveyance
protocol, or a Configuration protocol.
For an application of LbyR, we often cite the use case of a SIP-based
Marshall Expires January 10, 2008 [Page 3]
Internet-Draft GEOPRIV LbyR Requirements July 2007
signaling to emergency services, though we also talk about LbyR in a
more general sense. In this case, a SIP user agent, or SIP proxy
server acting on behalf of a user agent, to another user agent via
the SIP protocol [RFC3261]. In place of the actual value for a
"Location", a Location Reference URI is used to indirectly represent
the location via a dereference step. Stored in some Internet-
connected host, which we call a Location Configuration Server (LCS).
In the LbyR context, the Configuration protocol mechanism is used to
fetch a location reference, and in this case, the protocols which
have been identified for this use, includes DHCP, LLDP-MED, HELD, and
potentially, SUPL. Regardless of protocol choices, the underlying
approach to how LbyR is used for configuration is not specific to any
particular protocol choice.
A Location which is referenced can be either Coordinate location [RFC
3693] (e.g., lat/lon), or a Civic location (e.g., street address).
We reintroduce a few of the building blocks to location [RFC3693]
into the LbyR discussion. Included in this list is the "target", the
entity whose location is transmitted, (e.g., UA location). A "using
protocol", defined as how a "target" (in this model) transmits a
"location reference identifier" to a "location recipient". Privacy
of a target's location, with repect to user identity is important to
protect. Therefore, any examples shown will assume that any user
identity associated with the target is not included with location.
Location can be pushed from one host to another, via a conveyance
protocol, as part of a signaling protocol, in order to be used for
location-based routing (or other purposes, outside the scope here),
or it can alternatively be queried via a client request to a server
which provides location [ref. draft-sip-conveyance- XXX]. In the
case of LbyR Conveyance, the actual location (i.e., location object)
never gets pushed along, but is replaced by a Location Reference
Identifier. In the case of a client which queries a server for
location, the query is either to obtain a Location Reference
Identifier, or to obtain an actual Location (e.g., location object)
based the input of an LRI in the query.
The draft-sip-conveyance- document [draft-sip-conveyance] details how
SIP proxies treat LbyR (and LbyV) scenarios for conveying location
via the SIP protocol.
Whereas location objects are readily consumable by the hosts that
using protocols deliver to, a Location Reference ID must first go
through a dereference step in order to be useful.
In our SIP example, for LbyR, instead of having a content identifier
Marshall Expires January 10, 2008 [Page 4]
Internet-Draft GEOPRIV LbyR Requirements July 2007
(cid:) pointing to a location object within a SIP body, the LRI is
carried in the Geolocation header of a SIP message which is used to
get a location via a dereference step.
The structure of this document first defines terminology in
Section 3. Then a short discussion on actors, Section 5. Routing
models, considering both "Edge" and "Proxy" routed models are shown
by example, Figure 1 and Figure 2, respectively, followed by a more
specific model which shows a Layer 7 LCP context model.
[Placeholders for...] More models are included for comparison,
including those for LbyR by DHCP, LLDP-MED, and by SUPL. A high-
level list of baseline requirements are outlined for the LbyR
mechanism, (Section 11), and generally apply to configuration,
dereferencing, and conveyance of location by means of a Location
Reference Identifier in lieu of the an actual location, as would
otherwise be included within a PIDF-LO structure.
Any detailed discussion of Identification information about the
caller, subscriber, or device, as associated information to location
or a location reference, for either Conveyance, Dereference, or
Configuration, is out of scope in this document.
Marshall Expires January 10, 2008 [Page 5]
Internet-Draft GEOPRIV LbyR Requirements July 2007
2. Requirements Terminology
In this document, 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].
Marshall Expires January 10, 2008 [Page 6]
Internet-Draft GEOPRIV LbyR Requirements July 2007
3. Terminology
3.1. Terms
Several of the terms presented below are based on RFC3693, and in
some cases, extended to include additional language to support the
Location-by-Reference model.
Dereference Protocol: A protocol which is used to query a Location
Configuration Server based on an LRI as input, and which returns a
location value (.e.g, PIDF-LO).
Location Reference Identifier (LRI): An identifier which serves as a
pointer to a target's location record on a remote host (e.g.,
location configuration server), and is used by a dereferencing
protocol for retrieval of the associated specific location.
LoST Server: A network entity which provides a URI response based on
input of a location and service identifier [ref.
draft-ecrit-lost-].
Using Protocol: A protocol (e.g., SIP) which carries a Location
Object or an Location Reference Identifier.
Target: A person, end device, or other entity whose location is
communicated by a Geopriv Location Object.
Location Recipient (LR): The entity that receives location
information. It may have asked for this location explicitly (by
sending a query containing an LRI to a location configuration
server), or it may receive this location asynchronously.
Location Server (LS): The entity to which a LG publishes location
objects, is the recipient of queries from location recipients, and
is the entity that applies rules designed by the Rule Maker (RM)
[ref. RFC4119]. Also may be referred to as a Presence Server
(PS).
Location Configuration Server (LCS): The entity which receives a
client request for either location or a location reference. In
the latter case, also performs the dereference function for a
Location Refernce Identifier, in the context of the Location-by-
Reference model. May also be referred to as a Location
Information Server (LIS).
Marshall Expires January 10, 2008 [Page 7]
Internet-Draft GEOPRIV LbyR Requirements July 2007
Location: Either a coordinate (geographic) identification assigned
to a region or feature based on a specific coordinate system, or
by other identifiable information such as a street number and
street name within a civic location reference system.
Civic location: A described location based on some understood
location reference system, such a jurisdictions or postal delivery
grid. A street address valid within the USPS system is a common
example.
Coordinate location: A reference to a point which is able to be
located as described by a set of defined coordinates within a
geographic coordinate system, such as latitude and longitude
within the WGS-84 datum. For example, 2-D geographic location is
defined as an (x,y) coordinate value pair according to the
distance north or south of the equator and east or west of the
prime meridian.
Location-by-Value: The mechanism of representing location either in
conveyance protocols or configuration protocols as fully
specified, (i.e., including the actual location value itself).
Location-by-Reference: The mechanism of representing location either
in conveyance protocols or configuration protocols as an
identifier which refers to a fully specified location, (i.e.,
including a pointer to the actual location value itself).
Marshall Expires January 10, 2008 [Page 8]
Internet-Draft GEOPRIV LbyR Requirements July 2007
4. Routing Models
This document describes the two primary network models which may use
Location-by-Reference, these are often referred to as either "Edge"
routed or "Proxy" routed messaging.
Since Location-by-Value is an alternative approach which deals with
acquiring and conveying location information directly, and in the
general case where LbyV does not include a Location Reference
Identifier, LbyV is deemed out of scope in this document, except
where noted, and so the following examples will only deal with LbyR
scenarios.
1. The Edge routed model consists of the end device acquiring a
location reference identifier, dereferencing the LRI, and
performing the routing based on the dereferenced location.
Location information might be generated by the end host itself,
in which case the end host itself may request a location
reference identifier, based on its location, from the LCS.
2. The Proxy routed approach relies on some kind of middlebox (e.g.,
Proxy) inserting an LRI into the SIP messaging, and would be
required for non-location-aware end devices. In this case,
location information might be generated by, provisioned into, or
stored by the LCS, and represented to the end device as a
location reference identifier, delivered via a location
configuration protocol (e.g., using DHCP, LLDP-MED, or an L7 LCP.
The Location Reference Identifier is useful to point to a location
value or mask the actual location value. Since possessing the LRI
alone is insufficient to perform location-based routing, the LRI must
be de-referenced. Once the location is de-referenced and returned to
the location recipient, it can then be used as input to some
location-based service (e.g., LoST).
Marshall Expires January 10, 2008 [Page 9]
Internet-Draft GEOPRIV LbyR Requirements July 2007
5. LbyR Basic Actors
The basic actors shown in an "Edge" routing model.
+-------------+
| |
| LCS +<-----------------+-------------------------+
| | | |
+--+-------+--+ | |
^ ^ | |
| | | |
Configuration | |
Protocol | | |
(a) (b) Dereference (b) (b)
| | Protocol | |
| | | |
v v v v
+--+-------+--+ Conveyance +-----+------+ +-----+-----+
| Target / | Protocol | Proxy / | | Term./ |
| End Host +----(c)---->+ UAS +----(c)---->+ UAS |
| | | | | |
+-------------+ +------------+ +-----------+
Figure 1: Shows the basic model shows Edge routing inter-
relationship between Configuration, Dereference, and Conveyance
protocols:
In the case of Edge routing, the following applies, as shown in
the above figure, the Target / End Host:
(a) Acquires an LRI from the LCS
(b) Dereferences the LRI, receiving the location
Uses the location to determine routing instructions in the form of
a destination URI (step not shown)
(c) Conveys the LRI to the destination URI obtained in the
previous step
(b) Additional Dereference steps may be necessary on the way to
and at the terminating UAS.
Marshall Expires January 10, 2008 [Page 10]
Internet-Draft GEOPRIV LbyR Requirements July 2007
The basic actors shown in an "Proxy" routing model.
+-------------+
| |
| LCS +<-----------------+-------------------------+
| | | |
+--+-------+--+ | |
: ^ | |
: | | |
: | (b) Dereference (b)
: +--------(a)-------+ | Protocol |
(0) Configuration | | |
Determination Protocol | | |
Mechanism | | |
: v v v
+--+-------+--+ +--+--+------+ Conveyance +-----+-----+
| Target / | | Proxy / | Protocol | Term./ |
| End Host +----------->+ UAS +----(c)---->+ UAS |
| | | | | |
+-------------+ +------------+ +-----------+
Figure 2: Shows the basic model shows Proxy routed inter-
relationship between Configuration, Dereference, and Conveyance
protocols:
In the case of Proxy routing, this time it's the Proxy, serving
the Target / End Host, which acts as follows to:
(a) Acquire an LRI from the LCS
(b) Dereference the LRI, receiving the location
Use the location to determine routing instructions in the form of
a destination URI (step not shown)
(c) Convey the LRI to the destination URI obtained in the previous
step
Marshall Expires January 10, 2008 [Page 11]
Internet-Draft GEOPRIV LbyR Requirements July 2007
6. LbyR Actions
The LbyR mechanism has three distinct actions which describe its use.
1. An LRI is 'acquired' via a Configuration protocol request/
response (which implies its creation and receipt). This action
is performed by the entity which needs the location reference to
resolve it via the dereference step, then send it on to the next
destination (conveyance).
2. An LRI 'resolved', via a Dereferencing protocol request/response.
This is the action of exchanging the reference for an actual
location.
3. An LRI is 'pushed' via a Conveyance protocol mechanism. This
action is accomplished by a using protocol, such as SIP, in which
case it would be included in a specific SIP header.
Note: An LRI may also be conveyed alongside a PIDF-LO, (which enables
the Terminating UAS a convenient mechanism to perform location
updates).
Marshall Expires January 10, 2008 [Page 12]
Internet-Draft GEOPRIV LbyR Requirements July 2007
7. LbyR via L7LCP
Location-by-Reference with Location Subscriptions
In mobile wireless networks it is not efficient for the end host
to periodically query the LCS for up-to-date location information.
Furthermore, the end host might want to delegate the task of
retrieving and publishing location information to a third party,
such as a presence server. Finally, in some deployments the
network operator might not want to make location information
available to the end hosts.
These usage scenarios motivated the introduction of the
location-by- reference concept. Depending on the type of
reference, such as HTTP/ HTTPS or SIP presence URI, different
operations can be performed. While an HTTP/HTTPS URI can be
resolved to location information, a SIP presence URI provides
further benefits from the SUBSCRIBE/NOTIFY concept that can
additionally be combined with location filters [13].
+-----------+ Dereferencing +-----------+
| | Protocol (3) | Location |
| LCS +---------------+ Recipient |
| | | |
+-----+-----+ +----+------+
| --
| --
| Geopriv-L7 --
| Protocol --
| (1) --
| -- Geopriv
| -- Using Protocol
| -- (e.g., SIP)
+-----+-----+ -- (2)
| Target / |--
| End Host +
| |
+-----------+
Figure 3: Shows the assumed communication model for a L7 LCP:
Note that there is no requirement for using the same protocol in
(1) and (3).
Marshall Expires January 10, 2008 [Page 13]
Internet-Draft GEOPRIV LbyR Requirements July 2007
The following list describes the location subscription idea:
1. The end host discovers the LCS.
2. The end host sends a request to the LCS asking for a
location-by- reference, as shown in (1) of Figure 4.
3. The LCS responds to the request and includes a location object
together with a subscription URI.
4. The Target puts the subscription URI into a SIP message as
described in [14] forwards it to a Location Recipient, as shown in
(2) of Figure 4. The Location Recipient subscribes to the
obtained subscription URI (see (3) of Figure 4) and potentially
uses a location filter (see [13]) to limit the notification rate.
5. If the Target moves outside a certain area, indicated by the
location filter, then the Location Recipient will receive a
notification.
Note that the Target may also act in the role of the Location
Recipient whereby it would subscribe to its own location
information. For example, the Target obtains a subscription URI
from the Geopriv-L7 protocol. It subscribes to the URI in order
to obtain its currently location information, which then serves as
input to a LoST query (see [15]) in order to acquire the service
boundary (e.g., PSAP boundary). The service boundary indicates
the region where the device can move without the need to re-query
since the returned answer remains unchanged. The Target uses this
service boundary to location filters and updates the subscription.
If the Target moves outside a certain area, indicated by the
location filter, it will receive a notification and knows that re-
querying LoST to obtain a new service boundary is necessary.
For location-by-reference, the LCS needs to maintain a list of
randomized URIs for each host, timing out these URIs after the
reference expires. References need to expire to prevent the
recipient of such a URL from being able to (in some cases)
permanently track a host. Furthermore, this mechanism also offers
garbage collection capability for the LIS.
Location references must prevent adversaries from obtaining the
Target's location. There are at least two approaches: The
location reference contains a random component and allows any
holder of the reference to obtain location information.
Alternatively, the reference can be public and the LIS performs
access control via a separate authentication mechanism, such as
HTTP digest or TLS client side authentication, when resolving the
Marshall Expires January 10, 2008 [Page 14]
Internet-Draft GEOPRIV LbyR Requirements July 2007
reference to a location object.
Marshall Expires January 10, 2008 [Page 15]
Internet-Draft GEOPRIV LbyR Requirements July 2007
8. LbyR via DHCP
[Place text here.]
Marshall Expires January 10, 2008 [Page 16]
Internet-Draft GEOPRIV LbyR Requirements July 2007
9. LbyR via LLDP-MED
[Place text here.]
Marshall Expires January 10, 2008 [Page 17]
Internet-Draft GEOPRIV LbyR Requirements July 2007
10. LbyR via SUPL
[Place text here.]
Marshall Expires January 10, 2008 [Page 18]
Internet-Draft GEOPRIV LbyR Requirements July 2007
11. High-Level Requirements
Below, we summarize high-level design requirements needed for a
location-by-reference mechanism.
Rq1. Location Reference Identifier as a URI: The dereferencing
protocol MUST support an LRI in URI form, and may support other
non-URI forms.
Rq2. Dereference Protocol Confidentiality: The dereferencing
protocol MUST support mechanisms for encrypting messages sent
between client (Location recipient) and server (Location
Configuration Server).
Rq3. Dereference Protocol Transparancy: The dereferencing protocol
MUST support the exchange of messages without encryption (i.e., in
plaintext).
Motivation: In the case where encrypted message exchange is
unsuccessful, there must be a way to try to dereference a location
reference identifier with less restriction (e..g., in the
emergency service case, where every call always needs answered).
Rq4. Location Reference Expiration: The Location Reference
mechanism MUST provide a way to limit the validity of that
reference (and SHOULD also provide a way to extend or shorten the
validity period).
Motivation: Location references are not intended to represent a
location forever, and the identifier eventually may need to be
recycled, or may be subject to a specific window of validity,
after which the location reference fails to yield a location, or
the location is determined to be kept confidential. An expiry
timer for a location reference ensures that the location reference
becomes invalid based on configuration.
Rq5. Dereference Protocol Transport: The dereference protocol MUST
support TCP/IP and MAY support UDP/IP.
Motivation: Practical, near-term deployment issues may make TCP/IP
implementations unachievable.
Rq6''. Dereference Protocol Authentication: The The Location
dereferencing protocol MUST support both client-side and server-
side authentication between server and client.
Marshall Expires January 10, 2008 [Page 19]
Internet-Draft GEOPRIV LbyR Requirements July 2007
Motivation: It is reasonable to expect implementations of
authentication to vary. Some implementations may choose to
support both client-side and server-side authentication, might
support one only, or may support neither.
Rq7. Location Privacy: The Location Reference MUST NOT reveal any
personal identification information along with a requested
location object.
Rq8. Dereferenced PIDF-LO Result: The dereferencing of an LRI MUST
result in a well-formed PIDF-LO.
Motivation: This is in order to ensure adequate privacy rules can
be adhered to, since the PIDF-LO format comprises the necessary
structures to maintain location privacy.
Rq9. Time Limitation: The reference MUST be valid for a limited
amount of time.
Motivation:
Rq10. : The reference MUST be hard to guess, i.e., it MUST contain a
cryptographically random component.
Motivation:
Rq11. : The reference MUST NOT contain any information that
identifies the user, device or address of record.
Motivation:
Rq12. : The Location Recipient MUST be able to resolve the reference
more than once (i.e., there is no implicit limit on the number of
dereferencing actions).
Motivation:
Rq13. : Possessing a reference to location information allows a
Location Recipient to repeately obtain the latest information
about the Target with the same granularity.
Motivation:
Rq14. : The Target MUST be able to resolve the reference itself.
Marshall Expires January 10, 2008 [Page 20]
Internet-Draft GEOPRIV LbyR Requirements July 2007
Motivation:
Marshall Expires January 10, 2008 [Page 21]
Internet-Draft GEOPRIV LbyR Requirements July 2007
12. Security Considerations
The LbyR mechanism currently addresses security issues as follows.
1. A pawn ticket where possession implies permission, and
2. Identifiers that are public which are protected by privacy rules
at the dereference server.
3. Additional security issues will be discussed in a separate
geopriv document (based on a prior version of the l7-lcp-ps
draft).
Marshall Expires January 10, 2008 [Page 22]
Internet-Draft GEOPRIV LbyR Requirements July 2007
13. IANA Considerations
This document does not require actions by the IANA.
Marshall Expires January 10, 2008 [Page 23]
Internet-Draft GEOPRIV LbyR Requirements July 2007
14. Contributors
Andrew Newton; Martin Dawson; Henning Schulzrinne; Marc Linsner;
Brian Rosen; Ted Hardie; James M. Polk; James Winterbottom; Martin
Thomson; John Schnizlein; Barbara Stark; Jon Peterson; Allison
Mankin; Randall Gellens; Cullen Jennings; Richard Barnes; Keith
Drage; Rohan Mahy; Hannes Tschofenig
The contributors can be reached at:
Name user@example.com
Marshall Expires January 10, 2008 [Page 24]
Internet-Draft GEOPRIV LbyR Requirements July 2007
15. Acknowledgments
[TBD]
Marshall Expires January 10, 2008 [Page 25]
Internet-Draft GEOPRIV LbyR Requirements July 2007
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
16.2. Informative References
[I-D.ietf-ecrit-lost]
Hardie, T., "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-05 (work in progress),
March 2007.
[I-D.ietf-ecrit-requirements]
Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress),
March 2007.
[I-D.ietf-ecrit-security-threats]
Taylor, T., "Security Threats and Requirements for
Emergency Call Marking and Mapping",
draft-ietf-ecrit-security-threats-04 (work in progress),
April 2007.
[I-D.ietf-geopriv-dhcp-civil]
Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information",
draft-ietf-geopriv-dhcp-civil-09 (work in progress),
January 2006.
[I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in
progress), April 2007.
[I-D.ietf-geopriv-loc-filters]
Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in the Presence Information Document
Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-01 (work in progress),
March 2007.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Marshall Expires January 10, 2008 [Page 26]
Internet-Draft GEOPRIV LbyR Requirements July 2007
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
Marshall Expires January 10, 2008 [Page 27]
Internet-Draft GEOPRIV LbyR Requirements July 2007
Author's Address
Roger Marshall (editor)
TeleCommunication Systems, Inc.
2401 Elliott Avenue
2nd Floor
Seattle, WA 98121
US
Phone: +1 206 792 2424
Email: rmarshall@telecomsys.com
URI: http://www.telecomsys.com
Marshall Expires January 10, 2008 [Page 28]
Internet-Draft GEOPRIV LbyR Requirements July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Marshall Expires January 10, 2008 [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-22 17:16:56 |