Resumen

  • IHAVE ofrecía primero un Message-ID. El receptor podía declarar que ya conocía el artículo, pedir que se reintentara más tarde o solicitar el cuerpo completo.
  • La solicitud del cuerpo era un permiso para continuar, no el veredicto. Tras examinar el artículo, el servidor aún podía aceptarlo, diferirlo o rechazarlo por política, formato o recursos.
  • CHECK y TAKETHIS hicieron posible una alimentación continua con la misma separación conceptual. La mejora de rendimiento no convirtió al remitente en dueño del almacenamiento ajeno.

El equívoco de «envíalo»

Un servidor anuncia tres Message-IDs. El vecino reconoce el primero y contesta que no lo necesita. Para el segundo pide tiempo: quizá su disco o su historial no estén disponibles. Para el tercero responde que envíen el artículo. Solo el tercer cuerpo atraviesa el enlace.

Después aparece información que el identificador no contenía. El artículo apunta a grupos que el receptor no sirve, lleva una distribución excluida o presenta cabeceras dañadas. El mismo servidor que pidió los bytes los rechaza. No se retractó de una aceptación: completó una decisión que no podía tomar con el identificador solo.

Esta escena obliga a nombrar los estados. Hay una oferta de identidad, una invitación a transmitir y un resultado tras la inspección. Si se resumen como un único «aceptado», se pierde tanto la economía del protocolo como su reparto de autoridad.

Antes de IHAVE, una lista de lo que había y faltaba

RFC 1036 conserva el antecedente de IHAVE: los mensajes de control ihave y sendme. Un sistema anunciaba los Message-IDs de artículos disponibles y el otro solicitaba los que no tenía. Las listas podían agruparse, porque ofrecer por separado un identificador podía costar tanto como un artículo pequeño.

Era una solución nacida del almacenamiento y reenvío. Los enlaces no tenían capacidad infinita ni estaban siempre activos. El receptor ya poseía un conocimiento valioso: su historial de identificadores. Consultarlo antes de transferir un cuerpo evitaba duplicados sin exigir que ambos sitios compartieran una base central.

Pero el historial solo respondía si el nombre ya se había visto. No decía si el cuerpo cumpliría las reglas locales. Por eso la negociación basada en identidad nunca pudo sustituir la inspección del objeto.

Dos respuestas para dos preguntas

RFC 977 formalizó la secuencia. El cliente envía IHAVE con un Message-ID. 335 significa que debe transmitir el artículo; 435, que el servidor no lo quiere; 436, que conviene volver a intentarlo más adelante.

Cuando llega el cuerpo, comienza otro conjunto de resultados. 235 señala que la transferencia terminó con éxito. 436 mantiene la posibilidad de reintento. 437 rechaza el artículo sin pedir una nueva entrega. La especificación menciona, entre las razones posibles, grupos o distribución no deseados, falta de espacio, longitud excesiva y cabeceras defectuosas.

El primer 335 responde «necesito ver el objeto». El segundo código responde «esto ocurrió cuando lo vi». Ninguno debería registrarse en lugar del otro. Juntos cuentan por qué se gastó ancho de banda y qué hizo el receptor después.

No responder tampoco era aceptar

RFC 3977 actualizó NNTP sin borrar esta frontera. IHAVE no admite encadenar comandos sin esperar: el cliente aguarda la respuesta a la oferta, envía el cuerpo solo si se solicita y aguarda el resultado final. Si falta una respuesta, debe tratar el caso como fallo temporal.

Esa regla impide una peligrosa inferencia por silencio. Un corte de conexión después de transmitir el cuerpo no demuestra que el vecino lo almacenó. El emisor conserva una razón para reintentar, y el receptor necesita reconocer repeticiones para evitar copias innecesarias.

La norma distingue además IHAVE, destinado al tránsito de un artículo ya formado, de POST, destinado a introducir uno nuevo. El receptor de tránsito juzga el objeto dentro de una relación entre pares; no certifica para toda la red su origen ni su destino final.

El 235 cerraba la transacción, no la historia

Incluso la respuesta positiva tiene un límite. RFC 977 advierte que el servidor puede descubrir después un problema y descartar el artículo silenciosamente pese a haber respondido 235. La confirmación demuestra que la conversación NNTP alcanzó su final positivo, no que exista una copia permanente.

La misma cautela reaparece en RFC 4644. En una alimentación continua, 239 confirma TAKETHIS, pero un procesamiento posterior todavía puede eliminar el artículo. Para probar custodia hacen falta observaciones posteriores: presencia en el almacén, disponibilidad para lectores u oferta a otro vecino.

De ahí surge una jerarquía de evidencia. Bytes enviados es menos que transferencia confirmada. Transferencia confirmada es menos que retención. Retención es menos que propagación completa. El protocolo solo habla con autoridad sobre la frontera que define.

CHECK y TAKETHIS abrieron varios carriles

El problema de IHAVE era el tiempo de espera en enlaces con mucha latencia. Cada artículo requería una respuesta antes de su cuerpo. RFC 4644 separó la alimentación continua en CHECK, que consulta el interés por un Message-ID, y TAKETHIS, que entrega el artículo y obtiene el veredicto.

Varias consultas y entregas podían quedar en curso, aprovechando mejor el enlace. Sin embargo, la contestación a CHECK era orientativa. El receptor no podía confiar en que el cliente la obedeciera siempre. Una política bilateral o una estrategia adaptativa incluso podía permitir TAKETHIS sin CHECK previo.

La arquitectura ganó concurrencia, no obediencia. El servidor seguía evaluando cada cuerpo. El remitente seguía sin adquirir derecho a ocupar el disco del vecino.

La relación de alimentación no cabía en un código

RFC 5537 explica que los antiguos controles ihave y sendme habían quedado casi obsoletos en Internet, aunque sobrevivían en ciertos usos de UUCP. Los intercambios modernos dependían de acuerdos entre sitios: qué material enviar, qué transporte usar y qué políticas aplicar.

Un Message-ID no contiene ese acuerdo. Tampoco un 335 concede autoridad general al remitente. Los códigos documentan una interacción dentro de una relación operativa que los sitios establecieron fuera de la gramática del comando.

La lección de IHAVE no es que el protocolo dudara demasiado. Es que convirtió la duda necesaria en estados verificables. Preguntar antes de gastar ancho de banda, examinar antes de aceptar y observar antes de afirmar custodia son tres hábitos distintos. NNTP les dio tres lugares distintos.

Fuentes