Resumen

  • La revisión 08 del borrador de extensiones iCalendar incorpora OWNER, pero declara que el papel es solo indicativo y no puede conceder por sí mismo autoridad para modificar un calendario.
  • JMAP Calendars muestra los controles que faltan: el participante debe corresponder a una identidad de la cuenta y la operación debe estar permitida por los derechos actuales y las restricciones del evento.
  • Interpretar la etiqueta, autorizar, guardar, enviar mensajes, obtener aceptación remota y lograr que el participante vea el cambio son comprobantes distintos.

El objeto peligroso no tiene por qué estar mal formado. Puede ser sintácticamente impecable, superar el analizador y mostrar una convincente insignia de propietario. El fallo comienza cuando el programa eleva esa descripción a permiso.

La revisión 08 define OWNER como un papel de participación. La definición señala que el propietario puede hacer cambios que afectan a todos, como reprogramar o añadir y quitar asistentes. Inmediatamente fija el límite: el papel es indicativo, su semántica depende del protocolo de intercambio y ninguna implementación debe autorizar cambios solo porque aparezca en el objeto.

Esa regla separa una afirmación transportada por los datos del poder ejercido por el sistema. En un calendario es fácil confundirlas porque el papel viaja junto con horas, lugares, reglas de repetición y participantes que la aplicación sí procesa directamente.

La afirmación es portátil; la autoridad no

RFC 5545 ofrece una representación portátil. Un mismo objeto puede pasar por archivos, correo, depósitos CalDAV y servicios JMAP con modelos de identidad y permisos diferentes. Por eso el papel no puede contener un permiso universal.

El borrador dice expresamente que no define la semántica de OWNER en CalDAV. El receptor puede conservar y mostrar el papel, pero no inventar una regla de escritura ausente. Tampoco una futura entrada en los registros iCalendar de IANA autenticaría al participante ni le concedería capacidad: el registro coordina el nombre y su referencia.

La especificación inicial mínima explica el diseño. El vocabulario común debe ser suficiente para interoperar sin centralizar decisiones futuras. OWNER puede ser vocabulario compartido; la concesión sigue perteneciendo al protocolo y a la autoridad local.

JMAP hace visible la superficie de control

El borrador activo de JMAP Calendars define a un usuario como propietario solo cuando un Participante tiene el papel owner y corresponde a una ParticipantIdentity del usuario en esa cuenta.

Ni siquiera esa coincidencia otorga capacidad universal. mayWriteOwn permite crear, modificar o destruir eventos solo en el calendario donde ese derecho está vigente y solo si el usuario es propietario o el evento carece de propietario. mayWriteAll, mayRSVP, mayShare y mayDelete abarcan facultades distintas.

En CalendarEvent/set, el servidor debe aplicar myRights y responder con forbidden si la operación no está permitida. Ese veredicto constituye el comprobante de autoridad. El papel es una entrada, no el resultado.

También importan el origen del evento, su privacidad, la recurrencia y los calendarios a los que pertenece. Si una copia no es el origen de la programación, el cliente debe limitar la edición a propiedades por usuario aunque los derechos parezcan más amplios, porque una actualización futura del origen puede sobrescribirla.

Etapa Qué demuestra Qué sigue abierto
Análisis OWNER está presente en sintaxis válida Quién lo afirmó y si sigue vigente
Identidad El participante corresponde a la cuenta Derechos sobre calendario y evento
Autorización Una regla actual permite la operación Si el cambio fue aceptado
Mutación El servidor guardó un nuevo estado Si se enviaron mensajes
Entrega Otro sistema recibió el mensaje Si lo aplicó o mostró
Lectura posterior Un participante observa el cambio Convergencia duradera de todas las copias

Guardar no significa que la reunión cambió para todos

JMAP permite solicitar mensajes de programación al modificar un evento. La solicitud no demuestra entrega. El servidor puede guardar la copia local, formar la lista de destinatarios y después encontrar un fallo de transporte, un rechazo remoto o una copia que el usuario nunca consulta.

RFC 6638 y RFC 4791 muestran que almacenamiento y programación son superficies relacionadas, no un hecho atómico. Colección, autoridad del usuario, buzón de salida y copia del asistente requieren evidencia separada.

Un registro útil enlaza huella del objeto, ubicación del papel, coincidencia de identidad, versión de derechos, origen y privacidad, decisión de política, identificador y huellas de la mutación, selección de destinatarios, transporte y lectura posterior. No hace falta guardar contenido privado: bastan identificadores estables, huellas y resultados limitados.

Avance normativo no equivale a prueba operativa

La ficha de Datatracker presenta la revisión 08 como borrador del grupo CALENDAR EXTENSIONS destinado a Proposed Standard, con publicación solicitada. El historial y el informe del shepherd documentan el proceso. Todavía no hay RFC ni prueba de comportamiento de productos desplegados.

El documento también añade SHOW-WITHOUT-TIME y aclara que esa indicación visual no cambia el intervalo temporal usado para conflictos. La misma disciplina se aplica aquí: una presentación no puede reescribir un estado profundo; un rótulo OWNER no puede reescribir autorización.

Running-Code Primacy exige mirar qué identidad se resolvió, qué derechos se cargaron y qué veredicto emitió el servidor. The Policy Mirror revela el poder situado en cachés, resolución e interpretación. Reality Layers impide fusionar sintaxis, papel, autoridad y resultado en una sola luz verde.

La pregunta directiva no es «¿el calendario dice propietario?», sino «¿qué sistema concedió qué operación sobre qué estado, y qué prueba muestra que el cambio llegó a quienes dependían de él?»

Fuentes