[calsify] Re: Question about organizerCalendarAddress in JSCalendar bis

[Robert Stepanek <[e-mail]>]

On Fri, Sep 12, 2025, at 7:54 AM, Neil Jenkins wrote:
> On Mon, 1 Sep 2025, at 18:41, Mauro De Gennaro wrote:
>> However, since organizerCalendarAddress maps directly to ORGANIZER in iCalendar, and the "owner" role really comes from JMAP for Calendars permissions, do you think it would make sense to remove "owner" from JSCalendar and instead document it under section 5.1 (“Additional JSCalendar properties”) in JMAP for Calendars alongside other permissions-related properties like mayInviteSelf and mayInviteOthers?
> 
> I don't think this is tied directly to JMAP, and it's better to keep the "owner" definition with the other possible values in the main document.

I am not convinced anymore that the current guidance in draft-ietf-calext-jscalendar-icalendar-18 for the JSCalendar "owner" and "attendee" roles is sound. We should either define how to convert them to a standard iCalendar element, or instead they should become reserve them for JMAP for Calendars, just as we did for all the other scheduling properties of RFC 8984 that do not cleanly map to iCalendar scheduling.

Defining a standard element for the "owner" role should be straight-forward as long as the role is only informational, e.g. if it's just a way for the organizer to state to attendees who "owns" the event. In this case, we could register a new OWNER participation role value at IANA (see https://www.iana.org/assignments/icalendar/icalendar.xhtml#participation-roles) That aligns with RFC 5446 (iTIP) which states in section 1.3:

Note that "ROLE" is also a descriptive parameter to the iCalendar
   "ATTENDEE" property.  Its use is to convey descriptive context about
   an "Attendee" -- such as "chair", "required participant", or "non-
   required participant" -- and has nothing to do with the calendaring
   workflow.

I have not tested yet how existing iCalendar implementations deal with new ROLE parameter values, but its ABNF allows extension values: https://www.rfc-editor.org/rfc/rfc5545.html#section-3.2.16. I optimistically expect existing implementations to not care and ignore the unknown ROLE value.

If the "owner" role instead is something that requires enforcement - and the language in the JMAP for Calendars spec suggests that - then preserving it in iCalendar either as a ROLE parameter or JSPROP property is not a good idea. The role value should then rather be reserved for JMAP and only become a standard JSCalendar element when its clear how it relates to iTIP and how to deal with implementations that don't enforce it.

In any case we should update the jscalendarbis I-D to state if at least one participant in an event must have the "owner" role. The current I-D does not mention it either way,

For the "attendee" role I am starting to think to remove it entirely. There is no equivalent in iCalendar and in lack of any other role, it seems obvious that a participant in an event is "is expected to be present at the event".