Resumen

  • RFC 5134 registró los espacios URN epc y epcglobal; no creó una autoridad universal sobre productos.
  • epc puede nombrar objetos físicos, mientras epcglobal nombra construcciones lógicas o de software.
  • Una consulta ONS basada en DDDS selecciona servicios para ciertos subespacios, no inspecciona el objeto.
  • epcglobal no requiere ni proporciona un mecanismo de resolución.
  • Un resultado de red correcto no garantiza que los metadatos sean autorizados, íntegros, actuales o aplicables a esa instancia.
  • La seguridad de RFC 5134 advierte expresamente del incentivo para falsificar metadatos de objetos valiosos.
  • La persistencia impide reasignar el nombre, pero no prueba ubicación, custodia, propiedad ni existencia actual.
  • Los ceros iniciales del ejemplo SGTIN son significativos; eliminarlos cambia la identidad.
  • Los errata verificados aclaran que la parte específica del namespace es sensible a mayúsculas y minúsculas.
  • La sintaxis URN, la validez del subespacio y la asignación autorizada son controles diferentes.
  • EPCIS registra afirmaciones sobre eventos; un evento no es el mundo físico ni una observación continua.
  • La decisión operativa debe declarar qué comprobante acepta y qué inferencias todavía no puede hacer.

La pantalla verde contenía cuatro preguntas ocultas

La primera pregunta era de descubrimiento: ¿qué servicio seleccionaron las reglas para el nombre consultado? La segunda era de transporte: ¿llegó el cliente al destino previsto sin que se sustituyera la respuesta? La tercera era de autoridad: ¿quién emitió y protegió los metadatos? La cuarta era material: ¿el objeto que activó el lector era realmente la instancia nombrada? La interfaz comprimió las cuatro en un solo color.

RFC 5134 no autoriza esa compresión. Registra nombres persistentes y describe cómo algunos subespacios de epc pueden utilizar Object Naming Service. ONS es una aplicación de Dynamic Delegation Discovery System: aplica reglas y registros NAPTR para encontrar servicios. Es una arquitectura de selección. No contiene un sensor capaz de mirar el palé, autenticar el chip o decidir quién posee la mercancía.

La respuesta en 34 milisegundos fue, como máximo, un recibo de que aquel cliente, con aquella entrada y aquella cadena de delegación, obtuvo un resultado. El valor operativo del recibo es real. El error comienza cuando se le añaden afirmaciones sobre autenticidad y presencia que ningún componente del recorrido observó.

Dos namespaces evitan una falsa equivalencia

El RFC registra epc y epcglobal por separado. Los subespacios del primero pueden identificar objetos físicos o entidades corpóreas. El segundo se ocupa de objetos lógicos y de software, entre ellos namespaces de esquemas. La separación enseña una regla básica: no todos los nombres tienen el mismo tipo de referente ni la misma expectativa de resolución.

Para epcglobal, el registro dice que no se requiere ni se proporciona resolución. Intentar abrir cada URN como si fuera una URL produce una alarma falsa: un nombre de esquema puede ser válido y estable sin servidor asociado. Por tanto, la ausencia de respuesta no equivale a invalidez.

El inverso también importa. Que un nombre físico sí conduzca a un servicio no hace presente al objeto. Una etiqueta copiada puede generar la misma consulta que la auténtica. Un caché puede ofrecer datos antiguos. Una delegación legítima puede apuntar a un servicio comprometido. La resolución aumenta la superficie de información y también la superficie que debe probarse.

La entrada exacta forma parte del recibo

Un investigador no puede evaluar una resolución si el sistema sólo conserva la URL resultante. Hace falta la cadena exacta de entrada, el subespacio reconocido, las reglas de equivalencia aplicadas, el servicio solicitado, la secuencia de reglas DDDS, los registros NAPTR recibidos, el objetivo elegido, el estado de validación y la edad de los datos. Sin ello, el icono verde no es reproducible.

La exigencia empieza antes de DNS. En el ejemplo SGTIN de RFC 5134, el prefijo de empresa, la referencia de producto y el número de serie se representan en componentes delimitados. Los ceros iniciales de los campos rellenados son significativos. Un middleware que convierte esos componentes a enteros puede consultar de manera impecable el servicio correspondiente a otro nombre.

La regla de mayúsculas y minúsculas también exige cuidado. Los errata verificados 1325 y 1328 corrigen la afirmación original demasiado amplia: la parte específica del namespace es sensible a la caja; el esquema y el identificador del namespace obedecen las reglas generales de comparación URN. Pasar la cadena completa a minúsculas puede fusionar nombres. Comparar el esquema por bytes puede fabricar duplicados. La operación debe citar la regla, no una convención genérica de cadenas.

Un nombre válido pasa por tres puertas

La primera puerta es la sintaxis general URI/URN. La segunda es la gramática y la versión del subespacio EPC. RFC 5134 declara no normativo su ejemplo ABNF de SGTIN y remite al Tag Data Standard para las definiciones normativas. La tercera es la asignación: que la autoridad competente haya entregado ese prefijo, referencia o serie según la cadena prevista.

Superar una puerta no abre las siguientes. Una cadena puede tener caracteres válidos y una composición EPC imposible. Puede tener buena composición y no haber sido asignada. Puede estar correctamente asignada y haber sido copiada a otro soporte. Registrar sólo valid=true borra precisamente el lugar donde una investigación necesita mirar.

La versión normativa es un dato del veredicto. El archivo de GS1 muestra la evolución del Tag Data Standard. Una representación puede haber sido válida con las reglas de su fecha de comisión y no ajustarse a una interpretación posterior, o al revés. La validación debe preservar ambas preguntas sin reescribir el pasado.

Los metadatos no heredan la verdad del DNS

RFC 5134 explica por qué la seguridad no es un añadido decorativo. Los nombres EPC pueden referirse a bienes valiosos, de modo que existe un incentivo para falsificar información como coste o tamaño. El texto considera fundamentales las firmas digitales, la resolución segura y las relaciones de confianza.

Una respuesta útil debe indicar quién firmó cada afirmación, qué campos cubrió, a qué identidad exacta se vinculó, cuándo era válida y qué ancla aceptó el cliente. También debe distinguir una afirmación sobre una clase de producto de una afirmación sobre una unidad serializada. Una ficha auténtica de la clase no autentica la instancia que emitió la señal.

Ni siquiera una firma perfecta alcanza el mundo físico por sí sola. Puede proteger una descripción verdadera del número y, al mismo tiempo, el número puede estar impreso en una etiqueta clonada. Para vincular soporte y objeto hacen falta controles adicionales: capacidades criptográficas del tag, información de fabricación protegida, comisión controlada, evidencia antimanipulación o inspección adecuada al riesgo.

La lectura RFID es un testimonio acotado

Un lector observa una respuesta bajo condiciones concretas. El recibo debería incluir identidad del lector, versión del firmware, zona de antena, filtros, potencia, hora de captura, hora de ingestión y reglas de supresión de duplicados. Esa precisión no debilita el dato; permite usarlo sin otorgarle poderes inexistentes.

Si el mismo EPC aparece en dos muelles incompatibles, el namespace sigue siendo único. La inconsistencia pertenece a las observaciones. Puede revelar clonación, solapamiento de zonas, retraso en la cola, error de codificación o movimiento legítimo con relojes desalineados. El sistema debe abrir esas hipótesis y conservar los mensajes brutos, no elegir una porque el registro mantenga un solo nombre.

Del mismo modo, una lectura no es un título de propiedad. Custodia, propiedad, riesgo contractual y ubicación pueden cambiar en momentos distintos. Automatizar un pago o una liberación aduanera a partir de un scan exige una política explícita sobre qué otros comprobantes deben acompañarlo.

EPCIS preserva el verbo

La arquitectura GS1 distingue el identificador de los eventos de visibilidad. EPCIS expresa qué ocurrió, dónde, cuándo, por qué y cómo según una fuente. Esa estructura conserva el verbo: «la organización X afirmó haber observado o ejecutado Y». No convierte la fila en una fotografía continua de la mercancía.

Un evento sólido retiene hora del hecho y de captura, punto de lectura, ubicación comercial, paso de negocio, disposición, fuente y actor responsable. Las correcciones, llegadas tardías y duplicados deben dejar rastro. Una ubicación almacenada es una afirmación de un proceso; puede ser correcta, incorrecta o demasiado amplia.

La cadena de custodia surge de eventos acotados más recibos de entrega y controles de identidad. Los huecos no se rellenan porque el mismo serial aparezca antes y después. Un buen sistema puede decir «no observado durante este intervalo» sin destruir el valor de las observaciones vecinas.

Diez recibos en lugar de una conclusión mágica

La evidencia puede ordenarse sin mezclarla: registro del namespace; sintaxis; fidelidad de ceros y caja; asignación; lectura; autenticidad del soporte; resolución; integridad y vigencia de metadatos; evento de negocio; comprobación física. Cada recibo tiene productor, tiempo, alcance y condición de fallo.

Así aparecen estados que el badge ocultaba. Hay nombres válidos sin servicio. Servicios disponibles con datos caducados. Datos firmados para valores copiados. Tags genuinos con eventos incompletos. Historiales convincentes que terminan antes de la entrega. La aplicación puede decidir con políticas distintas según se trate de inventario, pago, retirada o seguridad, pero no debe fingir que las pruebas son intercambiables.

La claridad mejora incluso la disponibilidad. Un fallo de ONS puede degradar sólo la capa de descubrimiento mientras se preservan observación y asignación. Un incidente de metadatos puede suspender una decisión sin invalidar el nombre persistente. La arquitectura deja de convertir una dependencia en juez universal del sistema.

Fuentes