Feedback-ID: ia5d944da:Fastmail
MIME-Version: 1.0
Date: Tue, 07 Oct 2025 09:19:48 +0200
From: "Robert Stepanek" <rsto@fastmailteam.com>
To: calsify@ietf.org
Message-Id: <c5c80aa9-7f4b-4be5-b1e8-ffbcb4193ff3@app.fastmail.com>
In-Reply-To: <0851af7a-73e6-4e65-ab90-10fa32b3a9af@dogfoodapp.fastmail.com>
References: <FCD2E6CD-63E5-4E9E-AE36-B3755E4E9060@stalw.art>
 <f64ae60a-64df-4ddd-958f-2b69ae36efc0@dogfoodapp.fastmail.com>
 <B0709D29-A239-432F-B382-ABF66F404958@stalw.art>
 <0851af7a-73e6-4e65-ab90-10fa32b3a9af@dogfoodapp.fastmail.com>
Content-Type: multipart/alternative;
 boundary=969c21a0cc2746049dbe551c50df5fe6
Message-ID-Hash: C75NGJ75TRQ7YYKFCHKGCCUEZYJY3OM7
Precedence: list
Subject: =?utf-8?q?=5Bcalsify=5D_Re=3A_Question_about_organizerCalendarAddress_in_JSC?=
	=?utf-8?q?alendar_bis?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/calsify/ek8HEIS0QEMdeoMoqOd4GPLjmKs>

--969c21a0cc2746049dbe551c50df5fe6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 pe=
rmissions, do you think it would make sense to remove "owner" from JSCal=
endar and instead document it under section 5.1 (=E2=80=9CAdditional JSC=
alendar properties=E2=80=9D) in JMAP for Calendars alongside other permi=
ssions-related properties like mayInviteSelf and mayInviteOthers?
>=20
> I don't think this is tied directly to JMAP, and it's better to keep t=
he "owner" definition with the other possible values in the main documen=
t.

I am not convinced anymore that the current guidance in draft-ietf-calex=
t-jscalendar-icalendar-18 for the JSCalendar "owner" and "attendee" role=
s is sound. We should either define how to convert them to a standard iC=
alendar element, or instead they should become reserve them for JMAP for=
 Calendars, just as we did for all the other scheduling properties of RF=
C 8984 that do not cleanly map to iCalendar scheduling.

Defining a standard element for the "owner" role should be straight-forw=
ard as long as the role is only informational, e.g. if it's just a way f=
or the organizer to state to attendees who "owns" the event. In this cas=
e, we could register a new OWNER participation role value at IANA (see h=
ttps://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 n=
ew ROLE parameter values, but its ABNF allows extension values: https://=
www.rfc-editor.org/rfc/rfc5545.html#section-3.2.16. I optimistically exp=
ect existing implementations to not care and ignore the unknown ROLE val=
ue.

If the "owner" role instead is something that requires enforcement - and=
 the language in the JMAP for Calendars spec suggests that - then preser=
ving it in iCalendar either as a ROLE parameter or JSPROP property is no=
t a good idea. The role value should then rather be reserved for JMAP an=
d only become a standard JSCalendar element when its clear how it relate=
s 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. Th=
ere is no equivalent in iCalendar and in lack of any other role, it seem=
s obvious that a participant in an event is "is expected to be present a=
t the event".
--969c21a0cc2746049dbe551c50df5fe6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Fri, Sep =
12, 2025, at 7:54 AM, Neil Jenkins wrote:</div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><div>On Mon, 1 Sep 2025, at 18:41, Mauro De Gennar=
o wrote:</div><blockquote type=3D"cite" id=3D"qt-qt" style=3D"overflow-w=
rap:break-word;"><div>However, since organizerCalendarAddress maps direc=
tly to ORGANIZER in iCalendar, and the "owner" role really comes from JM=
AP for Calendars permissions, do you think it would make sense to remove=
 "owner" from JSCalendar and instead document it under section 5.1 (=E2=80=
=9CAdditional JSCalendar properties=E2=80=9D) in JMAP for Calendars alon=
gside other permissions-related properties like mayInviteSelf and mayInv=
iteOthers?</div></blockquote><div><br></div><div>I don't think this is t=
ied directly to JMAP, and it's better to keep the "owner" definition wit=
h the other possible values in the main document.</div></blockquote><div=
><br></div><div>I am not convinced anymore that the current guidance in&=
nbsp;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 rese=
rve them for JMAP for Calendars, just as we did for all the other schedu=
ling properties of RFC 8984 that do not cleanly map to iCalendar schedul=
ing.</div><div><br></div><div>Defining a standard element for the "owner=
" role should be straight-forward as long as the role is only informatio=
nal, 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 participa=
tion role value at IANA (see&nbsp;<a href=3D"https://www.iana.org/assign=
ments/icalendar/icalendar.xhtml#participation-roles">https://www.iana.or=
g/assignments/icalendar/icalendar.xhtml#participation-roles</a>). That a=
ligns with RFC 5446 (iTIP) which states in section 1.3:</div><div><br></=
div><pre style=3D"border-top-width:1px;border-top-style:solid;border-top=
-color:rgb(204, 204, 204);border-right-width:1px;border-right-style:soli=
d;border-right-color:rgb(204, 204, 204);border-bottom-width:1px;border-b=
ottom-style:solid;border-bottom-color:rgb(204, 204, 204);border-left-wid=
th:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);bord=
er-image-outset:0;border-image-repeat:stretch;border-image-slice:100%;bo=
rder-image-source:none;border-image-width:1;border-top-left-radius:3px;b=
order-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-=
left-radius:3px;background-color:rgb(246, 246, 246);background-position-=
x:0%;background-position-y:0%;background-repeat:repeat;background-attach=
ment:scroll;background-image:none;background-size:auto;background-origin=
:padding-box;background-clip:border-box;font-family:menlo, consolas, mon=
ospace;font-size:90%;margin-top:7px;margin-right:0px;margin-bottom:7px;m=
argin-left:0px;padding-top:7px;padding-right:10px;padding-bottom:7px;pad=
ding-left:10px;text-wrap-mode:wrap;white-space-collapse:preserve;overflo=
w-wrap:break-word;">Note that "ROLE" is also a descriptive parameter to =
the iCalendar=0A   "ATTENDEE" property.  Its use is to convey descriptiv=
e context about=0A   an "Attendee" -- such as "chair", "required partici=
pant", or "non-=0A   required participant" -- and has nothing to do with=
 the calendaring=0A   workflow.</pre><div><br></div><div>I have not test=
ed yet how existing iCalendar implementations deal with new ROLE paramet=
er values, but its ABNF allows extension values:&nbsp;<a href=3D"https:/=
/www.rfc-editor.org/rfc/rfc5545.html#section-3.2.16">https://www.rfc-edi=
tor.org/rfc/rfc5545.html#section-3.2.16</a>. I optimistically expect exi=
sting implementations to not care and ignore the unknown ROLE value.</di=
v><div><br></div><div>If the "owner" role instead is something that requ=
ires enforcement - and the language in the JMAP for Calendars spec sugge=
sts 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 b=
e reserved for JMAP and only become a standard JSCalendar element when i=
ts clear how it relates to iTIP and how to deal with implementations tha=
t don't enforce it.</div><div><br></div><div>In any case we should updat=
e 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,</div><div><br></div><div>For the "attendee" role I am starting to t=
hink to remove it entirely. There is no equivalent in iCalendar and in l=
ack of any other role, it seems obvious that a participant in an event i=
s "is expected to be present at the event".</div></body></html>
--969c21a0cc2746049dbe551c50df5fe6--