Resumen

  • Supersedes señala un único artículo anterior mediante su Message-ID; la corrección conserva una identidad distinta y se procesa como un artículo ordinario.
  • Retirar el predecesor equivale a tramitar un cancel: cada servidor comprueba autoridad y actúa sobre su copia. Dos servidores pueden aceptar la revisión y conservar historias diferentes.
  • Cancel-Lock y Cancel-Key mejoraron la autenticación del retiro, pero no ofrecieron borrado universal de archivos, pasarelas o citas.

La revisión llegó; el pasado no convergió

Dos servidores reciben el mismo artículo corregido. El primero valida la solicitud asociada y deja de servir la versión antigua. El segundo no puede verificarla, o decide no ejecutarla, y muestra ambos textos. La revisión está disponible en los dos; únicamente cambia el destino local del predecesor.

Esta escena revela por qué «sustituido» es una palabra peligrosa si no lleva alcance. Puede describir una relación entre versiones, una preferencia de interfaz o la retirada efectiva de una copia concreta. No demuestra que el artículo antiguo haya desaparecido de toda la red.

El protocolo permitió que la verdad corregida avanzara sin convertir la limpieza total del pasado en requisito previo.

Cancel nació como una operación del custodio

En la RFC 1036, un mensaje de control cancel identifica el objetivo por Message-ID. El sistema que recibe la petición actúa sobre la copia que conserva. La autoridad es local porque el almacenamiento también lo es.

La norma temprana intentaba autorizar comparando Sender o From de la petición y del artículo, además de reconocer a los administradores del sitio. Era una barrera débil: reproducir un encabezado parecido no equivalía a demostrar control sobre la publicación original.

La dificultad tenía dos caras. Si la comprobación era demasiado estricta, una corrección legítima no retiraba nada. Si era demasiado laxa, un tercero podía hacer desaparecer textos ajenos en cada servidor que confiara. Ninguna solución podía tratar la red como un único disco.

Supersedes no editaba el artículo anterior

La RFC 5536 define el campo Netnews Supersedes con exactamente un Message-ID. Explica su efecto como la tramitación de un cancel dirigido al predecesor, seguida inmediatamente del tratamiento normal del nuevo artículo una vez eliminado el campo.

Por tanto, la revisión no ocupa la identidad del original ni modifica su cuerpo en el mismo registro. Tiene otro Message-ID, otros encabezados y su propio recorrido. El campo enlaza dos publicaciones independientes y pide una acción sobre una de ellas.

También separa el éxito de ambas fases. La imposibilidad de retirar el original no bloquea la admisión de la corrección. Esa decisión hace que el sistema sea menos limpio, pero mucho más resistente a la falta de consenso entre custodios.

Cada sitio resolvía la autorización

La RFC 5537 aclara que Supersedes no es un mensaje de control, aunque la retirada que solicita debe autenticarse y autorizarse como un cancel. Si el sitio la acepta, aplica la misma acción local.

La nueva publicación, en cambio, se maneja normalmente tanto si el retiro se honra como si no. Aceptar el artículo nuevo no certifica que el viejo haya sido borrado; mantener el viejo tampoco invalida la corrección.

La experiencia histórica reforzó esa cautela. Muchos sitios ignoraron cancel y supersede porque autenticar era difícil y el abuso ofrecía una forma sencilla de silenciar contenido. El agente de publicación debería impedir que un usuario trate de sustituir el artículo de otra persona, pero los nodos posteriores conservan su propio juicio.

Una llave podía probar, no mandar

La RFC 8315 añadió Cancel-Lock y Cancel-Key. El artículo original publica un valor de bloqueo; una cancelación o revisión posterior aporta una clave de la que se deriva un valor comparable. Así, el servidor puede comprobar conocimiento ligado a la publicación inicial en vez de fiarse sólo de una dirección.

La mejora reduce la suplantación, pero no cambia la topología del poder. Una coincidencia no obliga a un archivo independiente, no recupera una copia exportada por una pasarela y no elimina citas. Ni siquiera obliga a un sitio que, aun autenticando, tenga una política distinta.

Conviene distinguir siempre «petición autenticada» de «copia retirada aquí» y de «ausencia comprobada en todas partes». Sólo la primera es consecuencia directa de la prueba.

El correo utilizó el mismo nombre con otra definición

La RFC 2156, sobre la correspondencia entre Internet Mail y X.400, contiene un Supersedes capaz de enumerar varios identificadores. La RFC 5536 advierte que el campo Netnews de un solo objetivo no está relacionado con él.

El registro IANA de campos de mensajes mantiene inscripciones separadas para mail y netnews. Compartir una etiqueta no crea una función de recuperación común entre buzones, servidores de noticias y archivos.

La inscripción normaliza el nombre y la referencia. No dice qué proveedores lo implementan hoy ni acredita el destino de cada copia.

Corregir fue añadir un hecho, no reescribir todos los anteriores

El precio de la separación es una historia desigual. Un lector ve sólo la revisión; otro encuentra ambas versiones; un archivo conserva un ejemplar que el servidor habitual ya no presenta. Describir esa desigualdad es más honesto que declarar un borrado sin evidencia.

Supersedes convirtió la corrección en una publicación nueva que podía viajar por derecho propio. El retiro fue una petición delimitada que cada custodio debía evaluar. La revisión no necesitaba poseer todo el pasado para mejorarlo: bastaba con llegar y declarar con precisión qué artículo pretendía reemplazar.