[caldeveloper-l] Proposed draft: Caldav-scheduling-controls

Thu Jun 7 02:29:40 PDT 2018

Please see attached a very early draft.  I'd love feedback (particularly
from those of you at CalConnect right now) on:
* how to tell the client that the server support this?  (server-
  info?, OPTIONS?)* should this be two separate specs, or together?
* should values for "Scheduling" header be case significant?

Thanks!

Bron.

On Wed, Jun 6, 2018, at 14:37, Bron Gondwana wrote:
> 
> 
> 
> On Wed, Jun 6, 2018, at 08:56, Helge Heß wrote:
>>> # Scheduling-Enabled header
>> 
>> I wanted to have that thing for a looong time.
>> 
>> I don’t like the header a lot, I’d prefer something like
>> 
>>   Scheduling: none / internal / all / X-??
>> 
>> over
>> 
>>   Scheduling-Enabled: F
> 
> I am happy with either.  The default would be "all" of course in your
> example.> 
>> 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).> 
> 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.> 
>> What I don’t remember is how bulk-upload deals with that
>> (https://github.com/evert/calendarserver-extensions/blob/master/calendarserver-bulk-change.txt)
>> . Is that implicitly off, does it explicitly support the
>> functionality?>> 
>> 
>>> # Schedule-Address header
>> 
>> 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).> 
> 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?> 
> Bron
> 
>> 
>> hh
>> 
>>> On 6. Jun 2018, at 00:40, Bron Gondwana <brong at fastmailteam.com>
>>> wrote:>>> 
>>> # Scheduling-Enabled header
>>> 
>>> 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:>>> 
>>> * Migrating an existing calendar from one server to another (e.g.
>>>   changing providers)>>> * Restoring a calendar from backup after data loss
>>> * keeping a synchronised copy of another calendar for backup,
>>>   caching or aggregation purposes>>> 
>>> 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.>>> 
>>> 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.>>> 
>>> # Schedule-Address header
>>> 
>>> 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.>>> 
>>> ====
>>> 
>>> 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.>>> 
>>> 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.>>> 
>>> ====
>>> 
>>> Cheers,
>>> 
>>> Bron.
>>> 
>>> --
>>> Bron Gondwana, CEO, FastMail Pty Ltd
>>> brong at fastmailteam.com
>>> 
>>> 
>>> _________________________________________________
>>> caldeveloper-l mailing list
>>> caldeveloper-l at lists.calconnect.org
>>> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org>> 
>> Email had 1 attachment:

>>  * signature.asc 1k (application/pgp-signature)> 
> --
>   Bron Gondwana, CEO, FastMail Pty Ltd
>   brong at fastmailteam.com
> 
> _________________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong at fastmailteam.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20180607/fdef936e/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-gondwana-caldav-scheduling-controls.txt
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20180607/fdef936e/attachment-0001.txt>