Re: [calsify] JSCalendar and iCalendar scheduling

[Michael Douglass <[e-mail]>]

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.
>
> *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).
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify