Resumen

  • En el modelo de presencia que Jonathan Rosenberg ayudó a definir, OPEN significa que el buzón de mensajería asociado está listo para aceptar un mensaje. No certifica dónde está la persona, si presta atención, si desea conversar o si responderá.
  • PIDF admite varios tuples y hasta estados OPEN y CLOSED para un mismo contacto. RFC 4479 separa persona, servicio y dispositivo para impedir que una propiedad de uno se atribuya automáticamente a otro.
  • La automatización responsable enlaza recibos distintos: autorización del observador, origen y vigencia del estado, actividad del dispositivo, aceptación y entrega del mensaje, visualización y respuesta. Ningún punto verde debe saltarse esos límites.

La asignación que llegó al buzón correcto y a la conclusión equivocada

Imaginemos un sistema de guardias. A las 08:03 consulta la presencia de tres especialistas. Dos aparecen CLOSED; el tercero, OPEN. La tarea se asigna al tercero y el servicio confirma que recibió el mensaje. Media hora después no hay respuesta. El informe etiqueta el caso como “retraso del agente disponible”.

La etiqueta contiene una afirmación que ninguna de las señales produjo. El servicio podía recibir. Eso no demuestra que la persona estuviera frente al dispositivo, que la notificación se mostrara, que el canal fuera el adecuado ni que existiera voluntad de actuar.

La arquitectura de presencia permite tomar mejores decisiones antes de contactar. Su valor desaparece cuando la aproximación se reescribe como hecho humano.

El modelo original no llamó disponible a la persona

RFC 2778, de Mark Day, Jonathan Rosenberg e Hiroyasu Sugano, es un documento Informativo. Define un modelo y un vocabulario común; no pretende ser por sí mismo un protocolo interoperable. Dentro de ese modelo hay un presentity que aporta información, un servicio de presencia que la almacena y distribuye, un watcher que la recibe, un servicio de mensajería y un instant inbox.

Para mensajería instantánea, OPEN describe un instant inbox listo para aceptar un mensaje. CLOSED describe uno que no lo está. El texto permite que otros medios de comunicación adopten un significado análogo, pero no lo especifica.

Ese alcance no incluye a la persona como sensor. Estar listo para aceptar no equivale a haber entregado; haber entregado no equivale a haber mostrado; haber mostrado no equivale a haber leído. Mucho menos equivale a comprometer una respuesta.

También queda fuera la identidad material del ser humano. El modelo reconoce principals —personas, grupos o software en el mundo real—, pero no resuelve cómo se proyecta ese mundo sobre las entidades del sistema. El identificador operativo coordina; no sustituye una prueba de identidad.

Un documento PIDF puede contar varias historias a la vez

RFC 3863 define el formato PIDF. Una presencia contiene cero o más tuples; cada uno lleva un status y puede añadir contacto, tiempo, notas y extensiones. El elemento básico toma open o closed.

Los tuples sirven para segmentar fuentes distintas: dispositivos diferentes, aplicaciones diferentes dentro del mismo dispositivo o datos generados en momentos diferentes. La especificación permite incluso que dos tuples con el mismo contacto discrepen, uno OPEN y otro CLOSED.

La discrepancia no se arregla eligiendo la fila que mejor conviene a la interfaz. Hace falta una regla del watcher: correlacionar identificadores, comparar marcas de tiempo, conocer la fuente y decidir qué componente describe cada dato. Esa regla es una decisión de producto y debe quedar registrada.

El id del tuple es una cadena arbitraria útil para reconocer la misma ocurrencia entre documentos. No identifica por sí mismo a un usuario o dispositivo, ni garantiza que dos productores hablen de la misma realidad. Convertirlo en una clave humana duradera ampliaría su semántica sin respaldo.

Guardar únicamente el estado agregado impide investigar. Conviene conservar el documento recibido o, como mínimo, presentity, suscripción, secuencia, tuple, contacto, fuente, estado, tiempo publicado, tiempo recibido y versión de la política de composición.

La autorización protege al observador, no interpreta a la persona

RFC 3856, cuyo autor es Rosenberg, usa SIP para suscribirse a la presencia y recibir notificaciones. El presence agent debe autenticar todas las solicitudes de suscripción y, después, decidir si el observador está autorizado. La autorización puede ser exitosa, rechazada o quedar pendiente.

Es fácil confundir cuatro resultados: identidad del watcher, permiso para ver, vigencia de la suscripción y contenido de presencia. Son planos separados. Una respuesta a SUBSCRIBE no dice que la persona esté disponible. Un NOTIFY prueba el transporte de un estado al watcher, no que ese estado sea una observación humana directa.

La selección de información puede variar por privacidad. Si un watcher deja de recibir actividad de dispositivo, quizá perdió ese permiso mientras conserva acceso al estado básico. Si la interfaz transforma el campo ausente en “inactivo”, castiga una decisión de confidencialidad. Si la suscripción termina y el panel dice “usuario desconectado”, confunde el fin de la mirada con el estado de lo observado.

Persona, servicio y dispositivo son tipos diferentes

RFC 4479, escrito por Jonathan Rosenberg, organiza la presencia en tres componentes. La persona representa estados del usuario; el servicio, un punto de comunicación por el cual se le puede alcanzar; el dispositivo, el entorno físico donde esos servicios se ejecutan o se manifiestan.

La regla fundamental asigna el atributo al objeto descrito, no al objeto que lo comunica. Si un teléfono informa “en reunión”, el atributo describe a la persona. Si informa nivel de batería, describe al dispositivo. Si un URI puede aceptar mensajes, describe un servicio.

Esta disciplina bloquea inferencias tentadoras. Un teléfono encendido no asegura que funcione la mensajería. Un servicio abierto no asegura que el usuario quiera hablar. La ubicación del terminal y la ubicación de la persona pueden ser diferentes. Incluso la entidad llamada persona es una fachada: el sistema no puede verificar que detrás haya un solo ser humano; una mesa de ayuda colectiva puede modelarse como una persona.

Por tanto, el agregado no debería borrar el tipo. La pantalla puede mostrar una visión conjunta, pero los datos deben seguir diciendo “servicio abierto”, “dispositivo activo” o “persona declaró estar en reunión”. Solo así una contradicción conduce al propietario adecuado.

La actividad reciente solo cambia la probabilidad

RFC 4480, de Henning Schulzrinne, Vijay Gurbani, Paul Kyzivat y Rosenberg, añade presencia enriquecida. user-input registra actividad o inactividad según un umbral configurable. La fuente puede observar una sola aplicación o varias; el tiempo exacto de última entrada puede omitirse.

El propio estándar explica que un tuple puede seguir OPEN aunque no se use desde hace tiempo. El watcher puede preferir un contacto abierto con actividad más reciente. Es una combinación razonable para estimar la probabilidad de respuesta, no para demostrarla.

La entrada reciente podría pertenecer a otra aplicación. Un proceso podría generar actividad. Una lectura pasiva quizá no deje el evento esperado. Diferentes productos aplican umbrales diferentes. Un “activo hace cinco minutos” necesita su ámbito y su reloj; sin ellos parece más preciso de lo que es.

La interfaz puede enseñar ambos datos sin adjudicar intención: “acepta mensajes” y “actividad observada recientemente”. El usuario decide. La automatización de alto impacto necesita evidencia posterior.

La contribución documentada tampoco debe agrandarse

El perfil público de Rosenberg en el IETF registraba 72 RFC y ninguna función activa el 9 de septiembre de 2026. RFC 3856 y RFC 4479 lo nombran como autor único; RFC 2778 y RFC 4480 tienen varios autores. Esta distinción reconoce su aportación sin atribuirle en solitario el consenso del IETF o cada implementación.

La página oficial de autores de Five9 ofrece la fotografía pública empleada como referencia de identidad. No se usa su biografía antigua para declarar un cargo actual. Procedencia de imagen y vigencia laboral son pruebas diferentes.

Del indicador al resultado hay una cadena

Antes de afirmar que alguien estaba disponible, el registro debería distinguir: quién obtuvo permiso para observar; qué notificación recibió; qué tuple y componente cambió; qué servicio aceptaba mensajes; qué actividad y umbral se observaron; si el mensaje fue aceptado, entregado y mostrado; y si una persona lo leyó o respondió.

No disponer de todas las etapas es normal. El estado correcto puede ser “desconocido”. Una frase como “servicio OPEN, entrega confirmada, lectura no observada” conserva capacidad de decisión. “Persona disponible que no respondió” transforma un vacío en acusación.

El estándar no obliga a retirar el punto verde. Obliga, si se lee con cuidado, a preguntar de qué objeto es ese color.

Fuentes