Visual RFC.
ALL RFCs / RFC 5870
Read the RFC ↗
RFC 5870 / GEOGRAPHIC LOCATION LINKS

Validate before using or sharing

05

A parser can read a string that still fails geographic or reference-system checks. Sharing it can reveal a person’s location in context.

DIAGRAMRead RFC section 9.1 ↗
RFC 5870 · § 9.1EXAMPLE
3 / 3
Validate before using or sharingTwo independent invalid-use examples first deliver a URI to a parser. geo94 comma0 arrives but its latitude is out of range, so downstream location use is stopped and a warning is recommended. Next a consumer receives an illustrative unknown crs example and stops a silent fallback to WGS84 rather than ignoring the CRS. The final separate fictional public message links Alex to a location URI; an observer can read this association. This is disclosure in context, not a safe path stopped by geo syntax. The scheme identifies no Target itself and provides no confidentiality or access permission.Validate use; examine the sharing contextPublic messageAny readerpublic context is readableFictional: “Alex is here”geo:13.4125,103.8667Context identifies a Target’s locationGEOPRIV requirements MUST be metSyntax supplies no confidentiality or identity proof
03
Review the sharing context.

A fictional message “Alex is here” plus a geo URI links a person to coordinates. Anyone who sees the public message can read that association; geo syntax supplies no confidentiality. Applicable GEOPRIV requirements still apply.

Source for this drawing: RFC 5870 · Read RFC section 9.1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 3986 URI syntax

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
GEOPRIV
IETF geographic location privacy requirements, including the rules of RFC 3693 when a location is associated with a Target.
Target
The entity whose location is described by the surrounding context; the bare geo URI has no identity field.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Validate the reference system and ranges; consider the sharing context.

  • Latitude outside -90…90 or longitude outside -180…180 is invalid in WGS-84. Applications MUST NOT use invalid locations and SHOULD warn the user; syntax acceptance alone is insufficient.
  • Consumers MUST NOT ignore an explicit crs, or interpret coordinates without understanding it. crs and u MUST NOT repeat; they MUST precede extensions, with crs first when both occur. Unknown CRS is not permission to fall back to WGS-84.
  • A geo URI has no built-in Target identity or access-control field. In context that identifies a Target’s location, RFC 3693 privacy requirements MUST be met. This is not a location permission or proof that a named person is there.
DETAILS

The first two scenes are separate validation failures; bad input arrives at the parser and only its unsafe use is stopped. “example” is an illustrative unknown CRS, not a registered system. The final fictional public picnic message illustrates disclosure, not a real person’s location. Extensions require specification/registration; this guide does not invent one.

Read the RFC section ↗

All chapters in RFC 5870

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗