Resumen

  • RFC 1312 definió un servicio experimental de mensajes cortos por TCP y UDP con campos para destinatario, terminal, emisor, cookie y firma, pero esos campos no demostraban por sí mismos quién estaba presente.
  • En TCP, el carácter + indicaba entrega exitosa a algún usuario o terminal; el propio RFC advierte que puede significar solo la invocación de un servicio local de entrega.
  • El protocolo no fija si el acuse ocurre con la entrega local, el despliegue en una ventana o la confirmación de lectura; una señal positiva no es un recibo humano de lectura.

Análisis

El destino podía ser una decisión local

El mensaje de RFC 1312 lleva una revisión y campos separados por nulos. Entre ellos están RECIPIENT y RECIP-TERM. Parecen precisar a quién se escribe, pero el texto deja abierta una parte esencial. Si falta el destinatario, la entrega puede ir a cualquier usuario del sistema. Si falta el terminal, el sistema elige el “correcto”, decisión dependiente de ese sistema. Un asterisco puede implicar todos los terminales. Si faltan los dos, el destino debería ser una consola, definida como el lugar donde probablemente lo vea un operador o administrador.

Nada de ello es un defecto de sintaxis. Es una descripción franca de un servicio que trabaja con elecciones locales. La solicitud puede contener una preferencia útil sin identificar una presencia. El servidor puede escoger una pantalla según información que el cliente no observa. Una consola puede ser una función administrativa y no una persona. De un campo dirigido no se sigue que una persona concreta recibió, vio o comprendió el mensaje.

La precisión tiene una consecuencia práctica: hay que conservar la diferencia entre instrucciones para una máquina y hechos sobre una persona. El protocolo puede registrar un nombre de usuario, un terminal o una consola; esas piezas permiten intentar la entrega. No prueban quién estaba al otro lado ni qué ocurrió después del intento.

El signo positivo tenía un alcance limitado

En la variante TCP, tras establecerse la conexión y enviarse el mensaje, el servidor contesta con + o , seguido opcionalmente de una explicación. El positivo significa que el mensaje fue entregado con éxito a algún usuario o terminal; el negativo, que no se entregó a ningún terminal. Ésta ya es una distinción útil para el componente que la emite.

Pero RFC 1312 no deja que el cliente convierta ese resultado en una historia completa. Declara que el acuse positivo puede indicar únicamente que el servidor de Message Send logró invocar un servicio local de entrega. Puede no ser posible inferir semántica verdadera de extremo a extremo. El RFC enumera los puntos que no resuelve: la llamada al servicio local, la exhibición a través de un sistema de ventanas y la confirmación de que un usuario lo leyó, por ejemplo al cerrar una ventana emergente. No prescribe cuál de ellos activa el acuse.

Por eso el + no certifica pantalla, atención ni lectura. Tampoco confirma que el destinatario seleccionado por el sistema coincidiera con una expectativa del emisor. El acuse prueba la etapa declarada por el servidor. Toda afirmación posterior necesita una observación posterior de la capa que realmente la puede conocer.

UDP ofrecía otra clase de silencio

La alternativa UDP puede devolver un datagrama de respuesta. Debe enviar un acuse positivo cuando el mensaje se dirige a un usuario particular y se entrega con éxito a ese usuario. Para mensajes sin usuario concreto, o para fallos, no se envía respuesta. La razón no es que ambos casos sean idénticos: el RFC quería evitar una avalancha de respuestas cuando un mensaje se difundía.

De ahí que el silencio no pueda traducirse automáticamente como fracaso. La política de respuesta limita qué puede inferirse de la ausencia de un datagrama. El COOKIE, junto con el puerto UDP del emisor, ayuda al servidor a identificar duplicados. Un cliente puede repetir un mensaje para aumentar sus probabilidades de recepción y el servidor puede descartar las repeticiones. Esta ayuda de deduplicación no vuelve a la primera copia una entrega comprobada, ni convierte el reintento en atención humana.

La firma y el texto muestran otros límites

El campo SIGNATURE tampoco cierra la brecha de identidad. Si está vacío, la identidad del emisor no puede verificarse. Si contiene algo, RFC 1312 solo lo trata como una codificación textual de un token de seguridad; no define la codificación ni su interpretación. Al mismo tiempo exige filtrar texto que se vaya a mostrar, pues escribir sobre un terminal sin permiso o aceptar secuencias de control puede abrir riesgos distintos.

Un nombre de emisor, una dirección de origen, una firma textual, una llamada a un servicio local y una lectura son hechos de órdenes diferentes. El protocolo no los confunde. Una operación cuidadosa tampoco debería hacerlo.

Una evidencia pequeña evita una conclusión falsa

RFC 1312 no describe mensajería actual ni garantiza cómo se comporta un producto posterior. Conserva, en cambio, una buena regla histórica: nombrar exactamente la etapa que un acuse observa. Un servicio local invocado es un hecho. Un mensaje mostrado, advertido, leído o aceptado es otro hecho, posiblemente de otra máquina o de una persona.

Reducir todos a “entregado” ofrece una tranquilidad falsa. Conservarlos separados permite que la respuesta positiva siga siendo útil sin pedirle que pruebe lo que no midió.

Fuentes

RFC 1312 es una especificación experimental de 1992; no prueba un destinatario real, una pantalla, una lectura, consentimiento, identidad, despliegue ni resultado.