Résumé

  • RFC 2009 plaçait dans l’adresse multicast la plus petite partition disponible englobant le polygone, mais conservait le contour exact dans le corps du paquet.
  • La diffusion locale des petits détails et les routeurs désignés réduisaient l’état global au prix de chemins non optimaux, de doublons, de faux positifs et d’une décision finale fondée sur une position déclarée.

Une frontière dessinée à la souris n’est pas une destination IP. Elle peut couper plusieurs cellules radio, ignorer les limites d’un comté et changer sans qu’aucune liste d’abonnés ne change. RFC 2009 a donc construit deux adresses superposées : celle que le réseau pouvait transporter et celle que l’expéditeur voulait réellement atteindre.

Les atomes étaient les plus petites surfaces dotées d’une adresse géographique ; les partitions regroupaient plusieurs atomes. Pour une forme trop fine ou irrégulière, le réseau choisissait la plus petite partition disponible qui la contenait. Son adresse multicast guidait le premier trajet. Le polygone original accompagnait toujours le message pour la sélection finale.

Éloigner le détail pour contenir la table

Un arbre multicast complet pour chaque atome aurait produit trop d’état. La proposition limitait donc la portée de l’information en fonction de sa granularité. Le détail d’un atome restait proche ; le niveau comté voyageait davantage ; les grandes partitions pouvaient être annoncées à travers le pays. Un routeur distant cherchait la correspondance exacte, puis rabattait sa décision vers le comté et enfin l’État.

L’agrégation seule ne suffisait pas : plusieurs liens pouvaient tous sembler mener à la même Californie agrégée. RFC 2009 réservait à un ou quelques MSS désignés le droit de propager l’appartenance agrégée d’une partition. Avec un seul représentant, une table distante pouvait ne garder qu’un lien. Le texte reconnaissait qu’un tel choix pouvait allonger le trajet.

Les recouvrements demeuraient. Deux chemins ou deux zones de couverture pouvaient livrer deux copies à la même station. Il fallait encore les reconnaître et les supprimer. Et lorsque la partition débordait largement le polygone, des stations inutiles recevaient le premier signal avant d’être éliminées au bord.

La périphérie comparait, elle ne certifiait pas

Dans une variante, la station de base retransmettait le message et chaque terminal comparait ses coordonnées au polygone. Dans l’autre, elle annonçait un groupe multicast temporaire ; les terminaux se disant à l’intérieur le rejoignaient avant le message principal. La seconde solution dépensait du délai d’adhésion pour éviter des données inutiles.

La source de position restait fragile. Une carte GPS pouvait fournir une mesure dehors. À l’intérieur, où le GPS ne fonctionnait pas, RFC 2009 proposait la position configurée d’une station intérieure. Cette valeur situe une infrastructure, pas le corps d’un utilisateur. Le calcul « dedans » prouve qu’un logiciel a accepté une valeur, non que la personne se trouvait effectivement là.

Il faut donc lire plusieurs reçus : la partition a été routée ; une station a été atteinte ; un appareil a fourni une position ; le test géométrique a réussi ; le groupe a été rejoint ; l’application a reçu ; le bon destinataire a compris et agi. Aucun reçu n’absorbe les suivants.

Le document n’était pas le déploiement

Les formats S/C/x, le sous-espace multicast et 240.0.0.0 étaient des exemples non enregistrés. RFC 2009 était Experimental. RFC 2026 traite cette catégorie comme recherche et développement, pas comme norme adoptée. Le modèle de groupe de RFC 1112 explique la remise multicast, sans authentifier les membres. RFC 1876 exprime une localisation DNS et sa précision, sans prouver une présence physique.

La section sécurité avertissait déjà que la localisation pouvait limiter l’accès à l’information ou suivre les activités d’un utilisateur. Elle demandait des protections sans fournir un régime complet d’identité, d’autorisation ou d’anti-usurpation.

La lecture de Lu Heng empêche la dernière confusion. Une spécification est un artefact de coordination ; son adoption doit apparaître dans le code en fonctionnement. Un polygone appartient à la représentation, une table et un transfert à l’exécution, un service réussi à l’observation. RFC 2009 n’a pas effacé ces frontières : il les a rendues visibles en remettant la précision au dernier kilomètre.

Sources