<!doctype html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<div>
Hi,
</div>
<blockquote type="cite">
Bron Gondwana <brong@fastmailteam.com> hat am 7. Juni 2018 um 18:29 geschrieben:
<br>
<br>
<div style="font-family: Arial;">
Please see attached a very early draft. I'd love feedback (particularly from those of you at CalConnect right now) on:
<br>
</div>
<div style="font-family: Arial;">
<br>
</div>
<div style="font-family: Arial;">
* how to tell the client that the server support this? (server-info?, OPTIONS?)
</div>
</blockquote>
<div>
I'd say OPTIONS, as support for the server-info document should not be a requirement here.
</div>
<blockquote type="cite">
<div style="font-family: Arial;">
* should this be two separate specs, or together?
</div>
</blockquote>
<div>
For me it rather feels like two separate topics.
</div>
<blockquote type="cite">
<div style="font-family: Arial;">
* should values for "Scheduling" header be case significant?
</div>
</blockquote>
<div>
No.
</div>
<div>
<br>
</div>
<div>
As addition, regarding the "Schedule-User-Address" header, I'm not sure if I got it right. Is it only required for the very special case when there are two or more attendees in an event that are also present in the "calendar-user-address-set" of the targeted collection's "calendar-owner"? Or are there also more common examples?
</div>
<div>
<br>
</div>
<div>
Tobias
</div>
<blockquote type="cite">
<div style="font-family: Arial;">
</div>
<div style="font-family: Arial;">
<br>
</div>
<div style="font-family: Arial;">
Thanks!
<br>
</div>
<div style="font-family: Arial;">
<br>
</div>
<div style="font-family: Arial;">
Bron.
<br>
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>
On Wed, Jun 6, 2018, at 14:37, Bron Gondwana wrote:
<br>
</div>
<blockquote type="cite">
<div style="font-family: Arial;">
<br>
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>
On Wed, Jun 6, 2018, at 08:56, Helge Heß wrote:
<br>
</div>
<blockquote type="cite">
<blockquote>
<div>
# Scheduling-Enabled header
<br>
</div>
</blockquote>
<div>
<br>
</div>
<div>
I wanted to have that thing for a looong time.
<br>
</div>
<div>
<br>
</div>
<div>
I don’t like the header a lot, I’d prefer something like
<br>
</div>
<div>
<br>
</div>
<div>
Scheduling: none / internal / all / X-??
<br>
</div>
<div>
<br>
</div>
<div>
over
<br>
</div>
<div>
<br>
</div>
<div>
Scheduling-Enabled: F
<br>
</div>
</blockquote>
<div style="font-family: Arial;">
<br>
</div>
<div style="font-family: Arial;">
I am happy with either. The default would be "all" of course in your example.
<br>
</div>
<div style="font-family: Arial;">
<br>
</div>
<blockquote type="cite">
<div>
I think the reason why people have been reluctant introducing that is that if you have this header, you can’t reliably know anymore whether something was scheduled or not (and a big motivation was that this decision MUST be taken off the client, because unreliable).
<br>
</div>
</blockquote>
<div style="font-family: Arial;">
<br>
</div>
<div style="font-family: Arial;">
This has always annoyed me that the client can't even be trusted to send a header, particularly since it could have been made compulsory. Anyway, water under a bridge. I much prefer explicitly requested side-effects over implicit side effects (aka:magic) as a protocol design philosophy.
<br>
</div>
<div style="font-family: Arial;">
<br>
</div>
<blockquote type="cite">
<div>
What I don’t remember is how bulk-upload deals with that (
<a href="https://github.com/evert/calendarserver-extensions/blob/master/calendarserver-bulk-change.txt">https://github.com/evert/calendarserver-extensions/blob/master/calendarserver-bulk-change.txt</a>). Is that implicitly off, does it explicitly support the functionality?
<br>
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<blockquote>
<div>
# Schedule-Address header
<br>
</div>
</blockquote>
<div>
<br>
</div>
<div>
I don’t understand this one. CalDAV does support aliases in the address-set. And when setting an attendee it is the clients choice which address to use (either as the EMAIL attribute or the attendee URI).
<br>
</div>
</blockquote>
<div style="font-family: Arial;">
<br>
</div>
<div style="font-family: Arial;">
What does your server do if two of the addresses in address set are invited? What do you do if the user has an alias *@example.com but there are some carve-out addresses which belong to somebody else?
<br>
</div>
<div style="font-family: Arial;">
<br>
</div>
<div style="font-family: Arial;">
Bron
<br>
</div>
<div style="font-family: Arial;">
<br>
</div>
<blockquote type="cite">
<div>
<br>
</div>
<div>
hh
<br>
</div>
<div>
<br>
</div>
<blockquote>
<div>
On 6. Jun 2018, at 00:40, Bron Gondwana <
<a href="mailto:brong@fastmailteam.com">brong@fastmailteam.com</a>> wrote:
<br>
</div>
<div>
<br>
</div>
<div>
# Scheduling-Enabled header
<br>
</div>
<div>
<br>
</div>
<div>
RFC6638 Section 8.1 defines the Schedule-Reply header to suppress server-sent scheduling messages when removing a resource (e.g. when cleaning up spam), however there are other situations in which a client may wish to update the resource stored on a server without sending scheduling resources, for example:
<br>
</div>
<div>
<br>
</div>
<div>
* Migrating an existing calendar from one server to another (e.g. changing providers)
<br>
</div>
<div>
* Restoring a calendar from backup after data loss
<br>
</div>
<div>
* keeping a synchronised copy of another calendar for backup, caching or aggregation purposes
<br>
</div>
<div>
<br>
</div>
<div>
Setting schedule-agent to CLIENT is not a good solution, because other clients will continue to leave the value set to CLIENT and then scheduling won't work on that event.
<br>
</div>
<div>
<br>
</div>
<div>
So - I propose replacing and/or supplementing "Schedule-Reply: F" with another header - "Scheduling-Enabled: F" which suppresses all scheduling actions on the server, and stores the resource as-is. This is an HTTP header on the PUT action, and the resource can then be interacted with normally by clients.
<br>
</div>
<div>
<br>
</div>
<div>
# Schedule-Address header
<br>
</div>
<div>
<br>
</div>
<div>
Email has the concept of aliases, however CalDAV does not. When storing or updating a resource, the server calculates which of the ORGANIZER or ATTENDEE properties refers to the acting user by looking at the calendar-user-address property on the calendar, or by the username of the authenticated user. This header provides a way for the client to tell the server "this is the address I am acting as", overriding those hints.
<br>
</div>
<div>
<br>
</div>
<div>
====
<br>
</div>
<div>
<br>
</div>
<div>
With these two headers, it's possible to use CalDAV for all interactions with the server, without needing a separate protocol for backup restore or for injecting iMIP messages sent to aliases. I assume I'd also need a way to define in some server info on the server that these headers were supported - so I'd love suggestions there.
<br>
</div>
<div>
<br>
</div>
<div>
I'm happy to write this up as an IETF draft and bring it to calext, particularly if there's general support of the idea. I'm happy to consider new names for the headers as well - it's pretty easy to change on our server and client code at FastMail. Both these headers are implemented and in production on our systems.
<br>
</div>
<div>
<br>
</div>
<div>
====
<br>
</div>
<div>
<br>
</div>
<div>
Cheers,
<br>
</div>
<div>
<br>
</div>
<div>
Bron.
<br>
</div>
<div>
<br>
</div>
<div>
--
<br>
</div>
<div>
Bron Gondwana, CEO, FastMail Pty Ltd
<br>
</div>
<div>
<a href="mailto:brong@fastmailteam.com">brong@fastmailteam.com</a>
<br>
</div>
<div>
<br>
</div>
<div>
<br>
</div>
<div>
<u>_______________________________________________</u>
<br>
</div>
<div>
caldeveloper-l mailing list
<br>
</div>
<div>
<a href="mailto:caldeveloper-l@lists.calconnect.org">caldeveloper-l@lists.calconnect.org</a>
<br>
</div>
<div>
<a href="http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org">http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org</a>
<br>
</div>
</blockquote>
<div>
<br>
</div>
<p>Email had 1 attachment:<br></p>
<ul>
<li>
<div style="font-family: Arial;">
<code>signature.asc</code>
<br>
</div>
<div style="font-family: Arial;">
1k (application/pgp-signature)
<br>
</div></li>
</ul>
</blockquote>
<div style="font-family: Arial;">
<br>
</div>
<div>
<div>
--
<br>
</div>
<div>
Bron Gondwana, CEO, FastMail Pty Ltd
<br>
</div>
<div>
brong@fastmailteam.com
<br>
</div>
<div>
<br>
</div>
</div>
<div>
<u>_______________________________________________</u>
<br>
</div>
<div>
caldeveloper-l mailing list
<br>
</div>
<div>
<a href="mailto:caldeveloper-l@lists.calconnect.org">caldeveloper-l@lists.calconnect.org</a>
<br>
</div>
<div>
<a href="http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org">http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org</a>
<br>
</div>
</blockquote>
<div style="font-family: Arial;">
<br>
</div>
<div class="ox-bf88f49e4c-signature">
--
<br>
</div>
<div class="ox-bf88f49e4c-signature">
Bron Gondwana, CEO, FastMail Pty Ltd
<br>
</div>
<div class="ox-bf88f49e4c-signature">
brong@fastmailteam.com
<br>
</div>
<div class="ox-bf88f49e4c-signature">
<br>
</div>
<div style="font-family: Arial;">
<br>
</div>_______________________________________________
<br>caldeveloper-l mailing list
<br>caldeveloper-l@lists.calconnect.org
<br>http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org
<br>
</blockquote>
<div class="default-style">
<br>
</div>
<div class="io-ox-signature">
<p>--<br>Tobias Friedrich<br>Engineering - Backend-Team<br>Open-Xchange GmbH</p>
<p>Phone: +49 2761 8385-0, Fax: +49 2761 838530</p>
<p>-------------------------------------------------------------------------------<br>Open-Xchange AG, Rollnerstr. 14, 90409 Nürnberg, Amtsgericht Nürnberg HRB 24738<br>Vorstand: Rafael Laguna de la Vera, Carsten Dirks<br>Aufsichtsratsvorsitzender: Richard Seibt</p>
<p>European Office: Open-Xchange GmbH, Martinstr. 41, D-57462 Olpe, Germany<br>Amtsgericht Siegen, HRB 8718, Geschäftsführer: Frank Hoberg, Martin Kauss</p>
<p>US Office: Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA<br></p>
</div>
</body>
</html>