We found the interoperability lab to be a very valuable exercise, and during the course of the two days were able to make changes in our current application. At then end of the two days we were communicating with all four servers, reading data, making changes with three of them. Most of the changes were based on incorrect assumptions, caused by developing with only one server. Moving forward, having access to multiple implementations will let us build a much more robust client.

As for the event itself, having face to face contact, and immediate bug fixing on both sides was extremely valuable to a quick development process. Doing this remotely might work, but the fact that we can bring laptops right to the people writing the server, or ask the other clients to modify data made the whole event go smoothly.

Some issues we encountered with specifically:

• Their application depends on valid principals with calendar- home-set properties; not all the servers had this set up.

• Calendar User Addresses are an issue, the fact that they can be anything, even email addresses that they are using elsewhere in their application was causing them problems with scheduling.

• They were using relative paths in some cases where servers were expecting full paths

• Also a couple of other minor issues, not really worth getting into here.

We realize this interoperability meeting was focused on client/server compatibility. One thing we would like to see in the future is more multi-client read write access to the same data on the same server and then making sure that everything still works. For example, have one vendor create a lot of calendar data on their server with their client, then let our application read and modify the data, then see that it shows up correctly the receiving application.

“Overall this was a great event, and we look forward to the next one.”

Our server team was pleased to participate in this CalConnect IOP. We had the absolute latest version of our CalDAV server available for testing on two machines.

All clients were tested against the server during the course of the event. No major problems were found in our server implementation. On the whole other clients do not yet support some of the more ‘advanced’ features such as access control and scheduling, so significant portions of the code were not exercised, but those portions that were performed as expected. We are not aware of any significant problems clients had with working with our server as compared to others.

Overall we found this to be a valuable experience and look forward to participating again in the future.

1. One vendor requires a principal resource with the CALDAV:calendar-home-set property so that it can locate a user’s calendar collections. The developer added support to their application for WEBDAV principals (section 4 of the ACL spec).

   One application had problems renaming calendars. This operation uses WEBDAV MOVE underneath. It turns out that the application was sending a relative URI in the Destination header which RFC 2518 specifies must contain an absolute URI. The developer beefed up the code to handle both forms and I believe the folks changed to absolute, so all was well after that.

2. One vendor did some amount of testing with their application, but the developer wasn’t directly involved and they never communicated any issues to him.

3. Another vendor ran the CALDAV test suite from their calendar server and found an issue when DELETEing a null resource.

4. An unknown party exposed a bug wherein a vendor application errored when receiving any CALDAV REPORT against a regular (non-calendar) collection.

The developer fixed all of these issues yesterday and then waited to hear about anything else that came up the next day. Nothing was reported.

One vendors application converts individual to UTC time. They also move floating recurr to UTC. Syncing unlimited recurrence fails. It also adds Alarms to every event. We found that this application rewrites exceptions as RDates and Exdates. Another vendor’s handling of modifications loses non-time pieces of these exceptions. All-day event creation fails on another vendors application. We also noted that another vendor does not send durations.

With regards to the specific items tested, they noted the following:

1. While verifying two free busy periods, they actually got three free-busy periods noted. So far as they could tell, both forms are valid (i.e. servers & clients are free to coalesce free-busy as they see fit).

2. While testing against one vendor application they noted the following:

   1. The server deleted VALARMs stored with events

   2. Modifications to recurring events caused an internal server error (500 HTTP response)

   3. The server never changes ETags, so a second client isn’t able to sync properly, since it thinks events haven’t changed since previous sync.

   4. The HTTP DELETE request succeeded, but the collection stayed on the server.

   5. The server returned an empty (HTTP 204) response to a valid free-busy-request REPORT.

They were very happy to exchange iCalendar objects to send to their server. Several attendees sent objects to help them test their iCalendar support, in particular recurring events. They found issues when absorbing iCalendar recurrence events. These will be useful in helping them streamline their software.

They tested their products against both servers. They also tested against another application. Not having stop time or no DTStart on timed event did cause some problems. They may need to put some kind of Note on events with no stop time or something like a ragged edge Icon on items with no end times. However, this may break scheduling with no end time. They also noted that the organizer object in one vendor’s application is an issue. Another vendor doesn’t allow the creator to update the principle.

We assume testers will have found some problems in the area of recurrences when working with our product. They are currently working on rewriting that support.

One vendor ran across a problem with a recurrent event that proved to be an ical4j bug. This is now fixed.

Another vendor’s application etags were broken and are now fixed.

We partially fixed a problem deleting calendars.