DKIM2-Signature: i=1; m=1; t=1790893285; d=fastmailteam.com;
	mf=PG5laWxqQGZhc3RtYWlsdGVhbS5jb20+; rt=PGptYXBAaWV0Zi5vcmc+;
	s=fm2:rsa-sha256:IYySRc3W09yywYsPEsVgVzEsdsgBh4M9H5y5UTIJw7QLOsf
	fXluyeJs3jFFqeYqR6WNSAxQTXh4X+koqFuJt+yw5VrZU1nwnvHSf8CeiQkQwLl7
	9UBoAbHpC3O8H4DN7Iw2ZhRVqn9aaUHUQz1SqzSXIFmOAU+iFNM9Fc2BXQnwtEDb
	Uqd4XAHPAywBVwn0gN1X/uN+d1375yMqtBDk9xq9IrXHLFtTZ+GYqjZMmruY3Q8T
	bXFThnAGXeQ6GT4DeIXAySFnpRo6lf2DSXVjTOEFB3JdmqbX6L/KeoYhHkJexaUY
	2eKrV8RjlP9ubVEqSP7vhywj2Z8un26KMArQdJQ==;
Message-Instance: m=1;
 h=sha256:ad1sftG8MCY9DfXgM0pE3lm4pqiUAJtDFsIJT6wViRc=:clUhJmFojh9MBZ4oFE96PLnM3MizlXaK9Qj56KAgZ5Y=;
Feedback-ID: ibc614277:Fastmail
MIME-Version: 1.0
Date: Fri, 02 Oct 2026 08:20:21 +1000
From: "Neil Jenkins" <neilj@fastmailteam.com>
To: "Ben Bucksch" <ben.bucksch@beonex.com>, "CalExt IETF" <calsify@ietf.org>,
 "JMAP IETF" <jmap@ietf.org>
Message-Id: <5424bfce-2e8d-4ee8-bf0c-542550fc1533@app.dogfood.fastmail.com>
In-Reply-To: <6df1ca2c-b286-7355-8f20-bc4eaccd41b8@beonex.com>
References: <0b37c64c-f38e-4b50-9611-94f20165bbea@app.fastmail.com>
 <6df1ca2c-b286-7355-8f20-bc4eaccd41b8@beonex.com>
Content-Type: multipart/alternative;
 boundary=ec6e04a32fd24ff4bda0e6f3b274284103e36dc8
Message-ID-Hash: LYLO2S36DOUBQKWWCTGO6ZMVU5C5HHEU
Precedence: list
Subject: [JMAP] Re: WGLC: please review the final state of the JSCalendar/JMAP
 Calendars drafts
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/jmap/W2U-RvZ9fSGgfZteWHGkuNUfXZw>

--ec6e04a32fd24ff4bda0e6f3b274284103e36dc8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

(Posting this again, as I forgot to include the calext list as well last=
 time; apologies for the duplication for those on JMAP list too.)

On Sat, 26 Sep 2026, at 06:35, Ben Bucksch wrote:
> However, the concern from last year regarding who processes the incomi=
ng invitation and who adds the event to the calendar is still open. The =
spec does not clearly define whether it's the client or server

I don't believe *this* spec needs to say anything about this. Clients th=
at handle mail as well as calendars should just compare the state of the=
 event on the server with the iTIP message they have. If the server upda=
ted the calendar automatically, the change will already have been applie=
d (the "sequence" number will be > than that in the iTIP message, or the=
 "updated" time will be >=3D that in the iTIP message if the sequence nu=
mbers are the same). If the server hasn't applied it, the client can off=
er to update the calendar if the user chooses.

Any deep change to scheduling should be a separate document (and we coul=
d do so much better =E2=80=94 I'd love to move away from using emails to=
 distribute anything beyond the initial invitation to an event; after th=
at, we should use a per-event web hook to push updates to all participan=
ts securely and reliably). But that's a whole separate thing.

Regards,
Neil
--ec6e04a32fd24ff4bda0e6f3b274284103e36dc8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>(Posting thi=
s again, as I forgot to include the calext list as well last time; apolo=
gies for the duplication for those on JMAP list too.)</div><div><br></di=
v><div>On Sat, 26 Sep 2026, at 06:35, Ben Bucksch wrote:</div><blockquot=
e type=3D"cite"><div>However, the concern from last year regarding who p=
rocesses the incoming invitation and who adds the event to the calendar =
is still open. The spec does not clearly define whether it's the client =
or server</div></blockquote><div><br></div><div>I don't believe <i>this<=
/i> spec needs to say anything about this. Clients that handle mail as w=
ell as calendars should just compare the state of the event on the serve=
r with the iTIP message they have. If the server updated the calendar au=
tomatically, the change will already have been applied (the "sequence" n=
umber will be &gt; than that in the iTIP message, or the "updated" time =
will be &gt;=3D that in the iTIP message if the sequence numbers are the=
 same). If the server hasn't applied it, the client can offer to update =
the calendar if the user chooses.</div><div><br></div><div>Any deep chan=
ge to scheduling should be a separate document (and we could do so much =
better =E2=80=94 I'd love to move away from using emails to distribute a=
nything beyond the initial invitation to an event; after that, we should=
 use a per-event web hook to push updates to all participants securely a=
nd reliably). But that's a whole separate thing.</div><div><br></div><di=
v>Regards,</div><div>Neil<br></div></body></html>
--ec6e04a32fd24ff4bda0e6f3b274284103e36dc8--