[calsify] JSCalendar and iCalendar scheduling

[Robert Stepanek <[e-mail]>]

Before we publish draft-ietf-calext-jscalendar we want to be extra sure that both JSCalendar and iCalendar interoperate cleanly in scheduling. We discussed this in IETF 110 last week and I would like to now present a proposal that should address all raised concerns. Please let me know your feedback so that we can find consensus on this topic.

*ATTENDEE property value and Participant.sendTo*

The property value of an ATTENDEE maps to a single-valued sendTo property of a JSCalendar Participant. The method of the sendTo property value is determined by the URI scheme: a `mailto:` URI maps to to the `imip` method, any other URI scheme (or none) to `other`.

A sendTo property with only a single method maps to the ATTENDEE property value, irrespective of the method type. If the sendTo property has both `imip` and `other` entries, then the default is to map the `imip` method value to the ATTENDEE property value. The `other` entry is preserved by a (to be defined) iCalendar parameter. To override this heuristic, the calext-jscalendar-icalendar RFC will register a new Participant property that allows to explicitly state which method to use when mapping the ATTENDEE property value.

*EMAIL parameter and Participant.email*

The iCalendar EMAIL parameter maps to the email property of the Participant. If no EMAIL parameter is set then the email property is null, even if the iCalendar property value is a `mailto:` URI. Likewise, only the Participant email property maps to the EMAIL parameter, the `imip` sendTo method value never maps to EMAIL.

An ORGANIZER always maps to the replyTo property. if the ORGANIZER also has an EMAIL parameter then it also maps to a Participant, with the `email` property set and the role set to `owner`. Likewise if the ORGANIZER has a CN parameter.

*Participants and iTIP*

For iCalendar, the cardinality of ATTENDEE properties in a iTIP message is well defined. For example, a REPLY message must include exactly one ATTENDEE (except for delegating events).

For JSCalendar, a REPLY may contain multiple participants. One for the replying participant, and additional participants for any participants identified in the sentBy, invitedBy, delegatedFrom, delegatedTo and memberOf properties. To simply identify the originator of the iTIP message sender, either the calext-jscalendar-icalendar RFC or the calext-jscalendar RFC will define a new top-level property that defines the originating participant identifier. This property must only be set for iTIP messages.

A replying participant may need to define new participants (e.g. for a new delegate). It must choose an unused participant identifier for each new entry. The organizer of the event may need to resolve duplicate participant ids from multiple replies and may assign new participant ids. Consequently, clients must be prepared to deal with new participant ids for each sequence of an event.