.ics 文件是否支持邮寄？邮寄时是否支持 RSVP 等 iCal 功能？
Do .ics files support being mailed? Are iCal features like RSVP supported when mailing them?
我正在开发一个基于 JavaScript 的应用程序，该应用程序在每个活动中设置 1 个组织者和 1 个或多个参与者之间的活动。由于面向 public，组织者和与会者几乎可以使用任何（主要）日历 and/or 电子邮件服务。
我确定 iCal (.ics) 是最广泛支持的日历事件共享格式，因此我编写了生成有效 .ics 文件的代码（已针对多个在线验证器成功测试），但我对如何使用该文件感到困惑。我的期望是：
- 生成包含组织者和与会者的 .ics 文件（以及组织者的与会者条目，同时使用 PARSTAT=ACCEPTED）
- 组织者将 .ics 文件发送给与会者（仅供参考：通过在组织者 ui 中打开邮件客户端并预先附加 .ics 文件并预设为：字段来实现）
- 组织者和与会者各自的 mail/calendar 服务提供商（例如 gmail/gcal/outlook/exchange/etc）解析 .ics 文件并自动将其添加到用户的日历中
- RSVP 状态由日历服务提供商跟踪
但是，由于各种原因，这种用法似乎不适用于主要提供商，例如为简单起见，我们假设组织者和与会者都使用 Gmail：
Gmail 似乎在组织者一方（.ics 文件发件人）和与会者一方（收件人）解析文件，但只为与会者提供将活动添加到他们的日历的操作.没有为组织者提供将其添加到 his/her 日历的自动操作。我可以确认它是在组织者这边解析的，因为 Gmail "knows" 它是组织者并且故意不提供 "add to calendar" 操作，即使 s/he 也是与会者（通过修改.ics 文件中的管理器）。
"Add to Calendar" 操作提供给与会者，添加后，提供 RSVP 操作，但实际上并不与组织者同步（此时组织者可能会也可能不会甚至在 his/her 日历中包含事件，具体取决于他们是否手动添加）。
我可以保证参与者定义正确（PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE）并且我生成的 .ics 文件有效且内容正确。
关于 .ics 标准，我上面概述的预期用法是否不正确，或者问题是因为 calendar/mail 提供商的特质？
是否有其他策略可以使用 .ics 文件来实现此用例，或者我是否从根本上误解了 .ics 文件的用法 - 它们不应该作为附件邮寄吗？除非你 运行 你自己的 CalDAV 服务器，否则他们不支持 RSVP 吗？
对于 iMIP/iTIP，没有 "injecting" 邀请进入组织者日历的概念。初始工作流程由组织者触发，因此假设事件已经在组织者的日历中。
对于第 2 点，如果事件 是 在组织者的日历中并且未处理回复，那么您使用协议的方式可能存在问题。我们需要详细信息（包括原始请求和回复）来帮助您进行调试。
在
有某种相关的回复
我正在开发一个基于 JavaScript 的应用程序，该应用程序在每个活动中设置 1 个组织者和 1 个或多个参与者之间的活动。由于面向 public，组织者和与会者几乎可以使用任何（主要）日历 and/or 电子邮件服务。
我确定 iCal (.ics) 是最广泛支持的日历事件共享格式，因此我编写了生成有效 .ics 文件的代码（已针对多个在线验证器成功测试），但我对如何使用该文件感到困惑。我的期望是：
- 生成包含组织者和与会者的 .ics 文件（以及组织者的与会者条目，同时使用 PARSTAT=ACCEPTED）
- 组织者将 .ics 文件发送给与会者（仅供参考：通过在组织者 ui 中打开邮件客户端并预先附加 .ics 文件并预设为：字段来实现）
- 组织者和与会者各自的 mail/calendar 服务提供商（例如 gmail/gcal/outlook/exchange/etc）解析 .ics 文件并自动将其添加到用户的日历中
- RSVP 状态由日历服务提供商跟踪
但是，由于各种原因，这种用法似乎不适用于主要提供商，例如为简单起见，我们假设组织者和与会者都使用 Gmail：
Gmail 似乎在组织者一方（.ics 文件发件人）和与会者一方（收件人）解析文件，但只为与会者提供将活动添加到他们的日历的操作.没有为组织者提供将其添加到 his/her 日历的自动操作。我可以确认它是在组织者这边解析的，因为 Gmail "knows" 它是组织者并且故意不提供 "add to calendar" 操作，即使 s/he 也是与会者（通过修改.ics 文件中的管理器）。
"Add to Calendar" 操作提供给与会者，添加后，提供 RSVP 操作，但实际上并不与组织者同步（此时组织者可能会也可能不会甚至在 his/her 日历中包含事件，具体取决于他们是否手动添加）。
我可以保证参与者定义正确（PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE）并且我生成的 .ics 文件有效且内容正确。
关于 .ics 标准，我上面概述的预期用法是否不正确，或者问题是因为 calendar/mail 提供商的特质？
是否有其他策略可以使用 .ics 文件来实现此用例，或者我是否从根本上误解了 .ics 文件的用法 - 它们不应该作为附件邮寄吗？除非你 运行 你自己的 CalDAV 服务器，否则他们不支持 RSVP 吗？
对于 iMIP/iTIP，没有 "injecting" 邀请进入组织者日历的概念。初始工作流程由组织者触发，因此假设事件已经在组织者的日历中。
对于第 2 点，如果事件 是 在组织者的日历中并且未处理回复，那么您使用协议的方式可能存在问题。我们需要详细信息（包括原始请求和回复）来帮助您进行调试。
在