Subject: [calsify] JSCalendar and iCalendar scheduling

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 15 Mar 2021 11:56:40 +0100

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.

---

From: Michael Douglass <[email-masked]>
Date: Mon, 15 Mar 2021 22:46:50 -0400

On 3/15/21 06:56, Robert Stepanek wrote:
> 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.
>
> 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.
>
> 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).
REPLY only allows one attendee. Delegation is carried out with REQUEST 
and REPLY
>
> 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.

This all seems very complicated. We've gone from a reasonably simple 
model in which the value of the ATTENDEE uniquely and reliably 
identifies the attendee throughout the sequence of messages to something 
which combines internal key values (participant ids) and a mix of keys 
for the participant itself.

The reason I proposed a calendarUserAddress property was simplicity - 
it's a 1-1 mapping with the ATTENDEE value and can be used as a key for 
the delegated..., invitedBy etc.

I'm fine not having that property IF we can come up with another way of 
clearly providing a single key for an attendee/participant.

I don't think this is just about icalendar<->jscalendar translation. We 
need to ensure that we can carry out current scheduling operations even 
if they are completely done in jscalendar.

>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: "Robert Stepanek" <[email-masked]>
Date: Tue, 16 Mar 2021 10:01:25 +0100

> REPLY only allows one attendee. Delegation is carried out with REQUEST and REPLY

This is going on a tangent, but: RFC 5546 seems to contradict itself.

Section 3.2.3 states that the ATTENDEE property in a REPLY must be present exactly once.
Section 4.2.5 states that the the delegator must send a REPLY to the organizer with their own ATTENDEE and an additional ATTENDEE for the delegate.
The errata does not clarify which section is right.

>  This all seems very complicated. We've gone from a reasonably simple model in which the value of the ATTENDEE uniquely and reliably identifies the attendee throughout the sequence of messages to something which combines internal key values (participant ids) and a mix of keys for the participant itself.
> The reason I proposed a calendarUserAddress property was simplicity - it's a 1-1 mapping with the ATTENDEE value and can be used as a key for the delegated..., invitedBy etc. 

> I'm fine not having that property IF we can come up with another way of clearly providing a single key for an attendee/participant.

I am not sure if you just ask for an opaque id for each participant that's guaranteed to be the same for all sequences of the event. Or if you also expect this id to be used to determine where to send the iTIP message to. In iCalendar these two are conflated in the ATTENDEE property value. But in JSCalendar the sendTo property allows to define multiple scheduling methods, so it separates the participant identifier from the scheduling method. Would a calendarUserAddress replace the sendTo property, which means we abandon the idea of multiple iTIP methods?

> I don't think this is just about icalendar<->jscalendar translation. We need to ensure that we can carry out current scheduling operations even if they are completely done in jscalendar. 

Absolutely, this is what I aimed for with my proposal and it might still have its flaws.  Did you identify a scheduling operation which the current proposal does not support?

---

From: Michael Douglass <[email-masked]>
Date: Fri, 26 Mar 2021 13:17:15 -0400

On 3/16/21 05:01, Robert Stepanek wrote:
> Section 4.2.5 states that the the delegator must send a REPLY to the 
> organizer with their own ATTENDEE and an additional ATTENDEE for the 
> delegate.

We should probably file an errata on this one - they are inconsistent, I 
think the table should say 1 attendee or 2 if delegating.