Network Working Group G. S. Kartha Internet-Draft Independent Intended status: Informational 20 January 2026 Expires: 24 July 2026 Geospatial Resource Discovery (GRD): Problem Statement and Conceptual Architecture draft-kartha-grd-01 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 24 July 2026. Kartha Expires 24 July 2026 [Page 1] Internet-Draft Geospatial Resource Discovery January 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 3 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 5. Design Guidelines . . . . . . . . . . . . . . . . . . . . . . 4 6. Conceptual Architecture . . . . . . . . . . . . . . . . . . . 4 7. Volumetric Query Concept . . . . . . . . . . . . . . . . . . 5 8. Relationship to Existing Work . . . . . . . . . . . . . . . . 6 8.1. IETF Standards . . . . . . . . . . . . . . . . . . . . . 6 8.2. OGC and GIS Standards . . . . . . . . . . . . . . . . . . 6 9. Security and Trust Challenges . . . . . . . . . . . . . . . . 7 9.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 7 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 10.1. Attacker Model . . . . . . . . . . . . . . . . . . . . . 7 10.2. Measurable Privacy Goals . . . . . . . . . . . . . . . . 7 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Illustrative Data Model . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction 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 Kartha Expires 24 July 2026 [Page 2] Internet-Draft Geospatial Resource Discovery January 2026 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 is intended to inform future work on interoperable spatial discovery mechanisms, potentially including protocol specifications. 2. Scope and Non-Goals 2.1. Scope 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. 2.2. Non-Goals 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. 3. Terminology 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: A cryptographic root of trust (e.g., a Public Key) configured on the client and used to validate data associated with a specific Semantic Layer (e.g., "Safety" or "Transit") within a given context. Kartha Expires 24 July 2026 [Page 3] Internet-Draft Geospatial Resource Discovery January 2026 4. Problem Statement 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., [RFC5870]), 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 commonly supported in interoperable discovery mechanisms. 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. 5. Design Guidelines 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 need to be integral to the design and should limit the precision of location data exposed to discovery services. 6. Conceptual Architecture 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. Kartha Expires 24 July 2026 [Page 4] Internet-Draft Geospatial Resource Discovery January 2026 +---------+---------+---------+ | Cell A | Cell B | Cell C | | | | | +---------+---------+---------+ | Cell D | Cell E | Cell F | | (Index) | (Index) | (Index) | +---------+---------+---------+ | Cell G | Cell H | Cell I | | | | | +---------+---------+---------+ Figure 1: Hierarchical Spatial Grid A GRD resolver functions as a directory service. The term "resolver" is used descriptively and does not imply a standardized network role. 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. 7. Volumetric Query Concept 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. Kartha Expires 24 July 2026 [Page 5] Internet-Draft Geospatial Resource Discovery January 2026 / \ / \ <-- View Frustum / \ / \ +-----/---------/-----+ | Cell X | Cell Y | | <-- Client requests Cell X + Y +--------+--------+---+ (Standard HTTP GET) Figure 2: Frustum-to-Cell Intersection 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. 8. Relationship to Existing Work 8.1. IETF Standards RFC 5870 ('geo' URI) defines a method to identify a physical location but does not define a mechanism to retrieve resources associated with that location. GRD complements RFC 5870 by providing the resolution layer. RFC 9176 (CoRE Resource Directory) enables resource discovery on constrained networks but relies on network endpoints rather than geodetic context. It does not support volumetric or spatial-context queries (e.g., "what is visible from this coordinate"). RFC 6763 (DNS-SD) is effective for local service discovery via multicast or administrative domains but cannot scale to global, location-based queries required for open spatial computing. 8.2. OGC and GIS Standards OGC standards (e.g., WFS, OGC API - Features) are designed for complex querying of heavy geospatial databases. GRD is designed as a lightweight, low-latency resolution service (conceptually similar to DNS in its indirection role) for real-time spatial computing, handing off the heavy data transfer to application-specific protocols. Kartha Expires 24 July 2026 [Page 6] Internet-Draft Geospatial Resource Discovery January 2026 9. Security and Trust Challenges 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. 9.1. Trust Model GRD cannot rely on a single global root of trust. Instead, trust must be contextual and scoped by semantic layer. A "Safety" layer might rely on a government Trust Anchor, while a "Commercial" layer might rely on a different registry. The architecture is expected to require that Spatial Resource Records (SRRs) carry cryptographic signatures verifiable against the client's configured Trust Anchors for that specific layer. 10. Privacy Considerations 10.1. Attacker Model The GRD Resolver is modeled as an Honest-but-Curious adversary. It is trusted to return correct spatial records but is assumed to log queries in an attempt to reconstruct client trajectories. 10.2. Measurable Privacy Goals Privacy risks are mitigated by enforcing minimum cell granularity (k-anonymity), intended to ensure that a query does not uniquely identify a user within a small physical area. Additionally, the architecture is expected to avoid reliance on persistent session identifiers that allow the Resolver to correlate separate queries to a single device (Unlinkability). 11. IANA Considerations This document does not request any IANA actions. 12. References [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", RFC 5870, June 2010, . Kartha Expires 24 July 2026 [Page 7] Internet-Draft Geospatial Resource Discovery January 2026 [RFC9176] Shelby, Z., Koster, M., and C. Bormann, "Constrained RESTful Environments (CoRE) Resource Directory", RFC 9176, April 2022, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013, . Appendix A. Illustrative Data Model This appendix is non-normative and illustrates the type of data a resolution service might return. { "cell_id": "8928308280fffff", "resources": [ { "id": "res-12345", "type": "safety.warning", "location": { "lat": 52.3, "lon": 4.9, "alt": 10 }, "layer": "infrastructure", "uri": "https://city-assets.example.com/signs/stop.glb", "validity_ms": 60000, "signature": "ab382...[cryptographic proof]" } ] } Figure 3 Author's Address Gokul Sivasankaran Kartha Independent Email: kartha.gokul@gmail.com Kartha Expires 24 July 2026 [Page 8]