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

[René CORDIER <[e-mail]>]

Hi Robert,

Thanks for taking the time to read it and give your feedback !

I will answer inline.

Best regards,

Rene.

On Apr 12, 2023 3:08 PM, from Robert Stepanek 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.+1


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.Good to know you are using something similar internally, it means there is clearly a common need for such a method then I believe.


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.

Agreed that to standardize the method, the properties argument should be supported.


 - 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.

As said, some changes will be necessary to formalize this document to the RFC style. So this comment makes sense in this regard, thanks!


 - 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[]].

+1, thanks for the clarification


 - 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.

Good to know, thanks for the ref, we will take the time to check it !


Thanks!
Robert
_______________________________________________
Jmap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jmap