Кратко

  • RFC 2446 определил транспортно-независимую семантику календарных scheduling-транзакций: Organizer контролирует master entry, а Attendee может отвечать, запрашивать информацию или предлагать изменение, не переписывая мастер-запись самостоятельно.
  • COUNTER в iTIP — предложение альтернативы, а не изменение общего события; решение принимает Organizer, и принятие предложения выражается отдельным изменением master entry и новым REQUEST затронутым участникам.
  • SEQUENCE отражает линию ревизий, контролируемых Organizer, а не степень согласия участников или факт доставки последней версии каждому адресату.
  • STATUS и PARTSTAT относятся к разным уровням состояния, а транспортная аутентификация, календарная роль и право выполнить действие должны рассматриваться отдельно.
  • Полученный COUNTER, REPLY, delivery receipt, reminder или видимая запись календаря сами по себе не доказывают ни глобального схождения, ни полномочия, ни фактического участия в событии.

RFC 2446, опубликованный в ноябре 1998 года как Standards Track, носил полное название iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries. Его историческая роль понятнее всего в связке с RFC 2445, который определял объекты, свойства, компоненты и модель данных iCalendar. RFC 2445 отвечал прежде всего на вопрос, как представить календарную информацию. RFC 2446 отвечал на другой вопрос: что означает обмен такими объектами между календарными пользователями и какие действия считаются отдельными scheduling-транзакциями.

Это различие между представлением данных и протокольным действием было принципиальным. iTIP не предполагал, что любой полученный iCalendar-объект автоматически меняет общее календарное состояние. Он описывал набор методов и ролей, через которые изменения публикуются, запрашиваются, подтверждаются, отклоняются или предлагаются. Позднее RFC 5545 заменил RFC 2445 как основную спецификацию iCalendar, а RFC 5546 заменил RFC 2446, сохранив основную архитектурную модель iTIP. Первоначальную привязку к электронной почте задал RFC 2447, а RFC 6047 позднее обновил iCalendar Message-Based Interoperability Protocol. Тем самым сам iTIP оставался транспортно-независимой семантикой, а конкретный механизм передачи существовал отдельным слоем.

Центральное место в этой модели занимают Organizer и Attendee. Organizer начинает scheduling-обмен и контролирует master entry — авторитетное представление события со своей стороны. Приглашённые пользователи выступают Attendees. Важно не смешивать эти протокольные роли с параметром ROLE свойства ATTENDEE. Параметр ROLE описывает характеристику участия, например требуемый или необязательный участник, но сам по себе не передаёт контроль над master entry и не превращает Attendee в Organizer. Протокольная власть и описательный атрибут календарного объекта — разные вещи.

Та же дисциплина разделения уровней видна в полях состояния. STATUS относится к состоянию календарного компонента в целом. PARTSTAT относится к участию конкретного Attendee. Они отвечают на разные вопросы. Состояние всего VEVENT нельзя выводить из состояния одного участника, а состояние одного участника нельзя считать подтверждением состояния всех остальных. Если один Attendee ответил ACCEPTED, это означает состояние именно этого участника в соответствующем контексте; оно не доказывает, что остальные получили ту же ревизию, приняли приглашение или вообще обработали сообщение.

Методы iTIP также выражают разные операции. PUBLISH распространяет календарную информацию без ожидания интерактивного ответа от получателей. REQUEST просит получателя обработать scheduling-объект и поддерживает последующий ответ. REPLY сообщает состояние конкретного участника. COUNTER предлагает изменение существующего предложения. DECLINECOUNTER позволяет Organizer отклонить такое контрпредложение. Уже из этого набора видно, что протокол не сводит коммуникацию к одному бинарному состоянию «событие принято» или «событие не принято».

Особенно важен COUNTER. В RFC 2446 Attendee может сформировать контрпредложение, включая полноценный альтернативный календарный компонент. Однако это не означает, что Attendee самостоятельно изменил master entry Organizer. COUNTER представляет альтернативу и передаёт её стороне, которая контролирует авторитетную запись. Между созданием контрпредложения и изменением расписания существует обязательный логический разрыв: Organizer должен принять или отклонить предложение.

Гипотетический пример хорошо показывает эту границу. Допустим, Organizer назначил встречу на понедельник. Один из Attendees отправляет COUNTER с полностью сформированным VEVENT, где предложен вторник. Этот VEVENT может быть синтаксически корректным, содержать тот же UID, необходимые свойства и новую предлагаемую дату. Получатель может успешно разобрать его. Система может показать пользователю, что поступило контрпредложение. Но ни один из этих фактов сам по себе не превращает вторник в новое время master entry. До отдельного решения Organizer вторник остаётся предложением.

Если Organizer принимает COUNTER, следующим протокольным шагом становится не молчаливое превращение чужого сообщения в новый master, а собственное изменение Organizer и новый REQUEST затронутым участникам. RFC 5546, пришедший на смену RFC 2446, сохраняет этот механизм и рекомендует после принятия COUNTER направить новый REQUEST с обновлённым состоянием. Таким образом, COUNTER, решение Organizer и последующий REQUEST — три различимые стадии. Их нельзя сжимать в один факт «встречу перенесли».

Именно поэтому SEQUENCE также нельзя читать как меру коллективного согласия. В iTIP он связан с ревизиями календарного объекта, которые контролирует Organizer. Увеличение SEQUENCE сообщает о продвижении линии организаторских изменений, но не означает, что все Attendees увидели эту ревизию, признали её или приняли участие в событии. REPLY, REFRESH, COUNTER, DECLINECOUNTER и REQUEST, связанный с делегированием, сами по себе не означают продвижения Organizer SEQUENCE. ADD и CANCEL, напротив, относятся к операциям, для которых последовательность ревизий продвигается согласно правилам протокола.

Это различие особенно важно при анализе ответов на разные версии события. REPLY может относиться к более ранней ревизии. Поэтому наличие ответа от участника и наличие более высокого SEQUENCE в другой копии календарного объекта нельзя механически объединять в вывод, что участник ответил именно на последнюю известную ревизию. Чтобы установить смысл ответа, требуется сохранить контекст версии и последовательность сообщений, а не смотреть на отдельные поля вне временной линии.

Пересылка приглашений создаёт ещё один пример того, как iTIP ограничивает автоматические выводы. Если известный Attendee переслал REQUEST другому пользователю, неизвестный ранее получатель не становится автоматически частью master attendee list Organizer. Сам пересылающий также не получает права изменить свойства общего события только потому, что передал сообщение дальше. Включение дополнительного участника остаётся решением Organizer и должно выражаться через соответствующую организаторскую транзакцию.

Это означает, что адресат, увидевший корректное приглашение, может находиться в совершенно ином протокольном положении, чем исходные Attendees. Наличие байтов, UID, Organizer и содержимого VEVENT ещё не доказывает, что Organizer признаёт этого пользователя участником. В распределённой системе пересылка транспортного объекта и изменение авторитетного списка участников — разные события.

Отдельный класс проблем связан с порядком доставки. Транспортные системы типа store-and-forward не гарантируют, что сообщения будут наблюдаться в том же порядке, в котором протокольные действия были сформированы. RFC 2446 учитывал ситуацию, когда CANCEL приходит раньше исходного или более раннего REQUEST. Для несопоставленного CANCEL с ненулевым SEQUENCE спецификация допускала временное удержание сообщения в ожидании связанного более раннего объекта. Такое ожидание не обязано быть бесконечным: реализация может прекратить его после истечения локально определённого периода.

Этот пример показывает, почему транспортная доставка и логический порядок календарного состояния должны анализироваться раздельно. CANCEL, наблюдаемый первым, не доказывает, что REQUEST никогда не существовал. Поздний REQUEST не обязательно означает, что отмена была создана позже. Порядок поступления в конкретный клиент — это наблюдение транспортного уровня, тогда как SEQUENCE, METHOD и история действий Organizer относятся к логике scheduling-протокола.

Вопрос безопасности добавляет ещё одну границу. Поля Organizer и Attendee являются частью календарного содержимого, но сами по себе не выполняют функцию аутентификации. RFC 2446 рассматривал возможность подмены Organizer или Attendee. Проверка происхождения, целостности и при необходимости конфиденциальности связывалась с транспортным binding и механизмами защиты сообщений. Для первоначальной почтовой модели существенным фоном был RFC 1847, описывавший Multipart/Signed и Multipart/Encrypted для MIME.

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

Из этого следует практическая схема анализа iTIP, полезная и для исторического чтения протокола, и для разбора конкретной реализации. Сначала существуют сырые байты и транспортный envelope. Затем устанавливается, если это вообще возможно, аутентифицированный отправитель. После этого отдельно определяется его право действовать. Далее рассматриваются METHOD и UID, Organizer и его SEQUENCE, личный PARTSTAT, наличие COUNTER, решение Organizer и новый REQUEST. Только после этого идут факты доставки, локальной обработки, commit в календарное хранилище, reminder и, наконец, наблюдаемое реальное участие человека.

Каждый из этих слоёв даёт более узкое доказательство, чем может показаться интерфейсу пользователя. Разобранный COUNTER доказывает, что система получила и поняла предложение в пределах своей реализации, но не доказывает его принятия Organizer. Высокий SEQUENCE показывает номер ревизии в соответствующем объекте, но не коллективное согласие. Delivery receipt говорит о некотором транспортном факте, но не обязательно о содержательной обработке календарным агентом. REPLY сообщает заявленное состояние участника, но не доказывает фактического присутствия на встрече.

Точно так же локально принятое приглашение не означает, что другие адресаты пришли к тому же состоянию. Reminder подтверждает существование локального механизма напоминания, а не участие. Видимая запись в календарном интерфейсе показывает локальное представление данных, но не гарантирует, что оно совпадает с master entry Organizer или последним состоянием других систем. Даже новый REQUEST, созданный Organizer, ещё не доказывает фактическую доставку каждому получателю.

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

Поэтому тексты Heng Lu могут использоваться лишь как аналитическая оптика для различения уровней реальности, спецификации, реализации и наблюдаемого эффекта. Они не являются источником нормативных фактов об iTIP. Нормативные утверждения о COUNTER, Organizer, SEQUENCE, STATUS, PARTSTAT, пересылке, CANCEL или безопасности должны опираться на RFC и связанные реестры, а не на более позднюю интерпретационную рамку.

Историческое значение RFC 2446 заключается именно в том, что он не пытался устранить распределённую неопределённость декларацией. Вместо этого спецификация описывала роли и переходы: кто публикует, кто запрашивает, кто отвечает, кто предлагает изменение и кто контролирует мастер-состояние. Там, где транспорт мог переупорядочить сообщения, протокол предусматривал возможность ожидания. Там, где участник мог предложить альтернативу, протокол не превращал предложение в решение. Там, где календарное поле называло Organizer, безопасность не предполагала, что само поле доказывает личность.

Такой дизайн делает ранний iTIP примером более общего интернет-принципа: распределённая система должна различать утверждение, полномочие, переход состояния и наблюдаемый результат. Между ними существуют реальные границы, и сокращение этих границ ради удобной интерпретации создаёт ложную уверенность. В календарном протоколе 1998 года это проявлялось в на первый взгляд простом вопросе — можно ли перенести встречу с понедельника на вторник.

Ответ протокола был точнее: Attendee может предложить вторник, Organizer может его принять, затем Organizer должен выразить новое авторитетное состояние, после чего остаются ещё доставка и локальная обработка.

Именно поэтому RFC 2446 остаётся полезным историческим материалом. Он показывает Интернет не как пространство, где корректное сообщение автоматически становится фактом, а как систему, где каждый переход должен быть отнесён к конкретному субъекту и уровню. COUNTER — предложение. Решение Organizer — отдельное действие. Новый REQUEST — отдельное сообщение. SEQUENCE — линия ревизий, а не согласие. STATUS и PARTSTAT — разные состояния. Аутентификация отправителя — не то же самое, что право изменить событие. Доставка — не то же самое, что commit. И ни один из этих технических сигналов сам по себе не доказывает, что встреча в итоге состоялась.

Источники

  1. RFC 2446 — iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entrieshttps://www.rfc-editor.org/rfc/rfc2446.html
  2. RFC Editor — RFC 2446: iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entrieshttps://www.rfc-editor.org/info/rfc2446/
  3. IETF Datatracker — RFC 2446: iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entrieshttps://datatracker.ietf.org/doc/rfc2446/
  4. RFC Editor — Errata for RFC 2446https://www.rfc-editor.org/errata_search.php?rfc=2446
  5. RFC 2445 — Internet Calendaring and Scheduling Core Object Specification (iCalendar)https://www.rfc-editor.org/rfc/rfc2445.html
  6. RFC 2447 — iCalendar Message-Based Interoperability Protocol (iMIP)https://www.rfc-editor.org/rfc/rfc2447.html
  7. RFC 5545 — Internet Calendaring and Scheduling Core Object Specification (iCalendar)https://www.rfc-editor.org/rfc/rfc5545.html
  8. RFC 5546 — iCalendar Transport-Independent Interoperability Protocol (iTIP)https://www.rfc-editor.org/rfc/rfc5546.html
  9. RFC 6047 — iCalendar Message-Based Interoperability Protocol (iMIP)https://www.rfc-editor.org/rfc/rfc6047.html
  10. RFC 1847 — Security Multiparts for MIME: Multipart/Signed and Multipart/Encryptedhttps://www.rfc-editor.org/rfc/rfc1847.html
  11. IANA — iCalendar Registrieshttps://www.iana.org/assignments/icalendar/
  12. Heng Lu — Running Code Primary: The Patch Needed to Preserve the Internet Original Designhttps://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  13. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption: Internet Coordination Systemhttps://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  14. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostilehttps://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/