0

我正在开发一个基于 JavaScript 的应用程序，该应用程序在每个事件的 1 个组织者和 1 个或更多参与者之间设置事件。由于它是面向公众的，因此组织者和与会者可以使用几乎任何（主要）日历和/或电子邮件服务。

我已经确定 iCal (.ics) 是共享日历事件最广泛支持的格式，因此我编写了发出有效 .ics 文件的代码（针对多个在线验证器成功测试）但我对如何使用感到困惑文件。我的期望是：

  1. 生成带有组织者和与会者的 .ics 文件（以及组织者的与会者条目，PARSTAT=ACCEPTED）
  2. 组织者将 .ics 文件发送给与会者（仅供参考：通过在组织者的 ui 中打开邮件客户端并预先附加 .ics 文件并预设为：字段来实现）
  3. 组织者和与会者各自的邮件/日历服务提供商（例如 gmail/gcal/outlook/exchange/etc）解析 .ics 文件并自动将其添加到用户的日历中
  4. RSVP 状态由日历服务提供商跟踪

但是，由于各种原因，这种用法似乎不适用于主要提供商，例如，为了简单起见，我们假设组织者和与会者都使用 Gmail：

  1. Gmail 似乎在组织者一方（.ics 文件发件人）和与会者一方（收件人）都解析文件，但只为与会者提供将事件添加到其日历的操作。没有为组织者提供将其添加到他/她的日历的自动操作。我可以确认它是在组织者一方解析的，因为 Gmail “知道”它是组织者，并且故意不提供“添加到日历”操作，即使他/她也是与会者（通过在 . .ics 文件）。

  2. 向与会者提供“添加到日历”操作，添加后，会提供 RSVP 操作，但实际上并未与组织者同步（此时谁在他/她的日历中可能有也可能没有该事件，具体取决于关于他们是否手动添加）。

我可以保证与会者的定义正确（使用 PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE）并且我生成的 .ics 文件是有效的并且它们的内容是正确的。

  • 关于 .ics 标准，我上面概述的预期用法是不正确的，还是由于日历/邮件提供商的特殊性而导致的问题？

  • 是否有另一种策略来使用 .ics 文件来实现这个用例，或者我是否从根本上误解了 .ics 文件的用法——它们不是要作为附件邮寄出去吗？除非您运行自己的 CalDAV 服务器，否则他们不支持 RSVP 吗？

4

1 回答 1

1

使用 iMIP/iTIP，没有将邀请“注入”到组织者日历中的概念。初始工作流由组织者触发，因此假设活动已经在组织者的日历中。

对于第 2 点），如果活动在组织者的日历中并且未处理回复，那么您使用协议的方式可能存在问题。我们需要详细信息（原始请求和回复）来帮助您调试它。

在我如何创建并通过电子邮件发送邀请两个不相关的收件人参加他们之间的会议并允许他们控制进一步的安排

于 2017-05-03T09:06:37.600 回答