通过电子邮件生成iCal约会和后续更新，但不提供接受/拒绝选项

Question

我们正在编写一个具有预订功能的系统，我们计划让它通过电子邮件向与会者发送*.ics文件，以便他们可以轻松地将约会添加到他们的日历中。活动的类型是类似于培训课程(例如下午3点在会议室)。

我们已经做到了这一点，系统发送*.ics，并使用Gmail和Outlook，用户可以接受约会，然后添加到他们的日历。

有时事件发生变化(例如，课程被取消或推迟到第二天)。我们的软件可以发送一个新的*.ics文件，Gmail/Outlook正确地认识到这是对原始约会的更新，并提供了再次接受/拒绝的选项。

问题是，我们没有通过电子邮件接收标准电子邮件客户端在用户接受/拒绝约会时自动发送的接收/拒绝响应的机制。因此，点击“拒绝”选项可能会让他们误以为他们取消了约会，而实际上我们的系统不知道他们在日历上做了什么。

我们总是希望预订是由用户直接在网站上进行的，而*.ics通过电子邮件只是为了帮助他们记住参加的方便。类似于机票预订，如果乘客真的打算取消，需要做一些比在Outlook中单击“拒绝”更明确的要求。在我做了几次航班预订之后，承运人给我发送了一个*.vcs文件，其中包含“方法:发布”，而不是“方法:请求”，听起来更接近我们想要的，尽管在测试中，*.vcs文件没有被GMail识别为约会。

因此，问题是，我们是否可以通过电子邮件预约，以及随后的更新，这些约会将被Outlook、GMail和Lotus自动识别，但不会让用户认为他们可以在自己的日历工具中取消/拒绝整个预订？如果是这样的话，是怎么做的？

更新1

我想我发现了这个方法的问题:发布我尝试过的航班预订示例--这是过去的一次约会。使用未来的日期，我们现在可以使用方法:发布允许人们在不需要接受/拒绝的情况下将事件添加到他们的日历中。现在的问题是，如果事件被取消或更改，我们就不能得到一个新的*.ics来被识别为覆盖原始的。我们为事件分配一个唯一的UID并递增序列字段，但我不知道规范是否允许“发布”-ed事件来优雅地处理更新(日期、时间、位置、描述等)。

更新2

好的，我刚刚在实验来自等级库的示例等级库文件。使用4.1.1“最小发布事件”和4.1.2“更改发布事件”中的示例，我将发送我认为符合规范的发布事件，以及随后的更新。Outlook 2010和GMail都认为更新是一个新事件。因此，在这一点上，我将假设Outlook和GMail只部分支持*.ics文件，放弃优雅的更新，并简单地指示用户删除他们的旧日历约会，如果我向他们发送一个新的日历约会。

Answer 1

iCalendar格式还指定了方法:发布(参见https://www.rfc-editor.org/rfc/rfc5546#section-3.2.1)。还不清楚您是否尝试过使用方法：.ics文件发布(没有与会者属性)。