Summary

  • RFC 3693 made a location service name the Target, Rule Maker, Rule Holder, Generator, Server, Recipient and Viewer instead of treating disclosure as a two-party exchange.
  • It described a Location Object that could carry privacy rules, but did not require every object to contain them or specify the whole rule-management system.

A coordinate answers “where?” It does not answer who supplied it, whose location it describes, who may see it, at what resolution, or whether a recipient may keep or forward it. Those missing verbs were the problem GEOPRIV set out to make visible.

RFC 3693, published in February 2004 as an Informational document, organized the problem around roles. The Target is the person or other entity being located. A Rule Maker creates access rules—typically the Target, but not always. The RFC's examples allow a parent or an employer to make rules for someone else. A Rule Holder stores and supplies them. A Location Generator gathers a position and creates an object; a Location Server receives it, applies rules and distributes permitted results; a Location Recipient receives it; and a Viewer consumes it without forwarding. A separate Data Transporter may forward information without processing it. Several roles can live in one device.

That vocabulary mattered because privacy depended on relationships, not merely encryption. A rule could let a credential holder learn a coarse location, such as a city, while withholding a more precise one. The RFC also called for pseudonyms and privacy-enhancing credentials, and treated collection, use, disclosure and retention as different rule subjects. It warned that revealing who receives location can itself expose a Target's habits or relationships.

The Location Object was deliberately more than a coordinate envelope—but not automatically a policy-enforcement token. RFC 3693 required that it permit third-party enforcement and said it should be able to carry a limited core of rules. Yet it described the object as carrying location information “and possibly privacy rules”: an instance did not have to embed them. The Location Server's disclosure decision had to be based on Rule Maker-defined rules, while a Generator lacking the full rule set still had to follow the Maker's instructions. A Viewer should receive only the subset needed for compliant handling.

The gaps were explicit. RFC 3693 left rule management and the Server's access to rules out of scope. It did not settle the language or full expressiveness of rules. A retention limit could have unclear technical consequences and partly depend on local law or custom. It required rules to be authenticated and protected but left key distribution and detailed mechanisms to other work. Nor did protecting the Location Object stop traffic analysis of other headers and objects.

Later documents show the next steps in specification, not proof of universal use. RFC 4119 defined a PIDF-based location-object format; RFC 4079 described a presence architecture. RFC 6280, published in 2011 as BCP 160, updated RFCs 3693 and 3694 and expanded their requirements into an architecture. HELD, SIP conveyance and location-URI dereferencing then specified particular ways to acquire, carry or retrieve location.

The historical achievement was narrower than “the Internet solved location privacy.” RFC 3693 made the control surface legible: who is located, who makes rules, where rules live, who applies them, which precision is released, and what a downstream recipient may do. A requirements document can name those boundaries. It cannot establish that a service implemented them, that a recipient obeyed them, or that a person remained anonymous.

Sources