Hi,
The attached is the description and agenda of Spatial Location BOF (spatial)
for IETF#48. Those interested are encouraged to attend. Thanks.
Regards,
Haitao Tang
James M. Polk
------------- cut here ----------------
Spatial Location BOF (spatial)
Chair(s):
Haitao Tang <[EMAIL PROTECTED]>
James M. Polk <[EMAIL PROTECTED]>
Applications Area Director(s):
Patrik Faltstrom <[EMAIL PROTECTED]>
Ned Freed <[EMAIL PROTECTED]>
Applications Area Advisor:
Patrik Faltstrom <[EMAIL PROTECTED]>
Mailing Lists:
General Discussion: [EMAIL PROTECTED]
To Subscribe: [EMAIL PROTECTED] ('subscribe ietf-spatial' in
body)
Archive: http://www-nrc.nokia.com/mail-archive/ietf-spatial/
Other Archived Files: http://www-nrc.nokia.com/ietf-spatial/others.html
Description:
As more and more resources become available on the Internet, there are
immediate and pressing needs for some applications to acquire spatial
location information about certain resources. These applications include
navigation, emergency services, management of equipment in the field, and
other location based applications.
However, there is no standard way for an application to get the information
over the Internet, although there are many methods to determine spatial
location of the resources. The purpose of Spatial Location WG is to develop
a protocol to solve the problem: How can an application acquire the spatial
location of an identifiable resource over/represented on the Internet, in a
reliable, secure, and scalable manner?
The protocol delivers the spatial location of an identifiable resource from
a device that knows the location to an application that needs to know the
location of the element. The work items for the protocol, called as Spatial
Location Protocol (SLoP), are:
1. Spatial Location Representations. There is the need to support different
location data representations/expressions. For interoperability reasons, we
need to have an absolute location system as the supported format by all SLoP
speakers. Its data format should be selected as such, e.g., longitude,
latitude, and altitude, with timestamp and accuracy. It is needed to list
all other absolute location systems and their data formats, which may be
supported by SLoP on an optional basis. Provisions should be made to support
new location systems and data formats. Support for descriptive locations,
when needed, should be added, while no syntax and standard will be defined
in the
current SLoP scope.
2. Representation Negotiation Mechanism. There must be a representation
negotiation mechanism designed. The mechanism must be able to support the
selection of the wanted location system and data format between two SLoP
speakers. Usually, a server has some options while a client may have only
few of them. The descriptive location negotiation is not considered part of
the current SLoP scope.
3. Security Mechanisms. There must be an authentication mechanism
selected/defined between SLoP speakers, to guarantee the
integrity/authenticity/accessibility (e.g., no spoofing and certain DOS
attacks) of the involved parties. There must be an encryption system
selected/defined to guarantee the privacy/confidentiality of the transferred
information between SLoP speakers. As an option, it would be preferred to
select/define a mechanism to guarantee availability (preventing
denial-of-service) for a SLoP speaker. Use of the authentication and/or the
encryption mechanisms should be setable by the
SLoP endpoint (user may enable or disable the use of the mechanisms). It is
done per session or per SLoP endpoint. The primary design for security in
SLoP must be end-to-end. When end-to-end security is not possible for
certain cases, then hop-by-hop security associations could be used between
the server and the client if allowed by the related policy for a target.
There are several mechanisms that can be used to build security
associations. The specific mechanisms for use are needed to be figured out.
All the mechanisms here should be affected by the related policies.
4. Policy Mechanisms. There must be a policy specification language
selected/defined for specifying various policies that are relevant to SLoP.
A PIB must be defined for all SLoP speakers. There must be basic sets of
security policy, locatability policy, accuracy policy, and explicitness
policy defined for all SLoP users, where any new relevant policy rule can be
appended into a set if needed, given it is specified via the language.
Privacy policy is in fact built from the combination from the four policy
sets. The policy instance for a target should be available to the server
representing the target, where the policy instance tells how a server shall
serve the spatial location of the target.
5. Server Discovery Mechanism. There should be a discovery mechanism
selected/ defined for client to find the appropriate server for a given
target when needed.
6. Transmission and Reliability Mechanism. The design of a reliability
mechanism is affected by the transport protocol below SLoP. Various
transport protocols have different reliable levels. If TCP is selected,
there is no need to have this extra mechanism. However, TCP seems too heavy
for some SLoP speakers. UDP is thus likely to be selected. If so, a
reliability mechanism must be designed into SLoP.
7. SLoP Message Coding Mechanism. There must be a coding mechanism selected/
designed for coding/decoding all SLoP messages. The coding mechanism must be
supported by all SLoP speakers.
TIME/PLACE: MONDAY, July 31, 2000, 1930-2200
Pittsburgh Meeting Agenda (150 min):
5 min Agenda Bashing
15 min Haitao Tang - Scope of This Effort
35 min Brian Rosen - Spatial Location Protocol Requirements
(draft-rosen-spatial-requirements-00.txt)
10 min Rohan Mahy - A Simple Text Format for the Spatial Location
Protocol (draft-mahy-spatial-simple-coord-00.txt)
10 min Haitao Tang - Target Naming Scheme
(draft-tang-spatial-target-00.txt)
10 min John Loughney - Basic SLoP Architecture Proposal
(draft-loughney-spatial-arch-00.txt)
20 min James M. Polk - Charter Bashing
10 min Haitao Tang - Review of Milestones and Group Status
