Resumen

  • POST tenía una autorización inicial para enviar y un veredicto distinto después de recibir el artículo completo.
  • Una desconexión podía ocultar al cliente un 240 que el servidor ya había emitido, sin deshacer la aceptación.
  • Repetir el mismo Message-ID mantenía dos intentos bajo una sola identidad, aunque no garantizaba visibilidad inmediata ni publicación exactamente una vez.

El silencio llegó cuando ya no quedaba nada por enviar

La avería difícil no ocurre al abrir la sesión. Ocurre después de las cabeceras, el cuerpo y la línea con un solo punto. Si el servidor concluye su procesamiento inmediato y la conexión muere antes del veredicto, el cliente observa el mismo silencio tanto si hubo rechazo como si hubo aceptación.

El siguiente paso tiene dos peligros opuestos. Abandonar puede perder una publicación que nunca entró. Reenviar con una identidad nueva puede duplicar otra que ya avanzó hacia moderación o distribución. La incertidumbre de transporte se convierte en una decisión editorial y operativa.

Desde 1986, POST no era una única respuesta

El RFC 977 asignó a POST dos momentos. Primero, 340 invitaba a enviar el artículo y 440 indicaba que la instalación no permitía publicar. Solo después de recibir el contenido completo llegaban 240 article posted ok o 441 posting failed.

Por eso 340 no transfería custodia. El servidor apenas abría la puerta de presentación. El RFC 3977 preservó la secuencia, prohibió encadenar POST por pipeline y aclaró que la pareja inicial responde al comando, mientras la pareja final responde al artículo enviado.

El 240 debía significar que, salvo errores imprevistos, el artículo se pondría a disposición local o se transferiría según correspondiera, quizá tras más procesamiento. Si el servidor no lo quería, debía usar 441 en lugar de aceptar y descartar en silencio. Era un compromiso de tratamiento, no una fotografía de todos los estados posteriores.

Aceptación y lectura respondían preguntas distintas

El propio RFC 3977 impide dos inferencias. Sin respuesta afirmativa, el cliente no puede suponer que la transferencia salió bien. Con ella, tampoco puede suponer que el artículo ya está disponible para otros clientes sin comprobarlo, por ejemplo mediante STAT.

El RFC 5537 explica la distancia. Un agente de publicación prepara el protoartículo; el agente de inyección lo valida e introduce; un moderador puede recibirlo; agentes de retransmisión lo propagan y un agente de servicio lo ofrece a lectores. Aunque una máquina reúna varias funciones, sus decisiones no son el mismo hecho.

Una consulta vacía puede significar espera de moderación o demora local. No permite reconstruir si la sesión anterior terminó en 240. Usar visibilidad como comprobante instantáneo crea precisamente el duplicado que se intentaba evitar.

La norma prefirió conservar el identificador

RFC 3977 contempla una sesión interrumpida antes de recibir la respuesta: un veredicto positivo pudo enviarse y perderse. En la sesión posterior, el cliente debe comprobar el éxito antes de reenviar o asegurarse de que el servidor asigne el mismo Message-ID al nuevo intento.

La segunda opción es preferible porque el artículo puede no estar disponible todavía, en particular si pasa por moderación. Su apéndice recomienda incluir un campo Message-ID idéntico en cada intento y pide al servidor reconocer esos POST como el mismo artículo.

La clave no demuestra que la primera transacción tuviera éxito. Tampoco autentica al autor. Mantiene constante la pregunta: «¿es este el mismo artículo que quizá aceptaste?». Un Message-ID recién generado preguntaría otra cosa: «¿quieres aceptar además este segundo artículo?».

El historial reconocía sameness, no perfección

El RFC 5536 exige un identificador único y destaca la dependencia de Netnews de comparaciones rápidas. En una red de inundación, explica RFC 5537, varios pares pueden ofrecer el mismo artículo. Los servidores de retransmisión y servicio guardan un historial de identificadores vistos para suprimir duplicados.

Ese historial vuelve útil la identidad estable del reintento. Los dos episodios pueden encontrarse como una sola intención incluso si el primer acuse desapareció. Pero la protección tiene límites: el historial se depura, los sitios aplican políticas distintas y puede haber fallos entre aceptación y persistencia. No existe una promesa de «exactamente una vez».

La diferencia práctica es enorme. Sin una identidad fija, quedan dos artículos parecidos. Con ella, quedan dos intentos reconciliables y una cadena de pruebas separada para recepción del cuerpo, respuesta final, inyección, moderación, retransmisión y lectura.

El registro de parámetros NNTP de IANA conserva POST como capacidad estándar y remite al RFC 3977. El registro no prueba que un servidor permita publicar ni cuánto dure su historial.

NNTP aceptó que un acuse puede desaparecer después del compromiso. Su defensa fue evitar que la recuperación cambiara el nombre del trabajo. Así, una duda sobre el resultado no tenía por qué convertirse en otro artículo con vida propia.

Sources