Produce an iCal appointment and subsequent updates via email but don't offer accept/decline options

Question

We are writing a system that has a booking feature, and we are planning to have it send *.ics files via email to attendees so they can easily add appointments to their calendars. The types of events are things like training courses (e.g. 3pm in the boardroom).

We've got this working to the point that the system sends the *.ics, and using Gmail and Outlook, the user can accept the appointment which, is then added to their calendar.

Sometimes an event changes (e.g. a course is cancelled or delayed until the following day). Our software can send out a new *.ics file, and Gmail/Outlook correctly recognize that this is an update to the original appointment and gives the option to accept/decline again.

The trouble is, we don't have a mechanism to receive via email the accept/decline responses that standard email clients automatically send when the user accepts/declines an appointment. Therefore, clicking the "decline" option could give them the false sense that they have cancelled the appointment when in fact our system has no idea what they've done within their calendar.

We always want the bookings to be instigated by the user directly on the website, and the *.ics via email is merely a convenience to help them remember to attend. Similar to a flight booking, if the passenger really intends to cancel, something a little more definitive is required than clicking "decline" in Outlook. With a few flight bookings I've made, the carrier sent me a *.vcs file which contains "METHOD:PUBLISH" instead of "METHOD:REQUEST" which sounds closer to what we want, although in testing, this *.vcs file was not recognized by GMail as an appointment.

So the question is, can we email appointments, with subsequent updates, that will be automatically be recognized by Outlook, GMail & Lotus Notes, but prevent the user from thinking they can cancel/decline the entire booking from within their own calendar tool? If so, how?

UPDATE 1

I think I found the issue with the METHOD:PUBLISH airline booking example I was experimenting with - it was for a past date. Using a future date, We can now use METHOD:PUBLISH to allow people to add events to their calendar without requiring accept/decline. Problem now is that if the event is cancelled or changed, we cannot get a new *.ics to be recognized as overriding the original. We are allocating a unique UID and incrementing the SEQUENCE field to the event, but I don't know whether the spec allows a "PUBLISH"-ed event to elegantly handle updates (date, time, location, description etc.)

UPDATE 2

Okay, well I've just been experimenting with the sample *.ics files from the spec. Using the examples from 4.1.1 "A Minimal Published Event" and 4.1.2 "Changing a Published Event" I am sending what I believe is a spec-compliant published event, and subsequent update. Both Outlook 2010 and GMail see the update as a NEW EVENT. So at this point I'm going to assume Outlook and GMail have only partial support for *.ics files, give up on elegant updates and simply instruct the user to delete their old calendar appointment if I send them a new one.

Answer 1

The iCalendar format also specifies the METHOD:PUBLISH (see https://www.rfc-editor.org/rfc/rfc5546#section-3.2.1). It is not clear whether you have tried an .ics file with METHOD:PUBLISH (and no ATTENDEE property).