Résumé

  • RFC 5134 enregistre deux espaces URN, epc et epcglobal, mais n’authentifie aucune marchandise.
  • Un nom epc peut désigner un objet physique ; epcglobal sert à des constructions logiques ou logicielles.
  • La persistance signifie que le nom ne sera pas réattribué, non que l’objet demeure au même endroit ou sous la même garde.
  • Dans l’exemple SGTIN, les zéros initiaux sont significatifs et leur suppression produit un autre identifiant.
  • L’errata vérifié limite la sensibilité à la casse à la partie propre à l’espace de noms.
  • Une chaîne conforme à la syntaxe URN peut rester invalide dans son sous-espace EPC ou non attribuée.
  • Une lecture radio atteste l’observation de bits, pas l’authenticité du support ni la présence de la marchandise nommée.
  • Seuls certains sous-espaces epc disposent d’un chemin historique ONS fondé sur DDDS.
  • epcglobal n’exige aucun mécanisme de résolution ; l’absence de réponse n’invalide donc pas le nom.
  • Une réponse de résolution sélectionne un service, mais ne prouve ni la garde, ni le lieu, ni la véracité des métadonnées.
  • EPCIS porte des déclarations d’événements bornées, pas une connaissance continue et infaillible du monde physique.
  • Les décisions doivent conserver des reçus distincts pour le nom, l’attribution, l’observation, l’authenticité, les métadonnées et l’issue matérielle.

La permanence qui a séduit le comité

Le dossier paraissait exemplaire. Le même URN revenait dans le registre d’attribution, les journaux de lecture, un service de découverte et plusieurs événements de visibilité. Aucun autre identifiant n’avait été émis. Pour le comité, cette continuité lexicale suffisait à établir que la pièce observée au dernier entrepôt était celle qui avait quitté l’usine.

RFC 5134 protège une affirmation beaucoup plus étroite. L’espace de noms organise des identifiants uniques et persistants ; un nom attribué n’est pas censé être recyclé pour une autre ressource. Cette règle stabilise les références lorsque les normes, les organisations ou les services changent. Elle ne suit pas la matière. Entre deux observations, l’objet peut être déplacé, détruit, remplacé ou séparé de son étiquette sans que le nom perde sa permanence.

La distinction est celle d’un registre bien tenu face à un monde physique faillible. Le registre peut avoir raison sur l’identité administrative alors que le lecteur se trompe sur le support. Une étiquette copiée peut présenter les mêmes bits qu’une étiquette légitime. Une chaîne de caractères immuable peut traverser une rupture de garde. La stabilité du nom rend l’enquête possible ; elle n’en fournit pas la conclusion.

Deux espaces, deux objets de preuve

RFC 5134 ne crée pas un seul grand récipient appelé EPC. Il enregistre epc et epcglobal. Les sous-espaces d’epc peuvent nommer des objets corporels. Les sous-espaces d’epcglobal nomment notamment des schémas et d’autres constructions logiques ou logicielles. Cette séparation empêche de transformer le mot « identité » en promesse uniforme.

Un nom de schéma peut rester valable sans document à télécharger. L’enregistrement epcglobal précise qu’aucun mécanisme de résolution n’est requis ni fourni. Un contrôle qui tente de déréférencer chaque URN comme une URL invente donc des pannes. L’absence de serveur n’est pas un défaut lorsqu’aucun serveur ne fait partie du contrat.

À l’inverse, le fait d’obtenir une page ou un document pour un identifiant d’objet ne matérialise pas l’objet. Le réseau a seulement conduit le client vers un service. La réponse peut être ancienne, mal signée, fournie par une délégation compromise ou exacte pour le numéro mais sans rapport avec le support actuellement lu. La disponibilité d’un service est un reçu technique, pas un certificat de possession.

La forme exacte fait partie de l’identité

L’exemple SGTIN de RFC 5134 décompose le nom en préfixe d’entreprise, référence de produit et numéro de série. Il avertit que les zéros initiaux des composants complétés sont significatifs. Une couche d’intégration qui convertit chaque segment en entier ne simplifie donc pas la présentation : elle substitue un nom à un autre.

Le premier contrôle doit être une acquisition sans perte. Il faut conserver la représentation reçue, l’octet ou le message d’origine lorsque c’est possible, la version du parseur, le sous-espace appliqué et le résultat produit. Un aller-retour doit reproduire la même identité. Une fonction de normalisation ne mérite le nom de canonicalisation que si elle applique les règles du namespace et non les préférences d’une base de données.

La casse exige la même précision. Le texte publié comportait une formulation trop large, ensuite corrigée par les errata vérifiés 1325 et 1328 : c’est la partie spécifique à l’espace de noms qui est sensible à la casse. Le schéma urn et l’identifiant d’espace suivent les règles générales de comparaison des URN. Mettre toute la chaîne en minuscules peut fusionner des noms différents ; traiter URN:EPC et urn:epc comme différents uniquement à cause de cette graphie peut créer de faux doublons.

Syntaxe, sous-espace et attribution

Un parseur URI peut confirmer qu’une chaîne respecte l’enveloppe générale. Cela ne suffit pas à établir qu’elle respecte la grammaire de son sous-espace EPC. RFC 5134 présente des exemples, mais renvoie les détails normatifs au Tag Data Standard maintenu par GS1. L’archive de ce standard rappelle aussi que les règles évoluent : un verdict doit citer la version utilisée.

Même une forme conforme peut contenir un préfixe ou une série qui n’a pas été attribué par l’autorité compétente. Et une attribution régulière peut être portée par une copie. Trois contrôles sont donc nécessaires : validation de la syntaxe, validation selon la version du sous-espace, puis preuve d’attribution. Aucun ne remplace l’authentification du tag ou l’inspection de l’objet.

Cette granularité évite le voyant vert « EPC valide », dont personne ne sait s’il veut dire caractères acceptés, composition reconnue, allocation retrouvée, tag authentique ou produit présent. Chaque statut doit dire exactement quelle proposition a été vérifiée et avec quelle preuve.

Une lecture est une observation, pas un titre de propriété

Un lecteur RFID produit une observation précieuse : à une heure donnée, avec un micrologiciel, une antenne, une zone d’interrogation et des filtres donnés, il a reçu une réponse contenant un identifiant. Le reçu doit garder ces paramètres ainsi que les temps de capture et d’ingestion. Il ne doit pas acquérir après coup une capacité d’authentification que l’interface radio n’avait pas.

Si la même valeur apparaît simultanément à deux portes incompatibles, l’unicité du namespace ne résout pas le conflit. Il peut s’agir d’une copie, d’un périmètre radio mal défini, d’un message retardé, d’une horloge fausse ou d’un mouvement légitime mal reconstitué. Le numéro ne choisit pas l’explication. Il permet seulement de réunir les observations à examiner.

La propriété et la garde sont encore d’autres affirmations. Une réception peut transférer une responsabilité contractuelle sans déplacer immédiatement le bien ; un mouvement physique peut avoir lieu avant l’enregistrement du transfert. Confondre le scan avec le titre de propriété donne à l’opérateur du lecteur un pouvoir juridique et économique que le protocole ne lui accorde pas.

ONS découvre un service, pas le réel

Pour certains sous-espaces epc, RFC 5134 décrit le recours à l’Object Naming Service, construit comme une application du Dynamic Delegation Discovery System. Les règles DDDS et les enregistrements NAPTR transforment une entrée en candidats de service. Ils organisent la découverte ; ils ne vérifient pas l’objet.

Un reçu de résolution sérieux retient l’entrée exacte, sa forme d’équivalence, le service demandé, la chaîne de délégation, le résultat choisi, les protections de transport ou DNSSEC pertinentes, l’autorité de la réponse et sa fraîcheur. Il peut ensuite dire : « cette règle a conduit ce client à ce service à cet instant ». Dire « le produit est authentique » ajouterait une conclusion extérieure au mécanisme.

Il faut aussi distinguer les échecs. Une absence de service, une délégation incomplète, une validation cryptographique ratée, un délai dépassé et une requête mal formée ne sont pas le même état. Pour epcglobal, aucune résolution n’étant requise, le simple échec de déréférencement ne constitue même pas un signal de validité.

Les métadonnées ont leur propre chaîne de confiance

La section sécurité de RFC 5134 anticipe l’incitation à falsifier des métadonnées associées à des objets de valeur, par exemple leur prix ou leurs dimensions. Elle présente signatures numériques, mécanismes de résolution sûrs et relations de confiance comme des éléments fondamentaux. C’est un avertissement contre la déduction « le résolveur a répondu, donc la fiche est vraie ».

Il faut demander qui a signé, quelle représentation de l’identifiant est couverte, à quelle période, pour quel champ et selon quelle politique de confiance. Une signature de classe de produit ne prouve pas nécessairement l’instance. Une fiche intègre peut être périmée. Un service légitime peut être atteint par une délégation falsifiée. La vérification doit conserver le signataire, l’algorithme, l’ancre, l’heure et la décision du client.

Même parfaite, l’intégrité des métadonnées n’authentifie pas le support. Une description signée peut dire exactement ce que désigne le numéro tandis qu’un contrefacteur a copié ce numéro sur un autre objet. La signature lie une déclaration à une autorité ; une autre preuve doit lier le tag au produit présent.

EPCIS raconte des événements bornés

L’architecture GS1 actuelle maintient une séparation féconde : l’EPC identifie le sujet, tandis qu’EPCIS échange des données d’événement sur ce qui s’est passé, où, quand, pourquoi et comment. Un événement est une déclaration faite par une source dans un contexte. Ce n’est pas une caméra omnisciente entre deux horodatages.

Chaque événement utile devrait garder le temps de l’événement et celui de la capture, le point de lecture, le lieu métier, l’étape, la disposition, le système source et la partie responsable. Les corrections, doublons et arrivées tardives doivent rester auditables. Un champ de localisation est une affirmation produite par ce dispositif ; il n’est pas le lieu lui-même.

Une chaîne de garde crédible se construit à partir de ces événements, de reçus de transfert et de contrôles physiques. Les intervalles sans observation restent des intervalles inconnus. La persistance du nom ne permet pas de remplir les blancs, et une succession de lignes cohérentes ne garantit pas que le même support physique les a toutes provoquées.

Une échelle de reçus, pas un badge

L’organisation peut représenter dix reçus séparés : enregistrement du namespace, syntaxe, fidélité lexicale, attribution, observation, authenticité du support, découverte du service, intégrité des métadonnées, événement métier et constat physique. Chaque niveau apporte une proposition limitée et une autorité identifiable.

Cette structure accepte les combinaisons réelles. Un nom peut être correctement attribué sans résolveur. Un service peut répondre avec une fiche périmée. Une fiche signée peut décrire un tag copié. Un tag authentique peut voyager dans un intervalle sans événements. Un historique complet jusqu’au quai peut précéder un échec de livraison.

Le système devient plus honnête lorsqu’il affiche le dernier reçu disponible et les trous restants. Il devient aussi plus contestable : le fournisseur peut réfuter une observation sans réécrire le registre, et l’opérateur de résolution peut être remplacé sans renommer le produit.

Sources