Re: [Jmap] [JMAP] CalendarEvent/parse proposition for the JMAP Calendar draft

[Robert Stepanek <[e-mail]>]

Hi,

I'm much in favor of adding CalendarEvent/parse as an optional method to JMAP Calendars. Just as Email/parse parses MIME messages, CalendarEvent/parse should parse iCalendar data. Should there ever be the need to support other calendar formats, this still could be solved with a `contentType` argument.

On Wed, Apr 12, 2023, at 9:26 AM, René CORDIER wrote:
> At Linagora we have an internal need of showing what we call a blue bar on top of Calendar event emails that you receive. It would allow the client to show the user details of a Calendar event he received in a nice and generic way when reading the corresponding email (because Calendar email sent events are not formatted the same way depending of the calendar).
> 
> We came up with a custom method called CalendarEvent/parse. It would allow to parse a .ics calendar file attached to the mail to extract properties defined in RFC5545 to allow client to show events from different calendars in the same way. 
> 

At Fastmail and in the Cyrus IMAP server we support this use case with a non-standard `calendarEvents` property in the `Email` object. Any MIME body parts of type text/calendar will be rendered as JSCalendar events to this property in Email/get.

The Cyrus IMAP server also already supports `CalendarEvent/parse` if you use the `https://cyrusimap.org/ns/jmap/calendars` capability.

> For more details, we have a document that defines our custom method here: https://github.com/linagora/tmail-backend/blob/master/docs/modules/ROOT/pages/tmail-backend/jmap-extensions/calendarEventParsing.adoc
> 

I guess we will have more discussions about this should this get defined in JMAP Calendars but here are my remarks already (in no particular order):

 • +1 for using the applicable subsets of arguments of Email/parse. But I do think that a standard CalendarEvent/parse also needs to support the `properties` argument, rather than hard-coding in the spec the list of returned properties.
 • Is there a reason why use you use different value type notations than the JMAP spec? e.g. your `blobIds: [Id]` definition would read `blobIds: Id[]` in standard JMAP notation. Similarly, `parsed: Map[BlobId]` notates that the value type of `parsed` is a JSON objects with keys of type `Map` (some subset of String) and values of type `BlobId`. But that's not what your example shows.
 • Your example shows that the parsed property maps a `blobId` to a single `CalendarEvent`. This will not work in the general case, as a blob with iCalendar data may contain multiple VEVENT components which do not parse to a single CalendarEvent. The most common scenario where we see that happening is for iTIP messages that contain two or more VEVENTs with the same UID and all of them having a RECURRENCE-ID. I suggest you change the value of parsed to a map of list of events, such as  `parsed: Id[CalendarEvent[]]`.
 • I see that you document how to convert iCalendar properties to JSCalendar event properties. I guess that's on me, because we still did not manage to publish our RFC draft that standardizes how convert between the two formats: https://www.ietf.org/archive/id/draft-ietf-calext-jscalendar-icalendar-07.html For JMAP Calendars, I definitely would be against different a conversion scheme as part of CalendarEvent/parse and rather refer to the conversion guide RFC.

Thanks!
Robert