calendar-color "changes" namespace

[WhyNotHugo]

I'm setting a property on a calendar collection:

<propertyupdate xmlns="DAV:" xmlns:ICAL="http://apple.com/ns/ical/">
  <set>
    <prop>
      <ICAL:calendar-color>#ff00ff</ICAL:calendar-color>
    </prop>
  </set>
</propertyupdate>

When I then read the property, it is missing from the response, but a same-named property with a different namespace is present.

<?xml version="1.0" encoding="utf-8"?>
<multistatus xmlns="DAV:">
  <response>
    <href>/dav/calendars/user/vdirsyncer@fastmail.com/JdvI8QAUmqEEcdvQ/</href>
    <propstat>
      <prop>
        <calendar-color><![CDATA[#ff00ff]]></calendar-color>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>

As a result, a client application will assume that the property is "unset".

[WhyNotHugo]

This is still an issue. The server is rewriting the namespace for this property into the wrong namespace.

[WhyNotHugo]

The same issue is also present for the calendar-order property.

[dilyanpalauzov]

The semantics for both properites is the same in both namespaces. Why don’t you set and read the property in the DAV: namespace?

[WhyNotHugo]

Other clients and servers give special meaning to {http://apple.com/ns/ical/}calendar-color, but not to {DAV:}calendar-color. For example:

• Nextcloud uses the value of {http://apple.com/ns/ical/}calendar-color when rendering calendar colours. If I write to {DAV:}calendar-color, then Nextcloud won't show a colour for that calendar.

• Tasks (client) reads {http://apple.com/ns/ical/}calendar-color for calendar colours.

• SailfishOS's caldav plugin also uses {http://apple.com/ns/ical/}calendar-color for calendar colours.

• A quick search shows a lot of other clients follow the same behaviour.

If I start writing to {DAV:}calendar-color, I break interoperability with the rest of the world.

---

Out of the seven servers with which I am testing, this is the only scenario where setting or reading a property returns a non-error response with the property missing. I have to special-case this behaviour in my response parser, and I'd like to get rid of that hack too.

[dilyanpalauzov]

I could not find code, which changes the namespace for these two properties. So this logic must be provided by Fastmail and is not part of Cyrus IMAP. (I looked for calendar-color and it was always prefixed with the Apple namespace.)

[rsto]

@WhyNotHugo I can not replicate your issue. In fact, we do have a test that asserts that this exact DAV property gets returned properly in a PROPFIND: https://github.com/cyrusimap/cyrus-imapd/blob/master/cassandane/tiny-tests/Caldav/calendar_setcolor

[dilyanpalauzov]

I looked again on the calendar-colour. What Cyrus IMAP does, is to map the NS_APPLE:calendar-color to COLOR: iCalendar property, when the calendar is exported. That is, when one calls GET https://server/dav/calendars/user/username/calendar-uid/.

What Cyrus IMAP also does, is for iCalendar objects to extract from the CATEGORIES: properties values words, which sound like colour, and map them to color-property. This is however only done in jmap-code.

About calendar-order there is no special handling, except in JMAP-code, which should not be relevant.

By reading the code I cannot confirm the behaviour observed by you. By executing the command below, on my server, which runs Cyrus IMAP 3.8 with many patches, I also cannot confirm the behaviour described by you. I can give you access, so that you can try yourself towards the server I use.

PROPFIND

curl -HDepth:0 -XPROPFIND -H"content-type:application/xml" -ume:password --data-binary @- <<EOF https://server/dav/calendars/user/me/Default/
<propfind xmlns='DAV:' xmlns:ICAL="http://apple.com/ns/ical/">
 <prop>
   <resourcetype/>
   <ICAL:calendar-color/>
   <calendar-color/>
 </prop>
</propfind>
EOF

→
content-type: application/xml; charset=utf-8

<multistatus xmlns="DAV:" xmlns:ICAL="http://apple.com/ns/ical/" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:CS="http://calendarserver.org/ns/">
<response>
  <href>/dav/calendars/user/me/Default/</href>
  <propstat>
    <prop><resourcetype><collection/><C:calendar/></resourcetype><ICAL:calendar-color><![CDATA[#4e9a06]]></ICAL:calendar-color></prop>
    <status>HTTP/1.1 200 OK</status>
  </propstat>
  <propstat>
    <prop><calendar-color/></prop><status>HTTP/1.1 404 Not Found</status>
  </propstat>
</response>
</multistatus>

PROPPATCH:

curl -v -HDepth:0 -XPROPPATCH -H"content-type:application/xml" -ume:password --data-binary @- <<EOF https://server/dav/calendars/user/me/Default/

<propertyupdate xmlns="DAV:" xmlns:ICAL="http://apple.com/ns/ical/">
  <set>
   <prop>
   <ICAL:calendar-color><![CDATA[#777777]]></ICAL:calendar-color>
   </prop>
  </set>
</propertyupdate>
EOF

→
content-type: application/xml; charset=utf-8

<?xml version="1.0" encoding="utf-8"?>
<multistatus xmlns="DAV:" xmlns:ICAL="http://apple.com/ns/ical/"><response>
  <href>/dav/calendars/user/me/Default/</href>
  <propstat><prop><ICAL:calendar-color/></prop>
  <status>HTTP/1.1 200 OK</status></propstat>
</response></multistatus>

Again PROPFIND

curl -v -HDepth:0 -XPROPFIND -H"content-type:application/xml" -ume:pw --data-binary @- <<EOF https://server/dav/calendars/user/me/Default/
<propfind xmlns='DAV:' xmlns:ICAL="http://apple.com/ns/ical/">
 <prop>
   <resourcetype/>
   <ICAL:calendar-color/>
   <calendar-color/>
 </prop>
</propfind>
EOF

<multistatus xmlns="DAV:" xmlns:ICAL="http://apple.com/ns/ical/" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:CS="http://calendarserver.org/ns/">
<response>
  <href>/dav/calendars/user/me/Default/</href>
  <propstat>
      <prop>
        <resourcetype><collection/><C:calendar/></resourcetype>
        <ICAL:calendar-color><![CDATA[#777777]]></ICAL:calendar-color>
      </prop>
      <status>HTTP/1.1 200 OK</status></propstat>
  <propstat><prop><calendar-color/></prop><status>HTTP/1.1 404 Not Found</status></propstat>
</response>
</multistatus>

[WhyNotHugo]

My testing was specifically done on Fastmail, are you aware on any downstream patches in this scope?

My request is exactly:

<propertyupdate xmlns="DAV:">
  <set>
    <prop>
      <calendar-color xmlns="http://apple.com/ns/ical/">#ff00ff</calendar-color>
    </prop>
  </set>
</propertyupdate>

And the response is:

<?xml version="1.0" encoding="utf-8"?>
<multistatus xmlns="DAV:">
  <response>
    <href>/dav/calendars/user/vdirsyncer@fastmail.com/czfL2Bs8klqXYBlG/</href>
    <propstat>
      <prop>
        <calendar-color/>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
</multistatus>

I also queried the above collection:

<propfind xmlns=\"DAV:\"><prop><calendar-color xmlns=\"http://apple.com/ns/ical/\"/></prop></propfind>

And got the following response:

<?xml version="1.0" encoding="utf-8"?>
<multistatus xmlns="DAV:">
  <response>
    <href>/dav/calendars/user/vdirsyncer@fastmail.com/czfL2Bs8klqXYBlG/</href>
    <propstat>
      <prop>
        <calendar-color><![CDATA[#ff00ff]]></calendar-color>
      </prop>
      <status>HTTP/1.1 200 OK</status>
    </propstat>
  </response>
</multistatus>

[WhyNotHugo]

Conjecture: the XML parser used by the server is ignoring the xmlns defined in the child element.

[dilyanpalauzov]

I upload

curl -v -HDepth:0 -XPROPPATCH -H"content-type:application/xml" -ume:password --data-binary @- <<EOF https://server/dav/calendars/user/me/Default/

<propertyupdate xmlns="DAV:" >
  <set>
   <prop>
   <calendar-color xmlns="http://apple.com/ns/ical/"><![CDATA[#4e9a09]]></calendar-color>
   </prop>
  </set>
</propertyupdate>
EOF

and then see what is stored in the annotations database:

cvt_cyrusdb /var/imap/annotations.db twoskip /var/imap/A flat && grep -a 44c2efd856b10d84 A

Converting from /var/imap/annotations.db (twoskip) to /var/imap/A (flat)
44c2efd856b10d84/vendor/cmu/cyrus-httpd/<DAV:>color     Defaulttext/plain
44c2efd856b10d84/vendor/cmu/cyrus-httpd/<DAV:>displayname
                                                                Default2222text/plain
44c2efd856b10d84/vendor/cmu/cyrus-httpd/<http://apple.com/ns/ical/>calendar-color       #4e9a09text/plain

Color is updated to #4e9a09 in the database with the right name space. But fetching the data is wrong, as the reply skips all namespaces:

curl -v -HDepth:0 -XPROPFIND -H"content-type:application/xml" -ume:password --data-binary @- <<EOF https://server/dav/calendars/user/me/Default/
<propfind xmlns='DAV:'>
 <prop>
   <calendar-color xmlns="http://apple.com/ns/ical/"/>
   <calendar-color/>
 </prop>
</propfind>
EOF

returns

<?xml version="1.0" encoding="utf-8"?>
<multistatus xmlns="DAV:">
<response>
  <href>/dav/calendars/user/me/Default/</href>
  <propstat><prop><calendar-color><![CDATA[#4e9a09]]></calendar-color></prop><status>HTTP/1.1 200 OK</status></propstat>
  <propstat><prop><calendar-color/></prop><status>HTTP/1.1 404 Not Found</status></propstat>
</response></multistatus>