search

bitfireAT / webdav-push

WebDAV Push: Draft
52 stars 0 forks source link

Message format #1

Closed WhyNotHugo closed 1 year ago

WhyNotHugo commented 1 year ago

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.