Resumen

  • NAMESPACE entregó al cliente la gramática de tres clases de nombres de buzón: personal, otros usuarios y compartida.
  • El descubrimiento del nombre, la existencia, el permiso, la selección, la obtención del contenido, la presentación y la lectura siguieron siendo estados separados.

Una ruta válida podía terminar ante una puerta inexistente

Supongamos que la respuesta anuncia una raíz personal vacía con /, una raíz de otros usuarios ~ con el mismo separador y ningún espacio compartido. El cliente ya sabe construir ~mark/INBOX. La sintaxis es correcta, pero la respuesta no dice que Mark exista ni que el usuario autenticado pueda ver o abrir su INBOX.

Ése fue el alcance de RFC 2342. Antes de NAMESPACE, muchos clientes dependían de que el usuario introdujera manualmente el prefijo personal o compartido. La extensión hizo descubribles las convenciones locales.

La respuesta tiene tres posiciones ordenadas. Cada una puede ser NIL o contener uno o más pares de prefijo y delimitador. Puede haber varias raíces por clase y delimitadores distintos. El servidor también puede exponer sólo una parte de los namespaces que soporta, y la vista puede variar según el usuario.

Por eso NIL tampoco es una declaración universal sobre el servidor. Es la ausencia de esa clase en la respuesta de esta conexión. El mapa describe cómo interpretar nombres disponibles, no todo lo que puede existir detrás del servicio.

No enumerar era parte de la protección

RFC 2342 permite que el cliente añada % al prefijo de otros usuarios y pruebe LIST. Sin embargo, el servidor no debería revelar usuarios que no hayan concedido acceso de listado. Puede devolver sólo nombres autorizados, o responder NO a la consulta amplia y exigir un usuario concreto.

El documento muestra ambas fases: #Users/% falla, mientras #Users/Mike/% devuelve dos buzones. El namespace seguía anunciado durante los dos intentos. Lo que cambió fue la pregunta y la política de exposición.

La distinción protege información real. Una lista de cuentas puede revelar la estructura de una organización y ofrecer un punto de partida para ataques. Publicar la convención de nombres no implica publicar sus ocupantes.

LIST sólo ofrecía una vista parcial

RFC 9051 define LIST como un subconjunto de todos los nombres disponibles para el cliente y permite cero respuestas. Un nombre puede llevar \Noselect o \NonExistent. La vista de suscripciones puede incluir un nombre cuyo buzón ya no existe.

Así se separan al menos cuatro hechos: la rama fue anunciada; un nombre apareció; el objeto existe ahora; la conexión puede seleccionarlo. Una caché que colapsa esas etapas convierte renombres, borrados y cambios de ACL en falsos incidentes de pérdida.

Ver el nombre y leer el contenido exigían derechos distintos

RFC 4314 asigna l a la visibilidad en LIST/LSUB, r a SELECT/STATUS y s a la persistencia de Seen/Unseen. Crear, insertar, borrar, expulsar y administrar ACL tienen derechos propios.

Un buzón puede ser visible sin ser legible. RFC 9051 contempla precisamente que LIST vea un buzón con l, pero STATUS no pueda devolver datos porque falta r; el resultado debe indicar que no es seleccionable. RFC 8440 permite adjuntar MYRIGHTS al LIST extendido, aunque esos derechos siguen describiendo operaciones permitidas, no operaciones realizadas.

SELECT exitoso sí prueba más: esta conexión entró en estado selected y recibió FLAGS, EXISTS, UIDNEXT y UIDVALIDITY. Pero todavía no prueba que FETCH entregara el cuerpo, que el cliente lo interpretara, que la interfaz lo mostrara o que alguien prestara atención.

Tampoco \Seen es un recibo humano. FETCH, STORE, una previsualización o un proceso de sincronización pueden modificarlo. El protocolo guarda estado del mensaje; no observa comprensión.

El valor histórico estaba en no exceder la afirmación

RFC 2342 convirtió una costumbre local en una interfaz interoperable sin convertirla en autoridad sobre las capas posteriores. El prefijo sirve para formular la siguiente operación. Sólo la ejecución de esa operación, bajo el estado y los permisos actuales, produce su propio resultado.

Ésta es una disciplina general de infraestructura: una convención puede hacer que una referencia sea válida sin crear el objeto; una capacidad puede anunciar una orden sin garantizar su éxito; una respuesta de control puede avanzar el diagnóstico sin certificar el resultado final.

NAMESPACE eliminó una pregunta manual. No eliminó la necesidad de probar cada transición.