Re: [calsify] JSCalendar and iCalendar scheduling

[Robert Stepanek <[e-mail]>]

On Tue, Mar 16, 2021, at 3:46 AM, Michael Douglass wrote:
> On 3/15/21 06:56, Robert Stepanek wrote:

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

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?