Foreword

This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) Documents as located at

http://www.calconnect.org/documents/disclaimerpublic.pdf.

June 2008 CalConnect Mobile Interoperability Test Report

1. Participants

Table 1 — Participants

Organization	Participants	Products Tested
Apple	Cyrus Daboo	iCal Server and client — OS X 10.5.3 iCal client 3.03
Mozilla	Bruno Browning	Sunbird/Lightning 0.9pre Mozilla Calendar CVS pull (mid-May sometime)
RPI/Bedework	Mike Douglass	Bedework server 3.5
Scalix	Florian von Kurnatowski Gren Elliot	11.4.1 pre-release
Zimbra Yahoo	John Holder Jong Yoon Lee	Zimbra Server pre 5.0.7 (nightly)
Uppsala University, Sweden	Emil Lundberg — Observer	iCal 3.0.3 (1244)
CalConnect Reps
Interop Manager Logistics	Pat Egen Dave Thewlis

2. Introduction

Participants of the testing event used predetermined test scenarios. Rather than post the full scenarios in this document, they can be found on the CalConnect website at the following URL: http://www.calconnect.org/ioptesting.shtml. The documents used in this testing event was the CalConnect CalDAV Matrix for Draft 08, in particular the scheduling section. This was one of the first interops where we had clients that supported the scheduling portion of CALDAV. Summaries and specific findings and issues found are noted in this document.

3. Participant Comments and Findings

3.1. Vendor 1

This vendor stated they were pleased to take part in the CalConnect interoperability event. Their testing focused on a server product with a client to ensure their scheduling support was working well and they certainly made big strides there. Other server vendors were doing a lot of their own testing with a client and they were able to help them out on a few issues.

No major issues were found, though some follow-up is needed on specific client behaviors that other vendors asked about. Now looking forward to the next event.

3.2. Vendor 2

The vendor was mostly testing a client and their implementation of scheduling.

Generally the baseline CalDAV stuff worked well with all the servers present for testing. They did see some oddities interacting with recurring items on one server but otherwise all was good.

CalDAV-sched was also working well after some bugs were fixed at the interop. This was tested most thoroughly with another vendor offering but was able to send invitations successfully with two other servers as well; they did not test those for REPLY creation or handling.

CalDAV-sched (including freebusy) is not yet working with one of the vendors present. The tester felt the chance to meet and interact with the other developers as well as their code was invaluable and has continued to be a benefit since the event. The only ways they can think of to improve it would be to increase some parameters: length of event, number of participants, and frequency of occurrence. However, they realize that all of those are difficult.

3.3. Vendor 3

The main value of the interop to this vendor was being in the same room as some of the other developers. This was invaluable for learning about how to configure better logging and also in diagnosing issues in both clients and our server.

Their CalDAV Schedule support did not work at all with one of the clients and they spent a lot of time diagnosing issues with that and fixing them. They didn’t support principal-property-search reports, for instance, which was a major blocker.

When updating a calendar entry, the server was using the HTTP status code of Created, which is incorrect for an update. The other vendor application was unhappy with this status code. It was creating meetings without an ORGANIZER at one point and this resulted in the server creating corrupt ORGANIZER fields in subsequent accesses.

Initial testing yet another vendor showed that the test version of that vendor’s application was not recognizing our Meeting Requests at all. This was subsequently fixed by them.

A lack of iMip support prevented IOP testing with two of the server applications at the event.

3.4. Vendor 4

This was a relatively quiet CITE but useful nonetheless.

One of the other vendors managed to find some CalDAV issues with our application. Those that were bugs were fixed and retried.

The one specific bug that might affect others is that our application wasn’t always handling content-type correctly when the character set was appended.

Scheduling using another vendor seemed to work fine.

This vendor also was pleased with the interop event.

3.5. Vendor 5

During the interop testing, this vendor found four significant issues of mention. Their application performed well in general testing against three other clients.

We also took the time to test free busy interop as well as iCal compatibility with two vendors. Their application performed well under these tests.

We also discussed the need to validate the need to validate (in some capacity) the changes that are pushed out on events that have multiple attendees.

3.5.1. Issues Found

Creating a New Calendar, the event will throw 500
- Error: dav - error handling method PUT com.xxxx.xx.dav.DavException: cannot create
- Summary: When creating a new collection, the server may not return the correct collection type.
When Adding an Attendee to an Event on another Domain, PERM_DENIED
- Error: calendar - Unable to process iCalendar attachment com.xxxxxxx.common.service.ServiceException: permission denied: calendar invite not allowed from (Sender)
- Summary: When creating an event via CalDAV, and adding an attendee that is not part of the domain, the server will throw this error. No impact on delivery/event.
MultiGet Problem with Calendars that have encoding\Characters that have encoding are escaped twice
- Error: <status>HTTP/1.1 404 Not Found</status>
- Summary: When using multiget clients and/or if user’s have calendars that have names that have characters that must be encoded, the calendar isn’t visible.
Validation of incoming iMIP messages and calendar SPAM
- Error: None, but impact is invalidated users can edit/change events; unscrupulous individuals can add spam events to calendars, unchecked.

3.6. A Neutral Observer

It is common for us to have observers to the interop. This time the observer chose to actually do some “neutral testing” on their own. These are their comments.

This organization is interested in implementing a university-wide (and possibly inter-university) calendaring service to complement the web, e-mail, and other services (IM also coming), so we are interested in calendaring standards for two reasons:

Can we hope to implement open and common standards for calendaring usable by multiple clients and/or are there third party vendors that can offer this capability, as well as interacting with proprietary protocols?
If so, we are (or should be) willing to contribute to the evolution of such standards, to the best of our ability.

Generally, the IOP event was a rewarding exercise, stressing our own test environment (iCal server) as well as different vendors’ servers and taking part in the discussions that followed. As discussed with the Executive Director previously, we will consider joining either as an individual university.

4. Summary

While the event was smaller than usual, this was our first event where we were able to test scheduling with CALDAV clients. Several vendors tested client and server scheduling.

Several items were uncovered and generally it was very successful. As usual, it would be nice to have more time.

We are continuing our work on a virtual testing environment to enable ongoing, interim testing via the internet to public servers. This will improve the ability to test more applications during our onsite testing events.

Thank you to all the participants and their willingness to take time out of busy schedules to help CalConnect forward the usage of calendaring standards.

Respectfully submitted by Pat Egen, CalConnect Interop Manager.

Appendix A
(normative)
Uppsala University, Sweden

Table A.1

Servers							Comments
One	Two	Three	Four	Five			Comments
					1.	Event creation.
P		P	P	P	1.1.	Create new single-instance meeting titled “Meeting 1.1” with the location “Durham”.
P		P	P	P	1.2.	Create new meeting titled “Meeting 1.2” recurring every Monday from 10:00 AM to 11:00 AM for 4 weeks.
P*		P	P**	P	1.3.	Create new single-instance meeting titled “Meeting 1.3” with 2 other attendees.	* & ** No cuaddr to test with, used CalDAV1 & CalDAV2, got ‘?’. Could use iMIP, and update status though email. NB: for iMip, e-mail address of sender/organizer must match cuaddr (problem w/ many e-mail addresses configured on either client)
P		P	P	P	1.4.	Create new single-instance meeting titled “Meeting 1.4” with an alarm set to trigger 15 minutes prior to the schedule time of the meeting.
					2.	Event modification
P		P	P	P	2.1.	Modify the title of meeting “Meeting 1.1” to “Meeting 1.1bis”.
P		P	P	P	2.2.	Modify the location of the meeting “Meeting 1.1bis” to “Seattle bis”.
P		P	P	P	2.3.	Reschedule meeting “Meeting 1.1bis” to the next day.
P		P	P	P	2.4.	Add an attendee to “Meeting 1.1bis”.
P		P	P	P	2.5.	Add an alarm to “Meeting 1.1bis”.
P		P	P	P	2.6.	Modify the title of the 1st instance of the recurring meeting created in 1.2.
P		P**	P	P	2.7.	Modify the participation status of the 1st attendee in meeting 1.3 to `DECLINED`.	** iMIP broken on test server.
P		P	P	P	2.8.	Cancel the 4th instance of the recurring meeting created in 1.2.
P		P	P	P	2.9.	One client changes “Meeting 1.1bis” to a different time, second client ‘refreshes’ its display to see the modification.
					4.	Event deletion
P		P	P	P	4.1.	Delete a single non-recurring meeting.
P		P	P	P	4.2.	Delete a single recurring meeting with no overridden instances.
P		P	P	P	4.3.	Delete a single recurring meeting with overridden instances.	Deleting all instances, even those that are already deleted.
P		P	P	P*	4.4.	Delete a non-overridden instance of a recurring meeting.	The FIRST time (only) a single but repeated instance is deleted, it comes back!
N		N	N	N	4.5.	Delete an overridden instance of a recurring meeting.
					5.	Access Control
N		N	N	N	5.1.	View access control details on current user’s main calendar.
N		N	N	N	5.2.	Change access control details on current user’s main calendar to add another user with read-only access. Verify that other user can view the calendar but not change it.
N		N	N	N	5.3.	Change access control details on current user’s main calendar to add another user with read-write access. Verify that other user can view the calendar and change it. Verify that changes done by one user are seen by the other.
N		N	N	N	5.4.	Remove another user’s access to the current user’s main calendar and verify they can no longer access the calendar.
					6	Calendar Management
N		N	N	N	6.1	Browse the list of calendars on the server, including the current user’s personal calendars.
P*		P	P	P	6.2	Create a new calendar in the current user’s personal calendar space.	* Can create calendar, but it not writable. Will do after restart of client. Bug fixed in server!
N		N	N	N	6.3	Create a regular collection in the current user’s personal calendar space.
N		N	N	N	6.4	Create a new calendar inside the collection created in 6.3.
P		P	P	P	6.5	Delete the calendar created in 6.2.
N		N	N	N	6.6	Delete the collection created in 6.3.
P Pass F Fail N Not supported (by client)