Subject: [calsify] Request for adoption: draft-gondwana-caldav-scheduling-controls

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 08 Mar 2019 07:07:50 -0500

It's a bit cheeky asking this as a recent chair myself, but I had started work on this document as a purely FastMail suggestion, and during discussion at CalConnect last month in Zurich it came up that Google had done much the same thing themselves to handle bulk import, so I ran the idea past Lucia and put this draft together.

There's still some work to do, and I'm happy to hand over authorship to somebody else if anyone wants it, or to continue working on it myself. I've renamed things to be a bit more consistent than our implementation at FastMail, but of course we'd update to match the standard once the spec is done.

https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/

(still plenty of work to do on it, but the bones are there)

I believe this is within the scope of this group's existing charter and would like to see it adopted.

Regards,

Bron.

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [email-masked]

---

From: Дилян Палаузов <[email-masked]>
Date: Fri, 08 Mar 2019 19:00:01 +0000

Hello Bron,

irrespective of the WG-addoptation, CALDAV:calendar-user-address-set (https://tools.ietf.org/html/rfc6638#section-2.4.1)
defines per principal all the aliases a user has, so the server does not have to guess anything.

When the Schedule-User-Address header is skipped, your draft says, that the CALDAV:schedule-user-address property on a
calendar or user/principal shall be used.  The draft references only RFC6638 “Scheduling Extensions to CalDAV” and the
latter does not say anything about CALDAV:schedule-user-address.  Where is CALDAV:schedule-user-address defined?

Are CALDAV:schedule-user-address and CALDAV:calendar-user-address-set supposed to mean the same?

In any case, it would be good to be able to specify several addresses in the Schedule-User-Address header: an invitation
having Organizer and Attendee, where the same person is both the organizer and the attendee, but uses different
addresses for both, is supposed not to trigger any scheduling to the same person.  This assumes that the system can
match the addresses as Attendee and Organizer belonging to the same person and both addresses could arrive as headers.

Section 7:
The "Scheduling" header only allows reduction of the cases in which the server will ??? creating scheduling requests.

Regards
  Дилян

What is the difference between Scheduling: NO and 
On Fri, 2019-03-08 at 07:07 -0500, Bron Gondwana wrote:
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Michael Douglass <[email-masked]>
Date: Fri, 8 Mar 2019 15:38:37 -0500

Cyrus wrote a spec for bulk import/updates

https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml

I have the impression it's used but not certain.

The spec says nothing about scheduling.

On 3/8/19 07:07, Bron Gondwana wrote:
> It's a bit cheeky asking this as a recent chair myself, but I had 
> started work on this document as a purely FastMail suggestion, and 
> during discussion at CalConnect last month in Zurich it came up that 
> Google had done much the same thing themselves to handle bulk import, 
> so I ran the idea past Lucia and put this draft together.
>
> There's still some work to do, and I'm happy to hand over authorship 
> to somebody else if anyone wants it, or to continue working on it 
> myself.  I've renamed things to be a bit more consistent than our 
> implementation at FastMail, but of course we'd update to match the 
> standard once the spec is done.
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Sat, 23 Mar 2019 06:29:47 -0400

> Are CALDAV:schedule-user-address and CALDAV:calendar-user-address-set supposed to mean the same?

Yes - I expect that was an early mistake that I just didn't notice. Oops. I'll fix that up in the next one.

> match the addresses as Attendee and Organizer belonging to the same person and both addresses could arrive as headers.

The server will always have you acting as a particular user when you're updating the record - but yeah, to avoid scheduling to multiple addresses makes sense. This will also be something interesting to discuss in JMAP calendars.

Bron.

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 26 Mar 2019 05:54:08 -0400

Thanks Mike - sorry about the delay in replying.

Do you think we should progress bulk-change as a separate document, or merge it into scheduling controls?

Ken implemented it in the Cyrus IMAPd server, but we aren't using it ourselves. I guess you could "bulk update" a single item to avoid scheduling as an alternative method.

Bron.

calsify mailing list

---

From: Ken Murchison <[email-masked]>
Date: Tue, 26 Mar 2019 07:16:34 -0400

To clarify, I implemented bulk import only.  I haven't implemented bulk 
update.

On 3/26/19 5:54 AM, Bron Gondwana wrote:
> Ken implemented it in the Cyrus IMAPd server, but we aren't using it 
> ourselves.  I guess you could "bulk update" a single item to avoid 
> scheduling as an alternative method.
>
> Bron.
>
>>> Google had done much the same thing themselves to handle bulk 
>>> import, so I ran the idea past Lucia and put this draft together.
>>>
>>> [email-masked] <mailto:[email-masked]>
>>>
>>>
>>>
>>> [email-masked]  <mailto:[email-masked]>

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Michael Douglass <[email-masked]>
Date: Tue, 26 Mar 2019 12:39:14 -0400

I think it probably would bear some investigation.

I suspect the bulk import would work better for the special cases you 
mentioned.

My recollection is that you get some sort of per record status and that 
would be helpful.

Maybe we should talk about this - I see some other less importy uses - 
for example updating a whole bunch of related resources. That gets very 
messy if it has to be done as a bunch of requests and one of them fails.

On 3/26/19 07:16, Ken Murchison wrote:
>
> To clarify, I implemented bulk import only.  I haven't implemented 
> bulk update.
>
>
>>>> during discussion at CalConnect last month in Zurich it came up 
>>>> that Google had done much the same thing themselves to handle bulk 
>>>> There's still some work to do, and I'm happy to hand over 
>>>> authorship to somebody else if anyone wants it, or to continue 
>>>> working on it myself. I've renamed things to be a bit more 
>>>> consistent than our implementation at FastMail, but of course we'd 
>>>> update to match the standard once the spec is done.
>>>>

---

From: Ken Murchison <[email-masked]>
Date: Tue, 26 Mar 2019 12:41:24 -0400

On 3/26/19 12:39 PM, Michael Douglass wrote:
> My recollection is that you get some sort of per record status and 
> that would be helpful.
>

Yes, bulk import as defined in the Daboo draft uses a 207 (Multi-status) 
response.

> for example updating a whole bunch of related resources. That gets 
> very messy if it has to be done as a bunch of requests and one of them 
> fails.
>
>>>>> I believe this is within the scope of this group's existing 
>>>>> charter and would like to see it adopted.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Bron.
>>>>>
>>>>> --

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC