Resumen

  • NNTP separó el Message-ID globalmente único de la clave local formada por grupo de noticias y número de artículo. Un artículo cruzado podía tener varios números sin multiplicarse.
  • Xref reunía las ubicaciones asignadas por el último servidor, lo que permitía al lector evitar el procesamiento repetido del mismo artículo cruzado.
  • El servidor de lectura normalmente eliminaba el Xref recibido y escribía el suyo. Cambiaba el recibo de archivo local, no el cuerpo ni la identidad global del artículo.

La segunda aparición

Una persona lee un artículo en un grupo de noticias. Al entrar después en otro grupo suscrito, vuelve a encontrar el mismo título y el mismo cuerpo, pero con otro número. Si el programa solo recuerda el primer número, puede presentar la segunda coordenada como si fuera un segundo artículo.

Netnews tenía una explicación más precisa: el autor había publicado un solo artículo de forma cruzada en varios grupos. El servidor solía conservar una única copia y crear una entrada de índice en cada grupo. Cada entrada ocupaba su propia posición.

Xref era el recibo compacto de ese archivado. Indicaba qué servidor lo había generado y enumeraba los grupos y localizadores donde ese servidor había colocado el artículo. No añadía otra identidad; reunía varios puntos de acceso locales alrededor de una obra.

La distinción sostiene todo el mecanismo. Identidad responde «qué artículo es». Ubicación responde «dónde lo ofrece este servidor». Si una aplicación intercambia esas preguntas, produce duplicados o promete una dirección universal que el protocolo nunca ofreció.

Tres claves con alcances distintos

El RFC 3977 describe tres tipos de clave para almacenar y recuperar artículos por NNTP. El Message-ID identifica globalmente el artículo. Otra clave combina un nombre de grupo con un número dentro del grupo. La tercera registra la hora de llegada al servidor.

La pareja grupo-número es inequívoca dentro de su ámbito: en un grupo de un servidor, un número solo puede señalar un artículo, y ese artículo no puede tener dos números en el mismo grupo. Sin embargo, un artículo cruzado pertenece a varios grupos y puede recibir un número distinto en cada uno.

Fuera de ese servidor, la pareja deja de ser única. El mismo nombre de grupo y el mismo número pueden designar artículos diferentes en servidores distintos. Los números se asignan según el orden local de llegada. Migrar de servidor implica cambiar de sistema de coordenadas aunque se mantenga el Message-ID.

La respuesta a GROUP comunica marcas de agua inferior y superior y una cantidad estimada. No garantiza que todos los números intermedios existan. Los artículos pueden retirarse y, bajo condiciones definidas, un artículo anterior puede reaparecer con su número previo. Un hueco no es una prueba de borrado mundial ni un número alto una cronología global.

Un artículo en varios estantes

El RFC 5536 distingue publicar un artículo en varios grupos de publicar varias veces el mismo texto como artículos separados. En el primer caso, el servidor suele guardar una sola copia, identificada por un Message-ID, y construir varios accesos de grupo.

Xref expresa ese abanico. Empieza por la identidad del servidor generador y continúa con una o más ubicaciones. Cada ubicación asocia un grupo con un localizador. En NNTP el formato tradicional es un número decimal, aunque la especificación admite localizadores dependientes de la implementación.

El nombre del servidor acota la interpretación. Sin ese dato, una posición aparentemente igual puede conducir a otro artículo en otro servicio. Con él, el cliente sabe que varias posiciones pertenecen al mismo mapa local.

RFC 5536 señala que los agentes de usuario suelen usar el campo para evitar tratar varias veces un artículo cruzado. Tras mostrarlo en un grupo, el lector puede alinear el estado de las demás posiciones conectadas. Así conserva la semántica del cruce: una intervención dirigida a varios públicos sigue siendo una sola intervención.

Declarar grupos no equivale a archivarlos

Newsgroups declara los grupos a los que se publicó el artículo. Xref cuenta dónde lo archivó realmente el último servidor. El RFC permite que esas listas no coincidan.

La diferencia hace visible el control local. Un servidor puede no transportar todos los grupos, aplicar reglas de admisión o alterar con el tiempo lo que ofrece por retención y moderación. Si copiara sin más la declaración del autor, ocultaría sus propias decisiones de archivo.

Por ello, un campo conserva la intención de distribución y el otro la vista de almacenamiento. La ubicación local no reescribe la declaración del autor; la declaración tampoco demuestra que cada servidor haya aceptado ese destino.

Un recibo que debía poder sustituirse

El RFC 1036, de 1987, describía Xref como el nombre de un host seguido de pares grupo-número obtenidos del directorio de cola local. Afirmaba que la información solo tenía valor para el sistema local y no debía transmitirse. Su ejemplo mostraba un mensaje con números distintos en dos grupos del mismo host.

La arquitectura posterior organizó el reemplazo del campo sin convertirlo en identidad. El RFC 5537 permite que un agente de retransmisión borre un Xref presente y añada otro para su uso. Un agente de servicio normalmente debe retirar el recibido —salvo una configuración especial que conserve los localizadores del remitente— y puede, como suele ocurrir, añadir el suyo antes de guardar.

El cambio no modifica el artículo. El mismo RFC prohíbe a esos agentes alterar sus partes salvo las excepciones estrechas de Path y Xref, y les prohíbe tocar el cuerpo. El mapa local puede cambiar mientras la obra permanece intacta.

La regla revela de quién es el dato: el recibo describe la decisión de archivo del servidor, no una afirmación permanente del autor.

Ámbito no es autenticación

El servidor nombrado en el campo no funciona como sello de procedencia. Su misión es indicar en qué espacio deben leerse los localizadores. No es una firma criptográfica, no comprueba al autor y no demuestra cuál fue el primer servidor de la ruta.

Que los agentes puedan retirar y regenerar Xref impide tratarlo como historial inmutable. La conclusión de que no autentica es una inferencia prudente basada en las reglas de reescritura y en la ausencia de un contrato de autenticación. El campo aporta evidencia de una vista local solo dentro del contexto de confianza de ese servicio.

El actual registro de cabeceras de IANA mantiene Xref como campo estándar de Netnews con referencia al RFC 5536. Message-ID y Newsgroups figuran por separado. El registro estabiliza el vocabulario, no concentra identidad, distribución declarada y ubicación en una sola autoridad.

El número significaba «aquí»

El mérito de Xref no fue crear un identificador más fuerte. Fue permitir que un sistema distribuido reconociera varias coordenadas para un solo artículo y aceptara que el siguiente servidor las sustituyera sin sustituir el artículo.

Si ubicación equivale a identidad, cada cruce o migración fabrica duplicados. Si identidad equivale a ubicación, un nombre global parece prometer una dirección universal. NNTP mantuvo ambas capas y limitó sus poderes.

Las fuentes oficiales no prueban la implantación actual del campo ni el comportamiento de un proveedor. Tampoco explican por sí solas la desaparición de un número local. Sí fijan la frontera: Message-ID dice qué artículo es; Xref dice dónde lo archivó este servidor. Su precisión proviene de no decir más.