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.
_______________________________________________ mailmate mailing list [email protected] https://lists.freron.com/listinfo/mailmate
