Résumé

  • RFC 5139 remplace la première forme civique de PIDF-LO par un vocabulaire XML plus précis, inspiré notamment de l’option civique DHCP.
  • La hiérarchie route, section, branche et sous-branche empêche de réduire des systèmes d’adressage locaux à une simple chaîne « rue ».
  • Le numéro de voirie se rattache à l’élément routier le plus précis fourni ; cette règle interprétative ne garantit pas que la valeur soit vraie.
  • Les variantes linguistiques doivent rester dans des blocs distincts ; une préférence de langue sélectionne une présentation, pas une réalité.
  • Le type XML token réduit les espaces ordinaires avant traitement, ce qui sépare le document brut de la valeur vue par l’application.
  • Une adresse détaillée peut provenir d’un annuaire ancien ; une localisation plus grossière peut être la seule observation récente.
  • Une signature ou un transport authentifié attribue l’assertion à une source, sans démontrer l’exactitude de ses composants.
  • La précision civique décrit une zone d’incertitude ; elle ne crée ni point géographique unique ni occupation effective d’une pièce.
  • Les règles PIDF-LO relatives au destinataire, à la conservation et à la retransmission restent indépendantes de la syntaxe civique.
  • La validation LoST et le transport SIP produisent des reçus de routage, non des preuves d’intervention réussie.
  • Il faut préserver les états « ancien », « contradictoire », « masqué par politique » et « plusieurs candidats », plutôt que les convertir en succès.
  • La direction doit relier observation, politique, cartographie, acheminement, prise en charge et résultat par des reçus séparés.

La préférence linguistique n’est pas un arbitre

RFC 5139 autorise xml:lang sur les éléments porteurs de langue, mais pas sur le pays ni le type de lieu, traités comme valeurs neutres dans leurs registres. Le script peut être indiqué par un sous-tague de langue. Une adresse civique devrait employer une seule langue, ou un mélange cohérent ; plusieurs versions du même lieu devraient apparaître dans plusieurs blocs civicAddress appartenant au même tuple.

Cette architecture respecte une réalité souvent perdue dans les bases internationales : une adresse locale n’est pas forcément la traduction mot à mot d’une forme dite canonique. Les noms officiels, les écritures, les abréviations et l’ordre des composants peuvent varier. Conserver chaque forme est plus honnête que les fusionner.

Le passage depuis RFC 4776 montre toutefois la limite. Le format DHCP peut répéter un composant pour plusieurs langues ou scripts, alors que le bloc XML n’en accepte qu’une occurrence. La conversion peut donc créer un bloc par langue et recopier les valeurs neutres. Si le destinataire annonce ses préférences, les valeurs reçoivent des poids. En cas d’égalité, d’absence de préférence correspondante ou de conflit dans une même langue, le texte permet un choix arbitraire.

« Arbitraire » suffit à poursuivre l’interopérabilité. Il ne signifie pas « vérifié ». Un journal qui ne garde que la valeur gagnante détruit la preuve du conflit. Il faut enregistrer toutes les variantes, leurs tags, la liste de préférences, le calcul de poids et la raison exacte de la sélection.

Un index de recherche peut construire une clé secondaire, mais il ne doit pas déclarer deux formes équivalentes sans autorité locale ou rapprochement vérifié. La langue décide de ce que l’on affiche ; elle ne décide pas à elle seule de l’endroit où se trouve une personne.

Ce que la hiérarchie de voirie sauve

RFC 5139 ajoute des champs pour le bâtiment, l’unité, la pièce, le siège, la communauté postale et une hiérarchie de voirie : route principale, section, branche, sous-branche. Dans certains pays, le même numéro réapparaît dans plusieurs sections. Deux voies secondaires peuvent partager un nom et n’être distinguées que par leur relation à une voie principale.

Le numéro HNO s’applique donc au composant routier le plus spécifique : sous-branche, branche, section ou route. Les qualificatifs de direction concernent RD; ceux d’une branche doivent être inscrits dans la valeur de cette branche. A6 peut conserver son rôle administratif local, mais ne doit plus servir de nom de rue.

Ces règles évitent une ambiguïté de modèle. Elles n’empêchent pas une donnée erronée d’occuper le bon champ. Le pays en deux lettres majuscules et la subdivision recommandée selon ISO contraignent la forme, pas la vérité. Le registre IANA donne un sens partagé à un CAtype, pas un certificat à chaque valeur reçue.

Un contrôle sérieux conserve l’ordre des composants, la version du schéma, les extensions comprises ou ignorées et le guide national appliqué. Si un géocodeur retourne un seul objet, il faut encore savoir combien de candidats existaient, quels champs ont été normalisés et quelle édition du jeu de données a été consultée. Une ligne unique en base n’est pas nécessairement un lieu unique dans le monde.

Le parseur modifie déjà la preuve

Les valeurs civiques de RFC 5139 dérivent du type XML Schema token. Les espaces ordinaires sont normalisés et réduits avant d’être transmis au traitement. Des fragments XML écrits avec des retours de ligne et des espaces multiples peuvent ainsi produire la même valeur. Une référence de caractère peut maintenir un espace nécessaire.

Il faut donc distinguer l’octet signé ou archivé, le document XML, la valeur DOM et la chaîne stockée. Un contrôle d’intégrité sur le document brut ne prouve pas la chaîne finalement comparée ; une trace applicative ne permet pas toujours de reconstruire l’entrée reçue.

Le schéma accepte aussi des éléments d’autres espaces de noms et des attributs libres. Cette ouverture rend l’extension possible, mais deux consommateurs peuvent comprendre des sous-ensembles différents. Le badge « schéma valide » doit être accompagné de la liste des extensions reconnues, des avertissements et des informations perdues.

Pour un usage à conséquences fortes, l’original immuable, le parseur, la version du schéma, le résultat normalisé et la décision doivent rester reliés. Une transformation silencieuse ne peut pas être qualifiée de simple nettoyage lorsqu’elle modifie une clé utilisée pour le routage.

Une adresse a besoin d’une histoire d’observation

RFC 5491 clarifie les rôles que les interfaces effacent facilement. La cible est l’objet localisé. La source fournit l’information. La méthode détermine la localisation. Le protocole de configuration la transporte. Confondre ces quatre choses revient à attribuer à un message la capacité d’observer le monde.

Pour réunir une localisation civique et une forme géodésique en un ensemble, les composants doivent partager source, instant et méthode. Sinon, un numéro de pièce tiré d’un annuaire peut raffiner artificiellement une zone réseau récente. Les deux données peuvent être exactes séparément et fausses une fois assemblées.

Le temps doit être explicite. La complétude n’est pas la fraîcheur. Un profil RH très détaillé peut dater d’avant un déménagement ; une observation de réseau moins précise peut être récente. Une adresse saisie par l’utilisateur, fournie par DHCP, issue d’un serveur de localisation ou recopiée d’un registre possède chaque fois une autorité et une durée différentes.

Le reçu minimal lie l’identité de la cible, la source, la méthode, l’interface d’acquisition, le moment de l’observation, l’émission et l’expiration. Si l’appareil sert de proxy à une personne, cette relation doit être déclarée. La présence de l’appareil ne prouve pas celle de son propriétaire.

L’authentification protège l’origine et l’intégrité. RFC 7378 rappelle que cela ne rend pas la localisation digne de confiance par magie : une source authentifiée peut se tromper, être compromise ou décrire le mauvais objet. La provenance permet d’attribuer une assertion ; elle ne la transforme pas en fait physique.

La précision, la confiance et l’actualité sont trois axes

RFC 7459 traite une localisation comme une estimation. Pour une adresse civique, l’incertitude dépend de la zone couverte par le composant fiable le plus précis. Un bâtiment reste une zone. Une pièce aussi. Un siège nommé ne prouve pas qu’il est occupé.

L’absence d’un champ fin peut signifier qu’il est inconnu, inutile ou retiré pour protéger la vie privée. L’absence d’une mesure d’incertitude ne signifie jamais incertitude nulle. Il faut garder séparées la granularité de la description, la confiance dans la présence de la cible dans cette zone et l’âge de l’observation.

Le géocodage ajoute encore un choix : plusieurs candidats, centroïde, entrée, parcelle ou point de toit. Le système doit conserver les candidats et la version du référentiel. Un point dérivé d’une adresse n’est pas une mesure de la pièce ; une coordonnée située dans un immeuble ne reçoit pas automatiquement le bon étage.

La norme commune reste volontairement mince. Elle permet aux autorités locales et aux implémentations de respecter leurs pratiques. Cette autonomie n’est défendable que si leurs transformations demeurent visibles et testables dans le code réellement déployé.

La confidentialité ne vient pas du bon ordre des balises

PIDF-LO associe la localisation à des règles d’usage. RFC 6280 sépare cible, auteur des règles, serveur de localisation et destinataire. Savoir lire un étage ne donne aucun droit sur cet étage. L’autorisation doit indiquer le destinataire, le but, la précision, la conservation, la retransmission et la révocation.

RFC 6772 permet de réduire la précision selon la politique. Un destinataire peut recevoir la ville sans la pièce alors que la source connaît les deux. Réenrichir automatiquement la donnée depuis un second fichier annule cette protection. Un champ manquant peut être la preuve que la politique a fonctionné.

Le code pays décrit la donnée localisée ; il ne dit ni où elle est stockée, ni quelle juridiction contrôle le traitement. Déduire la souveraineté de traitement à partir de la géographie du sujet serait une nouvelle confusion de couches.

Le risque irréversible vient des copies. Une fois la localisation précise diffusée dans les tickets, analyses et sauvegardes, une politique ultérieure ne récupère pas toutes les répliques. La minimisation avant divulgation est plus forte qu'une promesse d'effacement après usage.

Un bon routage ne confirme pas la présence

LoST peut valider une localisation civique et associer un service et un lieu à une URI. SIP peut porter ou référencer la localisation. Ces protocoles donnent des reçus importants : requête, avertissements, mapping, limite, expiration, livraison et décision de permission.

Ils ne prouvent ni que la cible est présente, ni qu’un centre a accepté l’appel, ni que l’adresse a été comprise, ni qu’une unité a été envoyée, ni qu’elle est arrivée. L’issue opérationnelle appartient à une chaîne plus longue.

Les essais doivent inclure l’adresse ancienne mais complète, l’adresse récente mais grossière, les variantes linguistiques contradictoires, les branches homonymes, la pièce masquée par politique, plusieurs candidats géocodés, le destinataire non autorisé et le mapping expiré. Un résultat global vert est insuffisant : chaque étape doit publier sa propre connaissance et son propre doute.

RFC 5139 réduit la perte d’information dans la première étape. Le déploiement mature respecte ce progrès en refusant de lui faire certifier toutes les étapes suivantes.

Sources

  1. RFC 5139, HTML
  2. RFC 5139, texte brut
  3. Fiche RFC Editor de RFC 5139
  4. Fiche IETF Datatracker de RFC 5139
  5. Historique de RFC 5139
  6. Recherche d’errata RFC 5139
  7. RFC 4119 : PIDF-LO
  8. RFC 4776 : option DHCP d’adresse civique
  9. RFC 5491 : usage de PIDF-LO
  10. RFC 7459 : incertitude et confiance
  11. RFC 7378 : localisation digne de confiance
  12. RFC 6280 : architecture de localisation et de confidentialité
  13. RFC 5222 : LoST
  14. RFC 6442 : transport de localisation dans SIP
  15. RFC 6772 : politique de géolocalisation
  16. RFC 6848 : extensions de localisation civique
  17. RFC 5646 : tags de langue
  18. RFC 4589 : registre des types de lieu
  19. Registre IANA des types d’adresse civique
  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