[MlMt] RSVP/respond to ical/.ics calendar invite?

[Bill Cole]

On 19 Oct 2017, at 13:28 (-0400), Max Rydahl Andersen wrote:

> I just realised I could really use this feature (having remark) as 
> busycal don't support putting remarks on invites.

It is common practice for the iCalendar "DESCRIPTION" attribute to be 
either presented as inline "body" text of an invite message OR to be 
replicated as a text/plain part, a sibling to the text/calendar part in 
a multipart/{mixed,alternative,related} container. Sometimes the 
text/plain part (or the displayed "body" text in lieu of a text/plain 
part) will also include user-friendly forms of other attributes of the 
iCalendar object (which is a text structure that's like a hybrid between 
a classical EDI object and a NeXT-style property list) in addition to 
DESCRIPTION, such as the time fields (DTSTART and DTEND) and ATTENDEE 
fields. Or not.

Unfortunately, the vast wiggle room in the above description means that 
there is literally no way to create a message which includes an 
iCalendar object of any sort which will be presented consistently by all 
iCalendar-aware or all iCalendar-ignorant but MIME-aware mail clients. 
The relevant specifications (RFC5545, 5546, 6047 and others) claim to be 
"Standard Track" but in the real world they are at best described as 
"Informational" or even "Experimental." In principle, calendaring via 
email (RFC6047) specifically requires S/MIME signing of all iCalendar 
objects, so very few clients are always compliant and some cannot be 
compliant because they only can sign whole messages but always generate 
multipart containers for calendaring. Making everything so much better, 
there is no clear consensus on whether calendar user agents, mail user 
agents, or integrated mail/calendar servers should do the actual 
generation and/or initial submission of messages and there have been 2 
different proposed extensions to CalDAV to implement server-side 
generation of messages such that a CalDAV client (e.g. Calendar.app or 
BusyCal) might not understand a CalDAV server that advertises itself as 
implementing one or the other and send out duplicate invitations and/or 
updates to events. Ooops, that's not what "better" means, is it...

Last I looked, even Apple had given up trying to do anything like 
RFC6047 with iCloud.