Independent

kartha.gokul@gmail.com

The Internet provides standardized mechanisms for resolving identifiers, such as domain names, to network locations. These mechanisms assume that a client already knows the identifier of the resource it wishes to access. Emerging classes of applications, including augmented reality, autonomous systems, robotics, and spatial computing, operate under a different assumption. In these systems, discovery begins with physical presence and observer context rather than with a predefined name. This document describes the architectural gap addressed by a Geospatial Resource Discovery service. It defines the problem space, explains why existing standards are insufficient, and outlines a conceptual architecture for spatial discovery. This document is informational and architectural in nature. It does not define a protocol, data format, or implementation.

Internet architecture has historically focused on resolving semantic identifiers into network endpoints. Systems such as the Domain Name System enable scalable communication by assuming that clients already know the name of the resource they are attempting to reach. Emerging spatial systems invert this assumption. In augmented reality, autonomous navigation, and smart environments, discovery begins with physical location and context. A user or machine operating at a specific coordinate needs to ask what digital information is associated with the surrounding space and visible volume. At present, this type of discovery occurs inside closed ecosystems. Each platform maintains its own spatial maps, registries, and access mechanisms. While effective within individual systems, these approaches do not interoperate. This document argues that spatial discovery represents a missing architectural layer and describes the requirements for an open Geospatial Resource Discovery capability.

This document focuses on the application layer. It describes a discovery pattern that can operate over existing transports such as HTTP/3 or CoAP. It intentionally avoids assumptions about rendering engines, device capabilities, or user interface models.

This document does not propose changes to IP routing or DNS semantics. It does not define legal ownership of physical space, geometric rendering standards, or a global governance model for spatial authority.

Spatial Resource: A digital asset associated with a physical location or volume, such as an augmented reality annotation, navigation marker, or machine-readable instruction. Spatial Cell: A discrete geospatial region used for indexing and lookup, typically derived from a hierarchical grid system. Frustum: A three-dimensional volume defined by an observer's position, orientation, and field of view. Trust Anchor: An entity considered authoritative for a specific category of spatial information within a given context, without implying a single global root of trust.

The Internet lacks a standardized mechanism to discover digital resources based on physical location and observer context. Existing discovery mechanisms resolve names rather than locations. While geographic identifiers exist (e.g., ), there is no standard protocol that allows a client to query a location and receive a list of available spatial resources. Spatial data is also highly application-specific. Autonomous vehicles, wearable devices, and smart infrastructure systems operating in the same physical environment cannot discover or consume each other's data unless they share a proprietary backend. In addition, current application protocols do not natively support volumetric queries. Requests such as retrieving resources within a three-dimensional viewing volume are not directly expressible. Finally, many spatial resources are dynamic and time-sensitive. Real-time spatial information, such as hazards or temporary instructions, requires low latency and short validity periods. Traditional caching assumptions are poorly suited to these constraints.

Any future specification for Geospatial Resource Discovery should follow a small set of architectural principles. The design should remain independent of transport and operate over existing Internet protocols. Complex geometric calculations should be performed by the client to preserve resolver scalability. Discovery should support semantic filtering so that clients can request only relevant categories of information. Privacy considerations must be integral to the design and should limit the precision of location data exposed to discovery services.

This section outlines a conceptual architecture referred to as Geospatial Resource Discovery (GRD). The physical world is divided into discrete spatial cells using a standard hierarchical indexing system. Representing space in this way allows spatial discovery to be reduced to key-based lookups rather than continuous geospatial computation.

A GRD resolver functions as a directory service. It maintains references to spatial resources indexed by cell identifier and returns pointers to the actual assets. The resolver does not host large content objects such as three-dimensional models. Authority over physical space is not strictly hierarchical. Multiple independent entities may publish resources associated with the same spatial cell. This introduces a fundamental architectural choice between client-side aggregation of multiple authorities and resolver- side federation of records. For example, a federated resolver simplifies client logic and can vouch for aggregated data integrity, but requires coordination among authorities. Client-side aggregation offers greater autonomy and avoids a central point of coordination but places the burden of trust evaluation and result merging on each client.

To balance scalability and privacy, GRD follows a coarse query and fine filter model. The client computes its precise view frustum locally and determines which standard spatial cells intersect that volume. It then queries the resolver for resources associated with those cells, optionally filtered by semantic category. This translation from a continuous geometric volume to discrete cell identifiers allows spatial discovery to leverage standard, cache-friendly HTTP request semantics for what is inherently a spatial query.

The client performs final filtering locally and discards resources that fall outside the exact viewing volume. This approach ensures that the resolver does not learn the client's precise orientation or gaze direction.

Existing standards address related but distinct problems. Emergency location and civic addressing (e.g., GEOPRIV) focus on determining where a client is located rather than discovering content at that location. Traditional geospatial standards (e.g., OGC) emphasize rich data transfer and are often too heavy for low-latency, real-time discovery. Local service discovery mechanisms (e.g., DNS-SD) operate at network scope and do not scale to global spatial resolution. Proprietary augmented reality platforms demonstrate feasibility but do not provide interoperability. GRD aims to bridge these gaps at the architectural level.

A primary risk in spatial discovery is reality poisoning: the injection of false or malicious information that directly alters a user's perception of the physical world. The safety implications are significant—consider the effect of a counterfeit right-of-way marker for an autonomous vehicle or a hallucinated safe path over a physical hazard for a first responder. GRD cannot rely on a single global root of trust. Instead, trust must be contextual and scoped by semantic layer and authority. A spatial trust chain model is required, where specific entities are recognized as authoritative for specific categories of information.

Querying spatial cells reveals approximate location information. Privacy risks can be mitigated by enforcing minimum cell granularity, allowing clients to request additional adjacent cells to obscure movement patterns, and avoiding persistent state at resolvers. Privacy should be treated as a core architectural requirement.

This document does not request any IANA actions.

This appendix is non-normative and illustrates the type of data a resolution service might return.