Кратко

  • Редакция 08 проекта расширений iCalendar вводит роль OWNER, но прямо называет её лишь указанием и запрещает выдавать право изменения только на её основании.
  • JMAP Calendars показывает недостающий контур: участник должен соответствовать идентификатору пользователя в аккаунте, а текущие права календаря и ограничения события должны разрешать операцию.
  • Разбор роли, привязка личности, авторизация, сохранение, отправка, удалённая обработка и видимый участнику результат требуют отдельных квитанций.

Опасная запись не обязана быть повреждённой. Она может быть синтаксически правильной, пройти все анализаторы и показать убедительный значок владельца. Ошибка начинается тогда, когда программа превращает это описание в разрешение.

Редакция 08 определяет OWNER как роль участника. Владелец может вносить затрагивающие всех изменения: переносить событие, добавлять и удалять участников и роли. Сразу после этого проект проводит главную границу: роль носит указательный характер, её смысл зависит от протокола обмена, и реализация не должна разрешать изменение лишь из-за наличия значения в объекте.

Так отделяется утверждение в данных от власти системы. В календаре их легко спутать: роль приходит рядом со временем, местом, повторением и участниками в одном интерфейсе действий.

Утверждение переносимо, полномочие — нет

RFC 5545 задаёт переносимое представление. Один объект может пройти через файл, сообщение, хранилище CalDAV и сервис JMAP с разными аккаунтами, идентификаторами и моделями прав. Поэтому поле роли не может нести универсальное право записи.

Проект прямо не определяет смысл OWNER для CalDAV. Получатель может сохранить и показать роль, но не вправе выдумать отсутствующее правило записи. Будущая регистрация в реестрах iCalendar IANA также лишь согласует имя и ссылку; она не аутентифицирует участника и не выдаёт полномочий.

Это соответствует Minimum Initial Specification: общий формат фиксирует минимальный смысл для совместимости, не централизуя будущую локальную политику. OWNER может быть общим словарём, а выдача права остаётся у протокола и оператора.

JMAP раскрывает цепочку решения

Активный проект JMAP Calendars считает пользователя владельцем события только тогда, когда Participant имеет роль owner и соответствует одной из ParticipantIdentity пользователя в аккаунте.

Даже это не создаёт универсальной способности. mayWriteOwn разрешает создавать, изменять или удалять события лишь в календаре с таким правом и когда пользователь владеет событием либо у события нет владельца. mayWriteAll, mayRSVP, mayShare и mayDelete описывают иные полномочия.

При CalendarEvent/set сервер обязан применить myRights и отклонить запрещённое изменение ошибкой forbidden. Этот вердикт и есть квитанция полномочия. Роль — только один вход решения.

Источник события, приватность, повторение и принадлежность календарям могут снова сузить результат. Если копия не является источником планирования, клиент должен ограничить изменения пользовательскими свойствами, даже когда права выглядят шире: позднее авторитетное обновление может перезаписать копию.

Этап Что установлено Что ещё не установлено
Разбор OWNER присутствует в допустимом синтаксисе Кто заявил и актуально ли это
Идентичность Участник соответствует аккаунту Права на календарь и событие
Авторизация Текущее правило разрешает операцию Принято ли изменение
Изменение Сервер сохранил новое состояние Отправлены ли сообщения
Доставка Другая система получила сообщение Применила и показала ли она его
Считывание Участник видит изменение Сошлись ли все копии надолго

Успешное сохранение ещё не изменило встречу для всех

JMAP позволяет запросить сообщения планирования вместе с изменением. Запрос не доказывает доставку. После локального сохранения остаются выбор адресатов, очередь, транспорт, удалённое принятие и отображение в копии участника.

RFC 6638 и RFC 4791 показывают хранение и планирование как связанные, но отдельные поверхности. Коллекция, право пользователя, исходящая очередь и копия участника не являются одним атомарным фактом.

Надёжный журнал связывает хэш исходного объекта, положение роли, соответствие идентичности, версию прав, источник и приватность, вердикт политики, идентификатор и хэши изменения, выбор получателей, транспорт и считывание. Содержимое частной встречи записывать не нужно: достаточно ограниченных результатов, устойчивых идентификаторов и хэшей.

Продвижение стандарта не доказывает работу

Datatracker показывает редакцию 08 как Internet-Draft рабочей группы CALENDAR EXTENSIONS с предполагаемым статусом Proposed Standard и запросом публикации. История и отчёт сопровождающего фиксируют процесс. Это ещё не RFC и не доказательство поведения развёрнутых продуктов.

Тот же документ добавляет SHOW-WITHOUT-TIME, но подчёркивает: представление не меняет временной интервал для проверки конфликтов. Дисциплина та же — внешний вид не переписывает глубокое состояние, а OWNER не переписывает авторизацию.

Running-Code Primacy требует смотреть на фактически разрешённый идентификатор, загруженные права и вердикт сервера. The Policy Mirror раскрывает власть в поиске, кэше и значениях по умолчанию. Reality Layers не позволяет слить синтаксис, роль, полномочие и результат в один зелёный индикатор.

Вопрос руководства звучит не «написано ли в календаре “владелец”?», а «какая система разрешила какую операцию над каким состоянием и какое последующее доказательство показывает, что изменение дошло до зависящих от него людей?»

Источники