Кратко

  • PARTSTAT=ACCEPTED — это переданный статус участия календарного пользователя, а не наблюдение за его последующим присутствием.
  • Ответившего, представителя, редакцию события, повтор, доставку и сигнал с самой встречи необходимо хранить раздельно.

После совещания организатор видит в календаре десять принятых приглашений и называет это стопроцентной явкой. В комнате, однако, было восемь человек. Разница не обязательно означает сбой. Календарь сохранил ответы до события, а подсчёт в комнате описал другой момент и другой объект.

В RFC 5545 параметр PARTSTAT определён как статус участия календарного пользователя. Для события предусмотрены, среди прочего, NEEDS-ACTION, ACCEPTED, DECLINED, TENTATIVE и DELEGATED. Этот словарь нужен для согласования приглашений. Он ничего не измеряет у двери, в конференц-клиенте или в поведении человека.

Почему здесь важен Cyrus Daboo

Cyrus Daboo участвовал в создании стандартов, по которым такой статус проходит через систему. Он соавтор CalDAV, RFC 4791, автор iTIP, RFC 5546 и вместе с Bernard Desruisseaux автор расширений планирования CalDAV, RFC 6638. Его профиль IETF в исследовательском снимке перечислял 26 RFC. Сообщение CalConnect о награде 2013 года документирует его исторический вклад в совместимость календарей.

Автор RFC 5545 — Bernard Desruisseaux, а не Daboo. Эта оговорка существенна: персональная история не должна присваивать одному человеку коллективную работу над стандартами. Роль Daboo в этой теме особенно видна в протоколе ответов iTIP и серверном планировании CalDAV.

У организатора и участника разные полномочия

В модели iTIP организатор контролирует основную копию объекта планирования. При первой отправке приглашённый обычно получает NEEDS-ACTION. Затем он меняет PARTSTAT в собственной строке ATTENDEE и посылает REPLY; организатор включает ответ в свою копию. Общий STATUS события и PARTSTAT конкретного участника — разные состояния.

Поэтому запись ACCEPTED у организатора подтверждает лишь ограниченный факт: в этой версии объект содержит принятый ответ для данного календарного адреса. Кто управлял клиентом и что произошло на встрече, запись сама не устанавливает.

Адрес, отправитель и пришедший человек

RFC 5546 предусматривает делегирование. Приглашённый может предоставить другому календарному пользователю право присутствовать от своего имени. SENT-BY показывает, что пользователь ответил от имени указанного участника или организатора. В законном процессе могут участвовать помощник, общий ящик или разрешённая автоматизация.

Следовательно, адрес приглашения, субъект отправки ответа и фактический посетитель могут различаться. Если при импорте оставить только слово «принял», проверить такое представительство задним числом уже нельзя.

Ответ относится к редакции и экземпляру

Организатор способен изменить время, место или условия. RFC 5546 использует SEQUENCE для редакций организатора и запрещает увеличивать номер при REPLY. Номер в ответе связывает решение участника с конкретной редакцией. Старое согласие не превращается автоматически в согласие на существенно изменённую встречу.

У повторяющегося события есть ещё и граница экземпляра. Общий ответ на серию может сочетаться с отказом или переносом одного случая, указанного через RECURRENCE-ID. Распространять серию ACCEPTED на каждую дату — значит создавать историю посещений, которой календарь не заявлял.

Сервер CalDAV наблюдает обработку

RFC 6638 описывает неявное планирование: сохранение, изменение или удаление объекта может заставить сервер отправить нужные сообщения. Входящие сообщения могут обрабатываться автоматически. Ответ участника способен обновить PARTSTAT у организатора, а SCHEDULE-STATUS — зафиксировать результат доставки или обработки. Агентом планирования может быть SERVER, CLIENT или NONE.

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

Для присутствия нужна отдельная графа

Безопасность помещения, кворум, сертифицированное обучение или оплата могут требовать учёта посещения. Тогда необходимо заранее выбрать источник и описать его ошибки. Пропуск можно передать, соединение оставить без присмотра, в ручном списке допустить пропуск. Каждый метод подтверждает только собственный сигнал.

Минимальный реестр доказательств разделяет адрес приглашения, значение ответа, ответившего или представителя, SEQUENCE, экземпляр серии, доставку, сигнал во время события, метод, временное окно и исключения. PARTSTAT=ACCEPTED записывается в графу ответа. Если наблюдение не велось, графа присутствия остаётся пустой.

Пустота честно сообщает предел знания и не является поводом подставить удобное значение.