Re: [calsify] draft-ietf-calext-jscalendar and participants

[Neil Jenkins <[e-mail]>]

On Wed, 17 Feb 2021, at 04:17, Robert Stepanek wrote:
>> For example I might have an ATTENDEE that looks like
>> ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHAIR;EMAIL=[e-mail]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOhcljjCSqMYrUXDcs6f1z7CyXejTR/principal/
> The difference is that the participant id has no meaning outside a single JSEvent. But a calendar user address is an identifier for an entity across events.
> 
> It allows for unambigously mapping the ATTENDEE or ORGANIZER property value to JSCalendar and reverse. It's not clear from a multi-valued sendTo property which one should be used as the property value.

My reading of the current RFCs, although I think they are not super clear, is that the calendar user address is the only "sendTo" method. An email may be specified in addition but this is not intended as an iMIP destination (so would not be in the JSCalendar sendTo, just the participant's email property). Is your interpretation that the calendar user address is more like a uid? If so, can you use it for anything other than as an opaque token for equality comparison?

> There is one other benefit of making more use of calendar user addresses in JSCalendar: the DELEGATED-FROM, DELEGATED-TO, MEMBER-OF, SENT-BY parameters all use calendar user addresses. But in JSCalendar we use participant ids for these properties. If a DELEGATED-FROM calendar user address has no ATTENDEE in iCalendar, we would need to create an artificial participant in JSCalendar. This participant could have an "informational" role, expectReply=false, because it's really not a participant. When mapping back to iCalendar we would need to figure out if to create an ATTENDEE for that. When we use calendar user addresses rather than participant ids for these properties then there is no ambiguity.

It seems a bit weird to me that you would have unresolvable identifiers like this (they don't seem particularly useful). I'd also say that you'd be making the JSCalendar object more awkward to work with (you'd have to linearly scan or build a separate index to get from one of these pointers to the participant it refers to). I would generally say a slightly more cumbersome translation is preferable to all objects in the new format being harder to use.

Neil.