Resumen

  • RFC 5256 hace reproducible el orden y el agrupamiento, pero cada resultado depende del ámbito de búsqueda, algoritmo, colación, calidad de cabeceras y estado actual del buzón.
  • Una rama puede nacer de una referencia declarada, un ancestro ficticio creado por ausencia o una unión por asunto; ninguna prueba por sí sola intención, ascendencia completa, custodia o entrega.

Una figura limpia sustituyó una pregunta incómoda

En la revisión de una operación, el árbol mostraba una orden y varias respuestas. Nadie preguntó qué mensajes habían quedado fuera de la búsqueda. El filtro empezaba dos días después de abrirse el asunto. La interfaz no mentía: agrupó correctamente lo que recibió. La interpretación sí añadió una totalidad que el comando nunca prometió.

THREAD empieza como una búsqueda. Solo después aplica el algoritmo solicitado a los mensajes que coinciden. Cambiar el rango temporal, una palabra, el buzón o su estado puede cambiar la familia visible sin alterar el contenido de ningún mensaje. El resultado dice cómo una regla organiza un conjunto en ese instante; no reconstruye por sí mismo toda la conversación.

Conviene separar el registro, la transformación y la presentación. Los mensajes y metadatos del servidor son el registro. La búsqueda, decodificación, normalización, colación y construcción del árbol son transformación. La sangría, los conectores y la etiqueta «conversación» son presentación. Una pantalla puede reunirlos, pero no debe convertir la comodidad visual en mandato probatorio.

La autoridad está repartida

El cliente elige los criterios, el juego de caracteres y el algoritmo. El servidor observa una versión del buzón, interpreta las cabeceras y devuelve números de secuencia o UID. El software emisor creó Message-ID, References e In-Reply-To. La aplicación decide cómo dibujar el resultado.

Todos pueden cumplir el estándar y aun así inducir una lectura falsa. Un campo References: inventado producirá una rama si el servidor lo procesa correctamente. Un padre ausente puede haber quedado fuera del filtro, no haber llegado jamás o haber sido eliminado. La línea dibujada no autentica el relato de la cabecera; el hueco tampoco explica su propia causa.

La cuestión de agencia es quién escogió cada etapa y quién asume el daño cuando la vista se eleva a historia oficial. El operador de la interfaz no debería certificar por sí solo la intención de quienes escribieron los mensajes.

ORDEREDSUBJECT agrupa, no reconstruye respuestas

RFC 5256 llama a ORDEREDSUBJECT «poor man's threading». Extrae un asunto base con un procedimiento obligatorio, agrupa los mensajes cuyo resultado coincide y los ordena por fecha de envío. El primero es raíz y todos los posteriores son hijos directos, hermanos entre sí. No existen nietos.

La planitud es una característica. El algoritmo ofrece una clasificación por asunto cuando faltan referencias, no una genealogía. Dos intercambios independientes con el mismo asunto pueden terminar juntos. Una conversación real puede dividirse si alguien modifica el asunto.

El asunto base también es una derivación. Se decodifican palabras, se comprimen espacios y se retiran ciertos prefijos de respuesta, envolturas de reenvío, colas y bloques. El mismo proceso se exige conectado y desconectado para evitar resultados distintos. Eso demuestra consistencia mecánica. El propio RFC avisa que un texto significativo puede confundirse con un artefacto y generar una colación incorrecta.

REFERENCES administra pruebas incompletas

REFERENCES toma los Message-ID de References y, bajo reglas definidas, el primer identificador válido de In-Reply-To. Normaliza escrituras equivalentes y evita enlaces que creen ciclos.

Cuando un mensaje carece de Message-ID válido, el algoritmo le asigna uno único. Si varios mensajes repiten el mismo valor, solo el primero según el menor número de secuencia lo conserva; los demás reciben identificadores inventados. Si se cita un ancestro que no aparece en el conjunto, se crea un mensaje ficticio para representarlo.

Después llega la poda. Un ficticio sin hijos se elimina. Otro con hijos puede desaparecer mientras esos hijos suben de nivel. A veces se mantiene un ficticio estructural cerca de la raíz. Los conflictos causados por listas truncadas se resuelven conservando o rompiendo enlaces según reglas explícitas.

Es una reparación determinista, no una excavación del pasado. El nodo ficticio no es un correo recuperado. La promoción no prueba que no existió intermediario. El identificador creado no autentica una identidad. Solo deja constancia de cómo el algoritmo volvió utilizable una entrada incompleta.

El asunto todavía puede unir raíces

Después de construir relaciones con identificadores, REFERENCES compara los asuntos base de los hilos situados en la raíz. Si coinciden, puede fusionarlos, privilegiar un mensaje no marcado como respuesta o crear un nuevo padre ficticio.

Por ello, dos conectores idénticos en la pantalla pueden provenir de mecanismos distintos: referencia directa, cadena inferida o unión por asunto. Sin procedencia por arista, el auditor no sabe si contempla una afirmación de cabecera o una decisión de presentación.

RFC 5256 reconoce expresamente que datos falsos en References: pueden incorporar un hilo dentro de otro. Normalizar un Message-ID corrige diferencias de escritura; no autentica a quien aportó el campo ni convierte la relación declarada en hecho.

La fecha visible puede venir de relojes distintos

SORT busca primero y aplica después criterios en el orden indicado. Si todos los criterios explícitos empatan, el número de secuencia del buzón actúa como clave implícita. Por eso REVERSE SUBJECT no es exactamente la inversión de SUBJECT: el desempate implícito no se invierte.

DATE empieza con la cabecera Date: ajustada a UTC. Zonas, horas o fechas inválidas reciben sustituciones definidas. Si no hay fecha de envío interpretable, se usa INTERNALDATE. Una columna puede mezclar tiempo declarado por el autor, valores corregidos y metadatos retenidos por el servidor.

RFC 5957 añade orden por nombres de presentación. Usa el nombre completo decodificado cuando existe y recurre al buzón y host cuando falta, pero no intenta adivinar un apellido dependiente del idioma. La prudencia es correcta: un orden debe exponer su clave, no hacerse pasar por una jerarquía humana universal.

Una vista actualizable no es un libro de custodia

Los UID ofrecen mejor identidad que los números de secuencia, pero deben conservarse con el buzón y UIDVALIDITY. RFC 5267 mantiene búsquedas y órdenes cuando cambia el buzón; RFC 5182 permite reutilizar resultados guardados. Ambas capacidades mejoran el protocolo sin crear un registro inmutable.

Si una decisión depende de la ascendencia, hay que retener el estado del buzón, búsqueda y charset, algoritmo, colación, capacidades y revisión del servidor, UIDVALIDITY y UID, cabeceras originales, Message-ID normalizados, regla de cada arista, nodos ficticios, promociones, fusiones por asunto, desempates, hash del resultado y versión de renderizado.

«La vista RFC 5256 colocó B debajo de A en esta captura» es verificable. «B fue escrito como respuesta a A» exige evidencia adicional. «El receptor leyó y aceptó A» pertenece a otra cadena de prueba.

Fuentes