Resumen

  • RFC 3940 identificaba el objeto que estaba siendo transmitido y reparado dentro del ámbito de un emisor, sin prometer una identidad mundial o permanente.
  • El contador de 16 bits podía volver a usarse; cualquier nombre que debiera persistir tenía que viajar como contexto definido por la aplicación o dentro de los propios datos.

Una multitud silenciosa necesitaba ordenar las reparaciones

Enviar un archivo por multidifusión a miles de destinos parece económico hasta que cada receptor confirma cada paquete. NORM evitó ese diluvio de confirmaciones: quien no perdía datos permanecía callado y quien detectaba un hueco pedía reparación. La corrección de errores hacia delante permitía además que un fragmento de paridad sirviera para reconstruir pérdidas distintas.

Había que mantener una relación inequívoca entre cada segmento, solicitud y objeto activo. RFC 3940, publicado como Experimental en noviembre de 2004, asignó un object_transport_id creciente. El emisor mantenía el mismo valor durante la transmisión y las reparaciones. Unido al identificador de emisor del protocolo, distinguía el NormObject que estaba en tránsito.

La solución respondía a «¿a qué envío pertenece este fragmento?». No respondía a «¿qué obra, versión o registro representa cuando termine el envío?».

El tipo de recipiente no definía la cosa

NORM ofrecía objetos de datos en memoria, objetos de archivo y flujos sin final conocido. La diferencia entre NORM_OBJECT_DATA y NORM_OBJECT_FILE era una pista de almacenamiento para el receptor. Uno sugería memoria; el otro, almacenamiento no volátil. Fuera de esa decisión, ambos eran unidades finitas transportadas de la misma manera. La aplicación incluso podía llevar datos estáticos en un flujo.

Por eso «file» no aportaba ruta, nombre, versión ni categoría documental. El protocolo podía reconstruir todos los bytes de un mapa y seguir ignorando si era el mapa vigente o una copia retirada. La integridad del proceso de reparación no transfería automáticamente procedencia, autorización ni significado.

Un orden local acababa por repetirse

El campo medía 16 bits y cada emisor llevaba su propia cuenta. El número 42 no era una dirección universal. Solo cobraba sentido junto con el emisor, su instancia, la sesión y el estado temporal que el receptor mantenía. En una sesión muy larga o indefinida, RFC 3940 admitía que el valor podía repetirse y confiaba en que los receptores se resincronizaran al observar saltos incompatibles con su estado.

La especificación fue explícita: los encabezados NORM no daban identificación global ni de nivel de aplicación al contenido. El identificador de transporte solo se aplicaba mientras el objeto se enviaba o reparaba. Monotonía significaba orden dentro de un ámbito finito, no singularidad para toda la vida.

RFC 5740 sustituyó a RFC 3940 en noviembre de 2009 y llevó NORM a la vía de estándares. Conservó la frontera y endureció la descripción: en una sesión larga, el campo dará la vuelta y se repetirá. La transición de experimento a estándar no convirtió el contador en clave de archivo.

Una nota lateral podía aportar contexto

NORM_INFO permitía adjuntar a cada objeto información opcional definida por la aplicación. Un tipo MIME era un ejemplo. El receptor podía leer ese contexto para decidir si le interesaba participar en la recepción; si la nota faltaba, podía solicitar su reparación como parte del proceso fiable.

La nota debía caber entera en un solo segmento del emisor. Esa atomicidad aceleraba su recuperación, pero también delimitaba su función. No existía obligación de incluir un identificador permanente, huella, versión o firma. Tampoco había una semántica universal. La aplicación podía usar INFO para nombrar el contenido, o incluir el nombre dentro del contenido, pero tenía que definir y conservar esa relación.

El hecho de que INFO compartiera el identificador con el objeto solo probaba su asociación durante la transferencia. Guardar después únicamente el contador era guardar la ficha de un guardarropa y descartar la fecha, el edificio y la descripción de la prenda. Cuando la ficha reapareciera, el protocolo no estaría duplicando una identidad: el sistema de archivo habría olvidado el ámbito.

Todos los bytes correctos podían caer en el registro equivocado

Pensemos en una caché que usa el identificador de emisor del protocolo y el contador de 16 bits como clave duradera. Pierde su estado de generación, vuelve después de una vuelta del contador y recibe un objeto nuevo. NORM entrega y repara correctamente los fragmentos actuales. Sin embargo, la caché coloca esos bytes bajo los metadatos antiguos: otro título, otra caducidad, quizá otros permisos.

Es una consecuencia analítica del diseño, no la afirmación de un incidente. Sirve para separar pruebas. El estado de transporte indica qué objeto activo recibió un segmento. Una huella aportada por la aplicación puede comparar bytes. Un identificador duradero conecta la transferencia con una versión. La autorización exige su propio registro. Ninguna capa hereda por accidente la autoridad de la siguiente.

La lección histórica de RFC 3940 está en su contención. Definió la identidad mínima necesaria para coordinar una entrega masiva y se negó a fingir que había resuelto la memoria del contenido. El transporte movía; la aplicación recordaba.