Resumen

  • RFC 1861 no usó «entregado» como una conclusión única: distinguió la orden aceptada, el mensaje en cola, la llegada a la unidad, la lectura, la respuesta y el cierre.
  • El remitente podía pedir una confirmación de lectura sin exigir respuesta, rechazar la espera con NOQUEUE y consultar una secuencia de estados mediante Message_Tag, Pass_Code y MSTAtus.
  • La precisión no convertía el documento en autoridad universal: era Informational, dejaba decisiones al operador, no analizaba la seguridad y conservaba el desacuerdo sobre crear SNPP o aprovechar el correo existente.

Una cola podía ocultar un fracaso

Imaginemos una avería nocturna. El centro de operaciones envía una página al técnico de guardia. La unidad está fuera de cobertura, pero la pasarela acepta el mensaje y lo guarda. En el panel aparece una señal positiva. Veinte minutos después, cuando el aparato vuelve a estar disponible, la radio entrega una alerta que ya no puede evitar la caída.

¿Falló el sistema? Depende del hecho que se hubiera prometido. La pasarela sí conservó el mensaje. La red sí lo entregó más tarde. La intervención, sin embargo, no ocurrió a tiempo. Si el panel redujo toda la cadena a «enviado», ocultó la diferencia decisiva antes de que el operador pudiera escoger otro canal.

El RFC 1861 expuso ese problema mediante códigos distintos. En modo bidireccional, PAGEr podía responder 850 cuando la unidad estaba en línea y la transacción quedaba aceptada. 950 indicaba que estaba desconectada y el mensaje se pondría en cola. 750 rechazaba la transacción cuando no se admitía la espera. Los tres resultados pertenecían al mismo punto de la conversación, pero no tenían el mismo significado operativo.

Antes incluso de esa selección, un 250 solo confirmaba que el servidor había procesado una orden. Aceptar un identificador, un texto o una opción era una prueba sobre la pasarela. No era evidencia de una transmisión por radio ni de atención humana. El protocolo resultaba fiable porque hacía visibles sus fronteras, no porque fingiera observarlo todo.

De una vía de salida a una conversación diferida

SNPP había empezado como un puente sencillo hacia la infraestructura de radiomensajería. El RFC 1568, de enero de 1994, describía una primera versión. El RFC 1645, publicado en julio de ese año, lo sustituyó con la versión 2. RFC 1861 apareció en octubre de 1995, declaró obsoleta aquella versión y añadió extensiones de nivel 3 para aparatos bidireccionales.

Una pasarela SNPP podía ocultar a los clientes de Internet la complejidad de los terminales TAP/IXO. En el modelo unidireccional, el cliente elegía un destinatario, proporcionaba el mensaje y lanzaba el envío. La posibilidad de que la unidad devolviera una confirmación o una respuesta cambió la duración del proceso.

El documento observaba que la entrega técnica podía ser relativamente previsible, mientras que nadie sabía cuándo el abonado sacaría físicamente el aparato, leería la pantalla y contestaría. Mantener una llamada telefónica abierta durante esa espera sería costoso. La solución no consistía en obligar a la persona a seguir el ritmo de la máquina, sino en permitir que la transacción persistiera después de terminar la conexión.

Por eso el nivel 3 se orientaba a una sola unidad. 2WAY abría una transacción con sus propias opciones de lectura y respuesta. SEND lanzaba el mensaje y cerraba aquella fase. Después, el cliente podía consultar MSTAtus tantas veces como hiciera falta. La continuidad residía en un registro identificable, no en la ilusión de una sesión instantánea.

Los códigos decían cuánto faltaba

RFC 1861 agrupó los resultados por grado de cierre. La familia 86x significaba que el mensaje inicial había sido entregado pero faltaba una acción solicitada. La 87x indicaba un avance intermedio pendiente de cierre. La 88x era final. La 96x identificaba una transacción en cola.

El primer resultado de SEND podía ser 860: entregado, a la espera de confirmación de lectura. 861 decía que estaba entregado pero faltaba una respuesta. 880 cerraba una entrega sin respuesta pendiente. 960 admitía que el mensaje seguía en espera de entrega.

Las consultas posteriores añadían hechos. 870 significaba que el mensaje ya había sido leído pero aún no contestado. 881 cerraba la combinación entregado y leído. 888 llevaba una respuesta de opciones predefinidas; 889, texto libre. 780 decía lo que muchos cuadros de mando prefieren omitir: el mensaje venció antes de ser entregado.

Según el RFC, después de un código 88x no habría nuevos cambios de estado. Esa regla daba un límite verificable a la transacción. Cualquier código anterior mantenía una pregunta abierta. Si una aplicación mostraba 860 y 881 con la misma palabra, destruía información que la red había trabajado para conservar.

La lectura no exigía una contestación

ACKRead 1 pedía a la unidad que informara cuándo el abonado veía realmente el mensaje recibido. El texto añadía una precisión esencial: esa función era independiente de la respuesta.

La separación reflejaba la realidad humana. Un aparato podía recibir mientras permanecía en un bolsillo. El abonado podía leer durante una emergencia y no disponer de una respuesta adecuada. También podía necesitar consultar a otra persona antes de comprometerse. El silencio posterior a la lectura era un estado, no una prueba automática de rechazo o aceptación.

El remitente podía definir la forma de respuesta mediante RTYPe: ninguna, sí/no, un repertorio sencillo del proveedor, opciones múltiples preparadas para ese mensaje o texto libre. MCResponse cargaba las alternativas. La red podía demostrar que uno de esos códigos había regresado. No podía demostrar que el destinatario hubiera comprendido una cláusula, que actuara sin presión o que tuviera mandato para obligar a una organización.

Este límite no reduce el valor del comprobante. Lo hace utilizable. Permite saber que existe una respuesta sin convertir el canal de vuelta en una firma, una elección o una delegación que el protocolo nunca definió.

NOQUEUE devolvía la decisión al remitente

La orden NOQUEUE, emitida antes de PAGEr, prohibía que la pasarela guardara el mensaje para más tarde. Si la unidad no estaba en línea, el cliente recibía un rechazo de la familia 750. Esa negativa podía parecer un peor indicador, pero conservaba la capacidad de actuar: el remitente sabía que debía llamar, enviar otra página o escalar el incidente.

Sin esa opción, la pasarela decidía implícitamente que una entrega tardía seguía siendo útil. Con ella, la urgencia volvía a quien conocía el contexto. El servidor no tenía que interpretar la importancia del mensaje; solo debía respetar si la espera estaba autorizada.

EXPTag ofrecía otro límite, el vencimiento de un mensaje en cola. Si no llegaba dentro del plazo, se eliminaba y su estado registraba la imposibilidad de entrega. El RFC aclaraba que la duración de los identificadores y parte de la política de expiración dependían del proveedor. Había interoperabilidad en el gesto, no uniformidad total en la operación.

Al final, KTAG permitía eliminar el identificador de seguimiento cuando ya no se esperaban respuestas. Mantener registros consume recursos y acumula datos sensibles. Borrarlos demasiado pronto impide investigar. El comando no resolvía esa política, pero hacía visible que recordar y olvidar también son decisiones del sistema.

El expediente cambiaba con una secuencia

Tras un SEND bidireccional correcto, el servidor devolvía un Message_Tag y un Pass_Code. El RFC describía el primero como localizador del expediente y el segundo como un PIN aleatorio para autorizar las consultas. Juntos permitían usar MSTAtus.

El registro contenía un número de secuencia que aumentaba al cambiar el estado, además de fecha y hora. Así, el cliente podía distinguir una lectura nueva de la repetición de una entrega ya conocida. La secuencia aportaba orden al relato, aunque el RFC no afirmaba que proporcionara un historial inmutable ni una sincronización perfecta entre todos los componentes.

Tampoco justificaba tratar el PIN como seguridad suficiente. La sección de seguridad afirma que esas cuestiones no se discuten. No hay análisis de adivinación, confidencialidad, autenticación fuerte, control de acceso o protección del archivo. Un diseño que registra el momento de lectura, la ubicación y la respuesta requiere precisamente esas preguntas, pero la fuente no las contesta.

La honestidad editorial exige conservar esa ausencia. Añadir hoy una seguridad imaginaria al protocolo sería tan engañoso como llamar «leído» a un mensaje apenas aceptado.

Localizar sin revelar la posición

PING permitía averiguar la localización o el estado de una unidad. El documento reconocía que esos datos eran sensibles y ofrecía una respuesta genérica elegida por el abonado: la unidad estaba en el sistema, pero no había información de ubicación disponible. A este ajuste lo llamaba modo ACLU.

La decisión separaba dos capacidades que suelen mezclarse. Un servicio podía saber que el terminal era localizable sin entregar su posición a quien preguntaba. La negativa a revelar no borraba la evidencia de presencia.

Sin embargo, el RFC no explicaba cómo autenticar la preferencia, proteger la base de localizaciones o resolver excepciones. El código 821 limitaba la respuesta en esa interfaz. No convertía a SNPP en una política integral de privacidad. El control seguía repartido entre abonado, proveedor, implementación y las reglas aplicables.

Un RFC conservó dos estrategias rivales

La publicación no borró el desacuerdo técnico. El autor relató que integrantes del IESG y el grupo «822 Extensions» preferían usar la infraestructura de correo ya desplegada. Un nuevo protocolo imponía costes; SMTP era una base ampliamente distribuida. Algunos revisores creían que la configuración podía conseguir el requisito de entregar de inmediato o fallar. Otros aceptaban funciones especiales, pero como extensiones de SMTP.

El autor defendía que SNPP aislaba los detalles de TAP/IXO y sus sucesores, y que las pasarelas desde correo podían construirse sin obligar a cada usuario a conocer aquella maquinaria. La discusión era sobre ubicación del control y coste de adopción, no sobre una supuesta oposición entre la red y el correo.

La ficha del RFC Editor clasifica RFC 1861 como Informational. El número hace permanente el documento; no certifica despliegue universal ni concede al IETF el poder de decidir qué arquitectura adoptó cada operador.

El registro valía por lo que no pretendía

Cada testigo veía una parte. La pasarela procesaba órdenes. El sistema de paging administraba cola y transmisión. La unidad podía observar recepción y apertura. El canal inverso recogía una opción o texto. El cliente reunía esos hechos y decidía si el estado solicitado estaba cerrado.

El protocolo no necesitaba una entidad central que fingiera haberlo visto todo. Su coordinación era útil porque mantenía la procedencia de cada comprobante. Incluso cuando la pantalla humana nunca se encendía, el registro podía seguir siendo exacto: el mensaje estaba en cola, o había llegado al aparato, o había vencido.

La pregunta que deja RFC 1861 no es si deberíamos recuperar los buscapersonas. Es si nuestros sistemas actuales son igual de honestos acerca de sus verbos. ¿Entregado a qué superficie? ¿Leído por qué observador? ¿Respondido por quién y con qué autoridad? ¿Cuándo deja de cambiar el expediente? Un registro gana legitimidad cuando responde de forma estrecha. La pierde cuando su propietario convierte una etapa técnica en una verdad sobre la persona.

Fuentes