Zusammenfassung

  • RFC 5139 ersetzt die ursprüngliche zivile PIDF-LO-Darstellung durch ein erweitertes XML-Vokabular auf Grundlage der DHCP-Adresstypen.
  • Straße, Abschnitt, Abzweig, Unterabzweig, Gebäude, Raum und Sitzplatz erhalten getrennte Bedeutung.
  • Schemagültigkeit belegt eine Darstellung, nicht die gegenwärtige Anwesenheit eines Menschen oder Geräts.
  • Sprachvarianten bleiben getrennte Adressblöcke; eine Sprachpräferenz löst keinen Sachkonflikt.
  • XML token faltet normalen Leerraum und trennt dadurch den Rohbeleg vom Anwendungswert.
  • Zusammengesetzte Ortsangaben benötigen gemeinsame Quelle, Zeit und Bestimmungsmethode.
  • Eine vollständige Kartei kann alt sein, eine grobe Messung neu; Vollständigkeit ist keine Frische.
  • Authentifizierung ordnet eine Aussage einer Quelle zu, macht sie aber nicht physisch richtig.
  • Raum und Sitzplatz verkleinern eine Unsicherheitsregion, ohne Belegung zu beweisen.
  • Empfänger, Zweck, Genauigkeit, Aufbewahrung und Weitergabe sind eigenständige Datenschutzentscheidungen.
  • LoST und SIP belegen Validierung und Transport, nicht Disposition oder Ankunft.
  • Führung muss unbekannt, veraltet, widersprüchlich, reduziert und ungeprüft als echte Zustände erhalten.

Ein grüner Parser hat nichts beobachtet

RFC 5139 behebt eine reale Modelllücke in RFC 4119. Adressen folgen weltweit nicht einem einzigen Schema. Die Revision übernimmt unter anderem Gebäude, Einheit, Raum, Sitz, Postgemeinschaft und zusätzliche Codes aus RFC 4776. Mit RD, RDSEC, RDBR und RDSUBBR bildet sie komplexe Straßenhierarchien ab.

Dies ist nötig, wenn Hausnummern in mehreren Straßenabschnitten wiederkehren oder kleine Wege erst durch ihre Beziehung zu einer Hauptstraße eindeutig werden. HNO bezieht sich auf das jeweils spezifischste vorhandene Straßenelement. Richtungs- und Straßenqualifikatoren der Hauptstraße dürfen nicht still auf einen Abzweig übertragen werden. A6 ist kein Ersatzfeld für Straßennamen mehr.

Die Regeln vereinheitlichen Interpretation, nicht Wahrheit. Ein falscher Wert kann im richtigen Element stehen. Ein Ländercode begrenzt den Wertebereich, beobachtet aber keinen Standort. Eine IANA-Registrierung gibt einem CAtype gemeinsame Semantik und zertifiziert keine Instanz.

Der Betriebsbeleg muss Reihenfolge, Schema- und Landesprofilversion sowie verstandene und ignorierte Erweiterungen erfassen. Ein Geocoder sollte Kandidaten, Normalisierungen und Datenstand offenlegen. Eine einzelne Datenbankzeile kann aus unvollständiger Sicht entstehen und ist kein Nachweis eines einzigen physischen Ortes.

Mehrsprachigkeit bewahrt auch Widerspruch

Sprachtragende Elemente dürfen xml:lang verwenden; Land und Ortstyp gelten in ihren Registern als sprachneutral. Ein Script kann über den Sprach-Subtag erscheinen. Pro Adressblock ist eine Sprache oder eine konsistente Mischung vorgesehen, parallele Formen bleiben in getrennten Blöcken desselben tuple.

RFC 4776 kann ein Element für mehrere Sprachen wiederholen. Die XML-Form erlaubt pro Block nur eine Instanz, weshalb die Umwandlung mehrere Blöcke erzeugen kann. Empfängerpräferenzen gewichten Werte. Bei Gleichstand, fehlender Präferenz oder Konflikt innerhalb einer Sprache ist eine beliebige Auswahl zulässig.

Beliebig bedeutet interoperabel fortfahren, nicht sachlich entschieden. Wer nur den Gewinner speichert, vernichtet den Konfliktbeleg. Alle Kandidaten, Tags, Präferenzen, Gewichte und Entscheidungsgründe gehören ins Protokoll.

RFC 5646 macht Sprach- und Schriftbezeichnungen gemeinsam lesbar. Ob zwei lokale Namen denselben Ort bezeichnen, muss eine zuständige Stelle oder eine geprüfte Zuordnung belegen.

Leerraum macht die Verarbeitung sichtbar

Die zivilen Werte basieren auf XML Schema token. Gewöhnlicher Leerraum wird normalisiert und zusammengezogen; mehrere lexikalische Formen können denselben Anwendungswert ergeben. Zeichenreferenzen können beabsichtigten Leerraum erhalten.

Empfangene Bytes, XML-Dokument, Parserbaum und gespeicherte Zeichenfolge sind deshalb unterschiedliche Belege. Eine Signatur über das Rohdokument beweist nicht automatisch den später verglichenen Wert.

Das Schema erlaubt außerdem fremde Namespace-Elemente und freie Attribute. Zwei gültige Implementierungen können verschiedene Erweiterungen verstehen. Kritische Systeme müssen Original, Parser, Schema, Ergebniswerte, unbekannte Erweiterungen, Warnungen und Verluste festhalten. „Gültig“ ohne Transformationsprotokoll reicht nicht.

Gegenwart braucht Quelle, Methode und Zeit

RFC 5491 trennt Ziel, Quelle, Bestimmungsmethode und Übertragungsprotokoll. Ein Gerät kann als Stellvertreter einer Person dienen, doch auch diese Beziehung ist eine Aussage. Manuelle Eingabe, DHCP, Location Server und Personalverzeichnis besitzen unterschiedliche Autorität und Verfallszeiten.

Zivile und geodätische Informationen dürfen nur mit gemeinsamer Quelle, gemeinsamem Zeitpunkt und gemeinsamer Methode zu einer zusammengesetzten Position werden. Eine alte Raumnummer aus dem Verzeichnis darf eine frische Netzregion nicht künstlich verfeinern.

Der Beleg verbindet Zielidentität, Quelle, Methode, Erwerbsschnittstelle, Beobachtungszeit, Ausgabe und Ablauf. RFC 7378 begrenzt den Authentifizierungsbeweis: Eine echte Quelle kann irren, kompromittiert sein oder das falsche Objekt beschreiben.

Nur eine noch gültige Beobachtung darf das Wort „aktuell“ autorisieren. Feldzahl und Signatur dürfen das nicht.

Granularität ist weder Vertrauen noch Frische

RFC 7459 behandelt Ortung als Schätzung. Bei zivilen Adressen bestimmt das feinste vertrauenswürdige Element ungefähr die Unsicherheitsfläche. Ein Raum ist kleiner als ein Gebäude, aber weiterhin eine Fläche; ein Sitzname zeigt keine Belegung.

Fehlende Details können unbekannt, unnötig oder aus Datenschutzgründen entfernt sein. Fehlende Unsicherheitsangabe bedeutet nie Null. Granularität, Konfidenz und Alter müssen separat bleiben.

Geocodierung wählt zwischen Eingang, Zentrum, Grundstück, Dach oder mehreren Kandidaten. Abgeleitete Koordinaten benötigen die ursprüngliche Adresse, Datensatzversion, Kandidaten und Auswahlregel als Herkunft.

RFC 4589 und das IANA-Register vereinheitlichen Begriffe; RFC 6848 steuert Erweiterungen. Keines davon bestätigt den Inhalt eines konkreten Objekts.

Datenschutz kann absichtlich unvollständig sein

PIDF-LO verbindet Ort und Nutzungsregeln. RFC 6280 trennt Ziel, Regelgeber, Location Server und Empfänger. RFC 6772 erlaubt eine politisch gesteuerte Reduktion der Genauigkeit. Wenn eine Quelle den Raum kennt, der Empfänger aber nur die Stadt sieht, kann die Schutzentscheidung korrekt arbeiten.

Nachträgliches Anreichern aus einer zweiten Datenbank umgeht diese Grenze. Autorisierung muss Empfänger, Zweck, Granularität, Aufbewahrung, Weitergabe und Widerruf binden. Das Land in der Adresse sagt weder Speicherort noch Verarbeitungsrecht aus.

Sobald präzise Standorte in Tickets, Analysen und Backups kopiert wurden, ist ein späterer Rückruf unzuverlässig. Minimierung vor der Offenlegung ist stärker als Löschung danach.

Eine Service-URI ist noch kein Einsatzergebnis

LoST kann einen Dienst und eine Position auf eine Service-URI abbilden und eine zivile Adresse validieren. SIP kann Ortung übertragen oder referenzieren. Anfrage, Warnung, Grenze, URI, Ablauf, Berechtigung und Zustellung sind wertvolle Einzelbelege.

Die richtige Abbildung beweist keine Anwesenheit. Die Übertragung beweist weder Annahme, Interpretation, Disposition noch Ankunft. Jeder Schritt braucht eine eigene Beobachtung.

Tests müssen vollständige alte Adressen, frische grobe Beobachtungen, Sprachkonflikte, gleichnamige Abzweige, politisch entfernte Räume, mehrere Kandidaten, unberechtigte Empfänger, abgelaufene Mappings und operatives Scheitern nach korrektem Mapping trennen.

RFC 5139 verbessert die gemeinsame Beschreibung. Seine Grenze ist Teil dieser Leistung: Ein Ort kann korrekt beschrieben sein, ohne dass jemand dort ist.

Quellen

  1. RFC 5139, HTML
  2. RFC 5139, Text
  3. RFC-Editor-Eintrag
  4. IETF Datatracker
  5. Dokumenthistorie
  6. Errata-Suche
  7. RFC 4119: PIDF-LO
  8. RFC 4776: DHCP-Ziviladresse
  9. RFC 5491: PIDF-LO-Nutzung
  10. RFC 7459: Unsicherheit und Konfidenz
  11. RFC 7378: Vertrauenswürdige Ortung
  12. RFC 6280: Ortungs- und Datenschutzarchitektur
  13. RFC 5222: LoST
  14. RFC 6442: Ortung in SIP
  15. RFC 6772: Geolocation Policy
  16. RFC 6848: Erweiterungen ziviler Ortung
  17. RFC 5646: Sprach-Tags
  18. RFC 4589: Ortstypen
  19. IANA Civic Address Types Registry
  20. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  21. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  22. Running-Code Primary