我们正在编写一个具有预订功能的系统，我们计划通过电子邮件将* .ics文件发送给与会者，以便他们可以轻松地将约会添加到他们的日历中。活动类型是培训课程（例如董事会下午3点）。
我们已将此工作发送到系统发送* .ics，并使用Gmail和Outlook，用户可以接受约会，然后将其添加到他们的日历中。
有时事件发生变化（例如，课程被取消或延迟到第二天）。我们的软件可以发送一个新的* .ics文件，Gmail / Outlook正确识别这是对原始约会的更新，并提供了再次接受/拒绝的选项。
问题是，我们没有通过电子邮件接收标准电子邮件客户端在用户接受/拒绝约会时自动发送的接受/拒绝响应的机制。因此，点击“拒绝”选项可能会让他们错误地认为他们取消了约会，而事实上我们的系统根本不知道他们在日历中做了什么。
我们总是希望用户直接在网站上发起预订，而* .ics通过电子邮件只是方便他们记住参加。与航班预订类似，如果乘客确实打算取消，则需要比在Outlook中单击“拒绝”更确定的内容。通过我做过的一些航班预订，运营商发给我一个* .vcs文件，其中包含“METHOD：PUBLISH”而不是“METHOD：REQUEST”，这听起来更接近我们想要的，尽管在测试中，这个* .vcs文件没有被GMail认可为预约。
所以问题是，我们可以通过电子邮件发送约会，以及随后的更新，这些约会将自动被Outlook，GMail＆amp; Lotus Notes，但阻止用户认为他们可以从他们自己的日历工具中取消/拒绝整个预订？如果是这样，怎么样？
更新1
我想我发现了METHOD的问题：我正在试验的PUBLISH航空公司预订示例 - 它是过去的日期。使用将来的日期，我们现在可以使用METHOD：PUBLISH来允许人们在不需要接受/拒绝的情况下将事件添加到他们的日历中。现在的问题是，如果事件被取消或更改，我们无法将新的* .ics识别为覆盖原始事件。我们正在分配一个唯一的UID并将SEQUENCE字段递增到事件，但我不知道规范是否允许“PUBLISH”-ed事件优雅地处理更新（日期，时间，位置，描述等）。
更新2
好吧，我刚刚试验了spec中的样本* .ics文件。使用4.1.1“最小发布事件”和4.1.2“更改已发布事件”中的示例我发送的内容是我认为符合规范的已发布事件以及后续更新。 Outlook 2010和GMail都将更新视为新事件。因此，在这一点上，我将假设Outlook和GMail仅部分支持* .ics文件，放弃优雅的更新，并简单地指示用户删除旧的日历约会，如果我发送新的日历约会。
答案 0 :(得分：1)
iCalendar格式还指定了METHOD：PUBLISH（参见http://tools.ietf.org/search/rfc5546#section-3.2.1）。目前尚不清楚您是否尝试过使用METHOD：PUBLISH（并且没有ATTENDEE属性）的.ics文件。