Spatial Location BOF (spatial) Monday, July 31 at 1930-2200 ============================ CHAIRS: Haitao Tang James M. Polk 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. AGENDA: 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