Resumen

  • En RFC 2446, un COUNTER completo enviado por un Attendee es una propuesta alternativa; no modifica por sí mismo la entrada maestra controlada por el Organizer.
  • Si el organizador acepta el cambio, su decisión y el nuevo REQUEST que comunica la revisión son transiciones separadas. Transporte, autenticación, PARTSTAT, estado local y participación real pertenecen a capas distintas.

Supongamos una reunión programada para el lunes. Uno de los invitados preferiría celebrarla el martes y envía un COUNTER. El mensaje puede contener un VEVENT completo, con todos los datos necesarios para describir la alternativa. Sin embargo, “completo” no significa “autoritativo”. La arquitectura descrita por RFC 2446 distingue quién propone de quién controla la entrada de calendario que sirve como referencia del intercambio.

Esa separación se entiende mejor empezando una capa antes. RFC 2445 define el formato y el modelo de datos iCalendar: componentes como VEVENT, propiedades y parámetros. RFC 2446 construye sobre esos objetos las transacciones de programación iTIP, independientemente del transporte. En otras palabras, una cosa es la representación del evento y otra el protocolo que determina qué tipo de mensaje está circulando y qué significa dentro de una relación de programación.

En ese modelo, el Organizer inicia el intercambio y mantiene la entrada maestra; los usuarios invitados participan como Attendees. Estos papeles protocolarios no deben confundirse con el parámetro descriptivo ROLE de ATTENDEE, que puede etiquetar a una persona como chair o req-participant. ROLE describe una función dentro del evento; no transfiere la autoridad del Organizer sobre la copia maestra.

También conviene separar estado global de estado individual. STATUS pertenece al estado general de la entrada, mientras que PARTSTAT expresa el estado de participación de un asistente concreto. Que un Attendee acepte, rechace o proponga una alternativa no equivale a modificar unilateralmente el objeto maestro.

RFC 2446 define métodos con efectos distintos. PUBLISH distribuye información sin esperar una respuesta interactiva. REQUEST pide al destinatario que procese un objeto de programación. REPLY comunica el estado de un participante. COUNTER permite proponer una modificación y DECLINECOUNTER permite que el organizador la rechace. El punto decisivo es que el COUNTER del asistente contiene una alternativa completa, no una edición remota del registro maestro.

Por eso, en el ejemplo del lunes y el martes, la recepción del COUNTER no convierte automáticamente el martes en la nueva fecha oficial. Primero existe una propuesta. Después existe una decisión del organizador. Si este la acepta, la reprogramación se expresa mediante un nuevo REQUEST dirigido a los asistentes afectados. RFC 5546, que posteriormente sustituyó a RFC 2446, conserva este principio y especifica que el agente de calendario del organizador debería emitir el REQUEST correspondiente después de aceptar una contrapropuesta.

SEQUENCE tampoco debe interpretarse como un contador de consentimiento. Según las reglas de iTIP, sigue revisiones realizadas desde el lado del organizador. REPLY, REFRESH, COUNTER, DECLINECOUNTER y un REQUEST empleado para delegación no incrementan por sí mismos ese valor; ADD y CANCEL sí forman parte de los casos que lo hacen. De ahí se sigue otra consecuencia importante: una respuesta puede referirse legítimamente a una revisión anterior sin que esa diferencia, por sí sola, pruebe un fallo de autorización o de procesamiento.

La separación de autoridad aparece también al reenviar invitaciones. Un asistente que reenvía una invitación a una persona que no estaba invitada no incorpora por ese acto al nuevo destinatario en la lista maestra. Corresponde al organizador decidir si lo añade, y quien reenvía no debe modificar las propiedades del evento como si controlara la copia principal.

A estas transiciones lógicas hay que añadir la capa de transporte. RFC 2446 fue diseñado como protocolo independiente del mecanismo de entrega. RFC 2447 proporcionó la vinculación por correo electrónico, posteriormente actualizada por RFC 6047. En redes store-and-forward, el orden de llegada puede diferir del orden lógico de generación. RFC 2446 contempla incluso que un CANCEL llegue antes que el REQUEST original. Para un CANCEL no correlacionado cuyo SEQUENCE sea distinto de cero, sugiere conservarlo temporalmente mientras se espera un mensaje con secuencia inferior y permite que termine caducando si ese mensaje nunca aparece.

Esto impide usar la simple visibilidad de un mensaje como prueba del estado global del sistema. Haber recibido bytes no demuestra que todos los destinatarios hayan recibido la misma revisión. Un objeto sintácticamente válido no demuestra que su remitente estuviera autorizado. Una fila local marcada como aceptada no prueba que el organizador haya cambiado su entrada maestra. Un recordatorio no prueba asistencia. Un evento visible en una interfaz no prueba que la reunión haya ocurrido.

La seguridad refuerza esta distinción. Los roles iTIP no autentican identidades. RFC 2446 identifica el riesgo de mensajes falsificados que aparenten proceder del organizador o de un asistente y deja la autenticación y el cifrado a la vinculación de transporte. Mecanismos de seguridad de correo, incluidos los definidos en RFC 1847, pertenecen a esa capa diferente. Saber qué método contiene un objeto no equivale a saber quién lo envió realmente ni si ese remitente tenía autoridad para producir el efecto pretendido.

La lectura histórica más útil de iTIP es, por tanto, una cadena de estados separados: bytes del mensaje; identidad autenticada y autorización del remitente; METHOD y UID; SEQUENCE bajo control del organizador; PARTSTAT de cada asistente; contenido de un COUNTER; decisión posterior del organizador; eventual REQUEST revisado; recepción por transporte; commit en un calendario local; generación de recordatorios; y, finalmente, participación observable en el mundo real. Ninguna de esas capas debería utilizarse automáticamente como sustituto probatorio de la siguiente.

Fuentes