Resumen

  • Los estados y, n y m explicaban el tratamiento ordinario de las publicaciones en un grupo, no los derechos personalizados del cliente conectado.
  • y no impedía una denegación individual y n no descartaba una excepción privilegiada; la respuesta real a POST era la prueba operativa.
  • Catálogo, autenticación, autorización local, aceptación del artículo y visibilidad para lectores eran superficies distintas.

Un catálogo no puede prometer en nombre de una cuenta

El lector ve y y el programa habilita el editor. Solo cuando el texto está listo envía POST. El servidor responde 440 antes de pedir el cuerpo. La experiencia parece absurda porque la interfaz convirtió una descripción general en una promesa personal.

La fila decía cómo se trataban normalmente las publicaciones de ese grupo. No había calculado todos los atributos de la cuenta, la dirección de origen, el modo de conexión ni las excepciones locales. El comando posterior sí evaluó el caso presente.

RFC 3977 ofrece también el contraste opuesto: un cliente con privilegios especiales, no definidos por la norma, podría publicar en un grupo marcado n. El estado no deja de ser cierto; su alcance termina antes de las excepciones particulares.

La primera norma ya separaba las dos decisiones

RFC 977, de 1986, definió LIST con nombre de grupo, números alto y bajo de artículos y una bandera y o n. El formato permitía presentar una gran cantidad de grupos en una respuesta compacta.

La misma sección advirtió que un cliente podía tener prohibido publicar aunque el grupo apareciera como permitido. La bandera existía porque algunos grupos eran moderados o digest y seguían un flujo habitual diferente. Esa propiedad era independiente del permiso concedido por el servidor NNTP al cliente.

El permiso individual se manifestaba en POST. 340 invitaba a enviar el artículo; 440 impedía la operación por una razón dependiente de la instalación. La norma no intentó estandarizar todas las políticas de cuentas y hosts. Conservó un punto interoperable donde el resultado podía observarse.

La distinción era práctica, no filosófica. Una tabla por grupo podía mantenerse estable mientras cambiaban usuarios y privilegios. Un control de acceso podía variar sin reescribir el significado del catálogo.

LIST ACTIVE era local y deliberadamente incompleto como autorización

RFC 3977 denominó LIST ACTIVE a la variante. Sin filtro, el servidor incluye los grupos que el cliente puede seleccionar mediante GROUP. La lista ya está situada en un servidor y una conexión; no constituye una autoridad mundial sobre el espacio de nombres de Usenet.

Después de los marcadores numéricos aparece el estado actual en ese servidor. y significa que se permite publicar, n que no se permite y m que las publicaciones se remitirán al moderador. Un valor desconocido no permite inferir nada.

La precisión crucial viene después: el estado solo indica cómo se procesan normalmente las publicaciones y no tiene por qué estar personalizado. Una prohibición del cliente se aplica también a y; un privilegio especial podría superar n.

«Normalmente» convierte la fila en evidencia útil y limitada. Sirve para presentar la ruta por defecto, pero no usurpa la función del sistema de identidad ni de la política de recursos.

Antes y después del cuerpo hay decisiones diferentes

En RFC 3977, POST devuelve 340 o 440 antes del cuerpo. Si recibe el texto completo, termina con 240 o 441. La diferencia tiene consecuencias: una denegación previa evita que el borrador cruce la conexión; un fallo posterior ocurre después de exponerlo al servidor.

Incluso 240 solo indica aceptación, no disponibilidad inmediata. Moderación, procesamiento y transferencia pueden quedar pendientes. El cliente no debe afirmar que otros lectores pueden ver el artículo sin comprobarlo.

Por tanto, una insignia «puedes publicar» mezcla cuatro preguntas: la regla habitual del grupo, el derecho de esta sesión a presentar un texto, la aceptación del texto y su visibilidad. Para investigar fallos o proteger contenido sensible, esas preguntas deben conservar respuestas separadas.

La autenticación no era una autorización universal

RFC 4643 usa 480 cuando el cliente debe autenticarse y/o autorizarse para una orden o recurso. Tras AUTHINFO, el conjunto de capacidades puede cambiar porque la sesión representa a un principal conocido.

Sin embargo, la autenticación correcta puede acabar en 502 para algunos o todos los recursos. La identidad aceptada no crea permisos globales. La política local decide qué puede hacer ese principal.

Esto impide sustituir una prueba por otra. La fila LIST ACTIVE habla del grupo; AUTHINFO habla de identidad; la respuesta al comando habla de autorización vigente. Un caché basado solo en grupo y estado perdería cambios de usuario, TLS, servidor o versión de política.

La m era un itinerario, no una credencial

El estado m indica un envío al moderador, pero no autentica al moderador ni garantiza aprobación. RFC 5537 separa agentes de publicación, inyección, retransmisión, servicio y lectura, además del moderador, porque cada etapa tiene responsabilidades distintas.

La historia ya publicada sobre Approved analiza esa autoridad. Aquí m cumple una función más estrecha: demuestra que la lista describe un procesamiento normal. Poder presentar un artículo no demuestra autoría; aceptar no garantiza retransmisión; retransmitir no garantiza lectura.

El registro mantuvo los verbos separados

El registro IANA de parámetros NNTP registra LIST, POST, AUTHINFO y READER como capacidades distintas. No prueba qué ofrece hoy cada servidor, pero proporciona nombres interoperables para descubrimiento, envío, identidad y lectura.

La economía de un catálogo depende de resumir. Su peligro nace cuando el resumen se convierte en autoridad. La luz verde de NNTP sí decía algo verdadero: describía el carril normal del grupo. Para saber si era tu luz, todavía había que llegar a POST.

Fuentes