One document matched: draft-rosen-spatial-requirements-00.txt
Spatial B. Rosen
Internet Draft Marconi
Document: draft-rosen-spatial-requirements-00.txt Jose Costa -Requena
Category: Informational Nokia
Mari Korkea-Aho
Nokia
Mika Ylianttila
University of Oulu
Rohan Mahy
Cisco Systems
Kenji Takahashi
NTT
Stephen Farrell
Baltimore Technologies
Spatial Location Protocol Requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
1. Abstract
This document describes requirements to be placed on the Spatial
Location Protocol (SloP).
2. Conventions used 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 [2].
Spatial Location Protocol (SloP) Requirements July 2000
3. Definition of Terms
Target: The entity whose location is known by the server and
desired by the client. The protocol does not specify
how the server learns the location of the target.
Server: Entity which supplies the location of the target to the
client. One end of the protocol.
Client: The entity which desired to learn the location of the
target. One end of the protocol.
Precision: Number of digits to which the measurement is accurate
Accuracy: The measurement is correct to within this maximum
expected error
Exactness: The precision of the reported value.
Velocity: Speed and direction
Orientation: Heading or bearing on or near the surface of the Earth,
with respect to True North
Obfuscate: To intentionally make the measurement less accurate by
adding randomness.
Geocentric: With respect to, or centered upon the center of gravity
of the Earth.
4. Location Representation
A location representation is an instantiation of the location of a
target. In SLoP, location representations shall be determined
through two levels of abstraction: schema and format.
"Schema" defines the logical scheme the location representations are
based on, such as WGS84. "Format" defines how a given schema is
represented. A schema can be formatted in several ways. For
example, a location determined by WGS84 can be represented in a set
of longitude, latitude, and altitude or geo-centric Cartesian
coordination (X, Y, Z).
The protocol must:
a. Define one default location representation that must be supported
by all SLOP entities.
b. Specify an absolute location on the earth and use WGS84 geodetic
datum as reference system for the default scheme.
c. Specify the format of the default scheme in longitude, latitude,
altitude parameters. Altitude may be an optional parameter.
d. Support other location representations than the default,
including existing schemes and formats widely used in other
contexts. These location representations may be absolute or
descriptive.
e. Specify an IANA registration process for additional
representations.
Spatial Location Protocol (SloP) Requirements July 2000
f. Permit at a minimum, the following values to be included in a
report, providing that the specified scheme and format have such
capability to specify:
1. Used location type (e.g absolute/descriptive location),
framework (e.g. WGS84, UTM, etc), and syntax/format (e.g.
long, lat., alt. in degrees).
2. Geocentric Position
3. Accuracy
4. Exactness
5. Time stamp (date, time, time zone)
6. Time-to-live
7. Direction
8. Velocity
9. Update frequency (??? do we want to include this?)
10. Orientation
g. Permit multiple scheme/format representations in a single report.
h. Client MUST be able to request certain elements of a format.
i. Server MUST be able to provide certain elements of a format based
on authorization policy (ex: give my speed, but not my position).
j. Server MUST be able to obfuscate a (numeric/coordinate) location
based on authorization policy.
k. Be extendable to support new location representations.
5. Message Coding
The protocol:
a. MUST support multiple formats. Each format must be registered
with IANA.
b. MUST support a very simple format for latitude, longitude, and
altitude.
c. MUST support a format for timestamp.
d. SHOULD have a provision to specify the accuracy of each
coordinate/measurement.
e. MUST support a mechanism to allow sending of multiple formats in
a single payload.
f. MUST gracefully handle receipt of formats clients do not
understand.
g. MUST be able to infer the IANA type and the beginning and end of
each format without parsing the entire message (as in TLV).
h. MUST support sending multiple instances of the same format within
the same packet.
i. MUST allow formats to contain raw binary, UTF-8, UTF-16, or UTF-
32 content.
j. Must support formats which contain human-readable text. Such
text SHOULD specify the appropriate language.
k. MUST be extensible/flexible enough to support a future
descriptive location format.
Spatial Location Protocol (SloP) Requirements July 2000
l. Formats which tend to be large SHOULD support a simple
compression mechanism.
m. Both client and server MUST be able to send and receive formats
larger than a single packet.
6. Representation Negotiation
The protocol must:
a. Provide a mechanism for the server to inform the client which
representations it supports. Such a mechanism must be able to be
invoked prior to the first location report.
b. Provide a mechanism for the client to select which of said
representations it prefers.
c. Provide the capability to provide reports in any representation
d. Provide that following such selection, reports are provided by
the server in the format chosen by the client.
e. Provide a mechanisms for the client to specify the need for
periodic position updates.
f. Provide a mechanism for the client and server to agree upon
periodic position updates.
7. Server Discovery
a. There SHALL be a server discovery mechanism for a client to find
the appropriate server for a given target.
b. The discovery mechanism SHALL work across domains. It SHOULD use
widely deployed mechanisms such as DNS. It SHALL permit server
locations to be changed with TTLs ranging from minutes to months.
c. Targets SHALL be identified with an identifier. The target
identifier SHALL be unique within the domain of the server.
d. Servers SHALL be identified by an identifier. Server names SHALL
be globally unique. A URI of the form slop:haitao-tangs-
phone@airtouch.com would be an appropriate way to identify a
target, using the DNS to find the server.
e. Clients MUST be able to perform DNS A and SRV lookups, and may
support manual configuration and/or other methods to resolve the
IP address of a suitable slop server in an unqualified domain.
f. Translator services should be distinguishable from other servers
during discovery.
g. It is desirable that translator capabilities (supported formats)
can be determined during discovery.
8. Transport
a. The protocol SHALL support UDP transport with retry timers for
reliability.
b. The protocol SHOULD support TCP as an optional transport.
c. The protocol MAY support RTP and/or SCTP as optional transports
Spatial Location Protocol (SloP) Requirements July 2000
d. The protocol SHALL provide a mechanism for the client to request
that location reports be delivered by the server using a client
specified QoS class or using the QoS class of the request. Such
a mechanism SHALL be optional to implement, and SHALL use IETF
DiffServ QoS classes.
9. Security
The protocol must:
a. Provide a mandatory-to-implement, optional-to-use authentication
mechanism from client to server and from server to client. The
mechanism should allow a choice in the algorithm(s) used.
b. Specify how such a mechanism shall be used in the presence of
firewalls and Network Address Translation (NAT) between client
and server.
c. Include mechanisms to allow subsequent location policy decisions
to be based on (possibly multiple) factors in addition to the
identity (or anonymity) or the client, e.g. authentication
mechanism, group membership(s), class-of-user, etc.
d. Provide a mandatory-to-implement, optional-to-use data integrity
and data origin authentication mechanism for all data. The
mechanism should allow a choice in the algorithm(s) used.
e. Provide a mandatory-to-implement, optional-to-use data
confidentiality mechanism. The mechanism should allow a choice in
the algorithm(s) used.
f. Not unnecessarily degrade a client's expectations of privacy.
g. Support anonymous use, as well as authenticated use.
Anonymous use MAY require the server(s) to be able to associate
location with the same (anonymous) client over time.
h. Where possible make use of existing, proven security mechanisms
(e.g. TLS, CMS, IPsec), in particular with respect to
cryptographic transforms.
i. Specify a mechanism for extending the security mechanism for
additional capability.
10. Policy
The protocol must:
a. Provide a mandatory-to-implement, optional-to-use _Policy
Enforcement Point_ mechanism.
b. Provide an optional _Policy Decision Point_ mechanism.
c. Specify how servers obtain policy from a policy storage facility
if the Policy Decision Point mechanism is implemented.
d. Specify a _Policy Information Base_.
e. Provide a mechanism to restrict the information in reports by:
1. Accuracy of location
2. Frequency of report generation
3. Representation format
Spatial Location Protocol (SloP) Requirements July 2000
4. Identity/class of report-requestor
f. Specify the way that the PIB and class-of-user is used to
restrict location information reported by interpreting policy
selected by class of user.
11. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
13. Author's Addresses
Brian Rosen
Marconi
1000 FORE Drive
Phone: +1 724 742 6826
Email: brian.rosen@marconi.com
Jose Costa-Requena
Nokia
Email: Jose.Costa-Requena@nokia.com
Mari Korkea-Aho
Nokia
Email: mari.korkea-aho@nokia.com
Mika Ylianttila
Centre for Wireless Communications
PL 4500, Tutkijantie 2 E, FIN-90014
University of Oulu, Finland
Email: over@ees2.oulu.fi
Rohan Mahy
Cisco Systems
170 W Tasman Dr, MS: SJCI/2/3
San Jose, CA 95134
+1 408 526 8570
rohan@cisco.com
Kenji Takahashi
Information Sharing Platform Laboratories
NTT
3-9-11 Midoricho
Musashino, Tokyo 180-8585 Japan
Spatial Location Protocol (SloP) Requirements July 2000
Phone: +81 422 59 6668
e-mail: kt@nttlabs.com
Stephen Farrell
Baltimore Technologies
61 Fitzwilliam Lane
Dublin 2. Ireland
Phone: +353 1 647 7406
email: stephen.farrell@baltimore.ie
14. Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
| PAFTECH AB 2003-2026 | 2026-04-20 14:36:53 |