Creating a calendar with timezone fails on Fastmail

[cubeshit]

Problem scope

• I'm sure that this is a DAVx⁵ problem.

App version

• I'm using the latest available DAVx⁵ version.

Android version and device/firmware type

Android 13

Steps to reproduce

• Add a new account
• Try to add a new calendar
• Calendar is created but then disappears while syncing

It happens with Fastmail and GMX (both Tested Services)
Doesn't happen with Nextcloud.
Already reinstalled DAVx5 and nothing changed.

Actual result

I can create a new calendar but then it tries to sync and it disappears.

Expected result

I can create a new calendar and it gets synced.

Further info

[devvv4ever]

Hi,

which types did you select when creating the calendar? VTODO VJOURNAL and VEVENT together or only one of them?

Some services/servers may not allow creating calendar from a client side at all.

[sunkup]

Just tested with GMX and it works fine for me.

[broccan]

I found that calendar creation only works on DAVx5 and fastmail without a timezone. i.e. scroll to the top and set it to -.

The part of the debug log indicating this is:

2024-08-09 13:46:39 16929 [.network.HttpClient]         <?xml version="1.0" encoding="utf-8"?>
<multistatus xmlns="DAV:" xmlns:CAL="urn:ietf:params:xml:ns:caldav" xmlns:CARD="urn:ietf:params:xml:ns:carddav" xmlns:n0="http://apple.com/ns/ical/">
  <propstat>
    <prop>
      <CAL:calendar-timezone/>
    </prop>
    <status>HTTP/1.1 403 Forbidden</status>
    <error>
      <CAL:valid-calendar-data/>
    </error>
  </propstat>
  <propstat>
    <prop>
      <resourcetype/>
      <displayname/>
      <CAL:calendar-description/>
      <n0:calendar-color/>
      <CAL:supported-calendar-component-set/>
    </prop>
    <status>HTTP/1.1 424 Failed Dependency</status>
  </propstat>
</multistatus>

I feel this should be handled by the DAVx5 client, or at the least some sort of error pop up when it occurs

[rfc2822]

Can you please also report this to Fastmail? After all, the CalDAV standard suggests calendars to have this property.

[rfc2822]

Was there any outcome?

[broccan]

Sorry, I just sent the feedback to fastmail now, I'll keep you updated

[robmueller]

I believe Davx5 is sending the wrong information here. From the spec on calendar-timezone

https://www.rfc-editor.org/rfc/rfc4791#section-5.2.2

5.2.2.  CALDAV:calendar-timezone Property

   Name:  calendar-timezone
...
"an iCalendar object with exactly one VTIMEZONE component.

But Davx5 is sending a timezone ID, not a VTIMEZONE component.

Instead Dav5x should be using the calendar-timezone-id property defined in:

https://www.rfc-editor.org/rfc/rfc7809#section-5.2

5.2.  CALDAV:calendar-timezone-id

   Name:  calendar-timezone-id
...
"a time zone identifier."

[ArnyminerZ]

Hi Rob, we are working on a fix to this, and we have (hopefully) fixed the issue to follow the spec. I've tried creating a calendar with a random timezone:

Request

<?xml version='1.0' encoding='UTF-8' ?>
<CAL:mkcalendar
	xmlns="DAV:"
	xmlns:CAL="urn:ietf:params:xml:ns:caldav"
	xmlns:CARD="urn:ietf:params:xml:ns:carddav">
	<set>
		<prop>
			<resourcetype>
				<collection />
				<CAL:calendar />
			</resourcetype>
			<displayname>Calendar with timezone</displayname>
			<CAL:calendar-description></CAL:calendar-description>
			<n0:calendar-color
				xmlns:n0="http://apple.com/ns/ical/">#FFFAFAFF
			</n0:calendar-color>
			<CAL:calendar-timezone-id>Africa/Bamako</CAL:calendar-timezone-id>
			<CAL:calendar-timezone>BEGIN:VCALENDAR
BEGIN:VTIMEZONE
TZID:Africa/Bamako
BEGIN:STANDARD
TZNAME:GMT
TZOFFSETFROM:+001608
TZOFFSETTO:+0000
DTSTART:19120101T000000
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

                 </CAL:calendar-timezone>
		</prop>
	</set>
</CAL:mkcalendar>

but it's still failing:

Response

<?xml version="1.0" encoding="utf-8"?>
<multistatus
	xmlns="DAV:"
	xmlns:CAL="urn:ietf:params:xml:ns:caldav"
	xmlns:CARD="urn:ietf:params:xml:ns:carddav"
	xmlns:n0="http://apple.com/ns/ical/">
	<propstat>
		<prop>
			<CAL:calendar-timezone-id/>
		</prop>
		<status>HTTP/1.1 403 Forbidden</status>
	</propstat>
	<propstat>
		<prop>
			<resourcetype/>
			<displayname/>
			<CAL:calendar-description/>
			<n0:calendar-color/>
			<CAL:calendar-timezone/>
		</prop>
		<status>HTTP/1.1 424 Failed Dependency</status>
	</propstat>
</multistatus>

Is there any obvious thing you find there? Maybe Fastmail doesn't support this feature? I've seen that this option is not available from the UI:

If I try to create a calendar without a timezone definition, it gets created correctly:

Request

<?xml version='1.0' encoding='UTF-8' ?>
<CAL:mkcalendar
	xmlns="DAV:"
	xmlns:CAL="urn:ietf:params:xml:ns:caldav"
	xmlns:CARD="urn:ietf:params:xml:ns:carddav">
	<set>
		<prop>
			<resourcetype>
				<collection />
				<CAL:calendar />
			</resourcetype>
			<displayname>Calendar without timezone</displayname>
			<CAL:calendar-description></CAL:calendar-description>
			<n0:calendar-color
				xmlns:n0="http://apple.com/ns/ical/">#DC143CFF
			</n0:calendar-color>
		</prop>
	</set>
</CAL:mkcalendar>

Which returns an empty 201 response.

Any ideas on what the issue might be? In any case, I think there shouldn't be a timezone by default, it should be set by the server, though @rfc2822 might have other preferences.

[robmueller]

It turns out that at the moment that the calendar-timezone-id support that's in cyrus isn't currently enabled at Fastmail! That's mostly because no client appears to have tried to use it before so we haven't had customer support requests for it. I'll talk with the team what's needed to actually enable it on our end.

[ArnyminerZ]

Awesome! Thanks.

We'll keep this thread open so that you can answer on the response you get 😉

[rfc2822]

I wonder how other servers will react to the calendar-timezone-id. Shouldn't it just be ignored when it's not supported / turned off? Because if not, we can't really use it without checking support before etc. and then it becomes cumbersome…

[ArnyminerZ]

Shouldn't it just be ignored when it's not supported / turned off? Because if not, we can't really use it without checking support before etc.

Well, in this case, it has gone from not working at all, to not working at all, so technically it doesn't break anything 😆

I did try it out with Nextcloud and it was working fine, so I hope that it works anywhere else also

[rfc2822]

Should work with 4.4.3.2 again