Resumen

  • PARTSTAT=ACCEPTED registra el estado de participación comunicado para una dirección de calendario, no la presencia posterior de una persona.
  • Respuesta, representación, revisión, recurrencia, entrega y observación del evento necesitan registros separados.

La escena es banal: comienza una reunión, queda una silla vacía y en la lista del organizador esa persona aparece como “aceptada”. Culpar al calendario sería injusto. El sistema conserva una decisión de coordinación tomada antes del evento. La silla aporta una observación posterior. El error nace cuando una base de datos decide que ambas cosas significan lo mismo.

La RFC 5545 llama PARTSTAT al estado de participación de un usuario de calendario. Para eventos, contempla NEEDS-ACTION, ACCEPTED, DECLINED, TENTATIVE y DELEGATED. Es un vocabulario preciso para gestionar invitaciones. No contiene un sensor de puerta, una lectura de pantalla ni una constatación de atención.

Por qué Cyrus Daboo es la clave de lectura

Cyrus Daboo aparece en las normas que enlazan las piezas sin confundirlas. Es coautor de CalDAV, RFC 4791, autor de iTIP, RFC 5546 y coautor de las extensiones de planificación de CalDAV, RFC 6638. Su ficha del IETF enumera 26 RFC en la instantánea consultada. El reconocimiento de CalConnect de 2013 documenta su trabajo histórico en interoperabilidad de calendarios.

La RFC 5546 divide la autoridad. El organizador controla el objeto maestro. Al crear la invitación suele marcar al asistente como NEEDS-ACTION. El asistente cambia el PARTSTAT de su propia propiedad ATTENDEE dentro de un REPLY, y el organizador incorpora la respuesta. El STATUS del evento completo y el PARTSTAT de cada asistente son estados distintos.

Por eso, ACCEPTED en la copia del organizador permite una afirmación limitada: esa copia contiene una respuesta aceptada para una dirección concreta. No identifica necesariamente a quien pulsó el botón ni relata qué pasó después.

La dirección, el remitente y quien acude

iTIP admite que esas tres figuras diverjan. Una persona invitada puede delegar la participación en otro usuario de calendario. SENT-BY permite indicar que alguien respondió en nombre del asistente o del organizador especificado. También puede intervenir un asistente administrativo, un buzón compartido o una automatización autorizada.

Eliminar esos datos y conservar solo “aceptó” empobrece la prueba. La dirección que recibió la invitación no es necesariamente la identidad del operador del cliente, y ninguna de las dos garantiza la identidad de quien entra a la reunión.

Aceptar una versión no es aceptar todas

La reunión puede cambiar. La RFC 5546 reserva SEQUENCE para las revisiones del organizador y establece que un REPLY no incrementa ese número. La secuencia del mensaje indica a qué revisión contestó el asistente. Una aceptación previa a un cambio de día, hora, lugar o propósito no debería presentarse como respuesta a la versión final.

Las recurrencias exigen aún más cuidado. Una aceptación general de la serie puede coexistir con una excepción identificada por RECURRENCE-ID: una sesión declinada, movida o eliminada. Expandir el valor general sobre todas las fechas inventa observaciones que no existen.

Un servidor procesa mensajes, no presencia

La RFC 6638 define la planificación implícita de CalDAV. Guardar, modificar o borrar un objeto puede hacer que el servidor envíe mensajes de planificación. Los mensajes entrantes pueden procesarse automáticamente, y el REPLY de un asistente puede actualizar su PARTSTAT en el recurso del organizador. SCHEDULE-STATUS informa del resultado de entrega o procesamiento.

Es evidencia operativa valiosa. Sirve para investigar por qué no llegó una invitación o qué componente incorporó una respuesta. Pero el agente de planificación puede ser SERVER, CLIENT o NONE. Que el servidor haya hecho su trabajo no demuestra que el humano hiciera nada, ni siquiera que viera el mensaje.

Un registro de evidencia para después de la reunión

Hay contextos donde constatar la asistencia es necesario: un quórum, una capacitación acreditada, el acceso físico o un servicio facturado. En ellos debe definirse otra fuente. Una marca de entrada puede prestarse; una conexión puede quedar abierta; una lista manual puede equivocarse. La solución no es fingir certeza, sino describir método, ventana temporal y límites.

El esquema mínimo separa dirección invitada, valor de respuesta, actor o representante, SEQUENCE, alcance de recurrencia, resultado de entrega, señal observada durante el evento, método y excepciones. PARTSTAT=ACCEPTED ocupa la columna de respuesta. Si nadie midió la presencia, la columna de observación queda vacía.

Una celda vacía conserva una verdad incómoda: el calendario sabía lo que se contestó, no lo que ocurrió.