Message format

[WhyNotHugo]

When the server pushes notifications to the client, it'll have to send a specific payload.

I'm opening this issue with the intent of discussing and agreeing on the format for this payload.

I think that using XML is probably the best choice. That's really a sentence I never though I'd write (I'm not a huge fan of XML), but I think it's the logical choice given that CalDav is already using XML. Any client can be expected to be able to parse and handle this already, and an extension to CalDav should really just use the same underlying format.

In particular, I think that the message that servers "push" to clients, could include a payload very similar to the result of a PROPFIND querying the etag for the element that has changed:

<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:"
          xmlns:C="urn:ietf:params:xml:ns:caldav">
 <D:response>
   <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
   <D:propstat>
     <D:prop>
       <D:getetag>"fffff-abcd2"</D:getetag>
     </D:prop>
     <D:status>HTTP/1.1 200 OK</D:status>
   </D:propstat>
 </D:response>
</D:multistatus>

This tells the client which resource has changed and is enough for the client determine what course of action they want to take (usually, fetch the updated resource).

Aggregation of multiple entries (e.g.: multiple response nodes with a different href each) should be perfectly valid.

[rfc2822]

I support that since WebDAV is based on XML, XML would be a good choice because clients can use their existing parsers/libraries for Push, too.

Existing ideas about such push messages:

• JMAP sends a so-called StateChange object to clients.
• TC-PUSH Draft suggests an Update notification basically containing topics. A subscribed topic represents a *DAV resource (like a calendar). A sample notification can be found there, too.
• (W3C Push API does not specify the format of push messages because it's only describing the push workflow itself.)

My original idea was to send a list of topics/subscription IDs, encapsulated in XML, something like

<push-notification>
  <updated>
    <subscription>12345_subscription_id_here</subscription>
    <subscription>67890_another_subscription_id_here</subscription>
  </updated>
</push-notification>

Because push messages could/should be aggregated (for instance because they are only sent every minute to avoid flooding), it should be a list.

[WhyNotHugo]

I would rather send the href of the resource that has changed, not the containing collection. Sending the collection means that the client needs to:

1. Fetch the full list of the collection with etags.
2. Compare with a local state which one has changed.
3. Request the resource that has changed.

This basically means that a client has to do a "full sync" when a single item changes.

Also, I don't think we'd have a concept of "subscription id" when using WebSocket.

[rfc2822]

That may be interesting for WebSocket connections. However other push backends may not be that reliable and either deliver a push, or not, and may do so in time or not. Also the body size of such push messages may be very limited.

Btw, sending the changed resources sounds to me as if this would be related to Collection Sync - basically every Change that changes the sync-token would then send a push notification as side effect. Clients could load only changes since this sync-token (updated and also deleted entries, the mechanism is defined there).

For DAVx5, I'd do a re-sync in any case.

Maybe we could use some Depth mechanism for subscriptions? Depth: 0 only subscribes to the collection, Depth: 1 also to its members.

[WhyNotHugo]

I often forget about Collection Sync (mostly because many servers don't implement it).

Maybe we could use some Depth mechanism for subscriptions? Depth: 0 only subscribes to the collection, Depth: 1 also to its members.

This sounds like a very good balance. 👍