Forum for iCal4OL, Print4OL and ICS4OL

Exchange of experiences / Erfahrungsaustausch / Get Help

You are not logged in.

Announcement

Verkauf von iCal4OL an Neukunden ist eingestellt! Keine Demo mehr verfügbar..
Diese Seite ist ausschliesslich für Kunden, welche auch noch zusätzliche Lizenzen kaufen können.
The selling of iCal4OL has ended! No trial available anymore..
This site is exclusively for customers, which may still want to buy additional licenses.

iCal4OL Version 2.16.6 is now available. See Announcements / Ankündigungen


#1 2012-02-01 16:51:37

Roland
Administrator
Registered: 2007-11-25
Posts: 1517

Help for your CalDAV Server Implementation and common mistakes..

Hello

Probably the best way to go is, to use the SabreDAV PHP Framework!

The documentation of SabreDAV and CalConnect (Organization for CalDAV) seem to be not clear enough, though - I (mostly) encounter following issues/bugs with new implementations:

1)
After a HTTP PUT (upload modifying/new) there is no
Etag: "xxxxxxx"
header in the server response! This is a MUST, please read the CalDAV-Spec.... also for HTTP GET!
The new etag must be in the response, otherwise most clients will not work correctly.

(If this bug is present, use flag "no_ctag" in iCal4OL (now default - can be overridden by flag "getctag") - it will read and correct ETAGs in the Sync-Fields, but it can't work together with flag "older", see below)


2)
Field length for HREFs (URI) and UID (permanent unique item identifier) should be both set to at least 255!
iCal4OL has a flag to shorten HREFs ("href") and "most" UIDs, but for Outlook invitations it's essential to upload the GlobalAppointmentID as UID, which can be up to 232 characters.

Therefore it's possible, that an event has a different HREF than UID! This is the case for several server solutions out there. Your solution will not work correctly with some CalDAV clients, if this is not possible!

Actually the server may answer with a new location (HREF), but it's advised to use the HREF provided from the Client!
UID and HREF may differ, but once set, the UID and HREF should never be changed by the server or a client!


3)
<d:displayname>xxxx</d:displayname>   (when retrieving principal infos)
is not in-between
<cal:calendar-user-address-set>...
    <d:displayname>xxxx</d:displayname>
</cal:calendar-user-address-set>
and does NOT contain the fullname (real name) - it should not be the email address!

OK, I'm already happy if the CalDAV Autoconfiguration was implemented by the Server (current-principle, home-set, aso)!
I don't know the exact handling of other CalDAV Wizards Solutions (like in ICAL or iOS). It may work for them, but not for iCal4OL, or vis-versa!
Let me know, if my assistants/wizards on tab "Who" are not working with your solution...


4)
Missing VTIMEZONE - only localtime during download in DTSTART / DTEND, if event was created in Browser Interface!
The Client(!) does interpret it in his local timezone... If the server is in a different timezone, it won't work correctly.
==> VTIMEZONE is a MUST nowadays. A lot of users are travelling, or in a different timezone than the server..


5)
CalDAV "REPORT multi-get" with time-range filter, does not work correctly!
E.g. repeating events are missing in the response, like Birthdays (which HAVE an occurrence in the time-range!).

"REPORT time-range" filter is used in iCal4OL by default, unless you specify the flag "singleget"!


6)
Repeating events
- Deleted exceptions are not working
- Moved occurrences are not working

There are some limits for modifications from Outlook itself! Not all changes may be allowed, like moving an occurrence outside of pattern begin/end, or changing the sorting (e.g. the third occurrence is moved to start before second occurrence).
Mostly, if already exceptions are present (deleted/moved), the start timestamp of the "Master" can't be changed anymore.
Some CalDAV clients can't handle the first occurrence as exception (moved or deleted) - Outlook can.


7)
CalDAV ATTENDEE's are not working
ORGANIZER;CN=Roland Scherrer:MAILTO:rscherrer@XXXXX.de
ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CN=Roland Scherrer:MAILTO:rscherrer@XXXXX.de
ATTENDEE;ROLE=REQ-PARTICIPANT;RSVP=TRUE;CN=other@XXXXX.ch:MAILTO:pcpraxis@XXXXX.ch

Nowadays, CalDAV-Scheduling Support is necessary.
iCal4OL has options (tab "1.x More" => see tab "1. How" to activate them..) to suppress attendee lines.

Flag "inbox" will activate the CalDAV-Scheduling in iCal4OL. But it's actually implemented for every solution separately.
The issue here is... Is your server using ""If-Schedule-Tag-Match:" or not?
Well, there is a a nasty bug in WinHttp, not allowing headers longer than 16 characters. Therefore WinInet.dll is the default HTTP_DLL (see tab "Options").

Note: CalDAV-Scheduling may not work with your solution. Provide a test account, so I can test and implement it as needed.
Still, a lot of other Clients have issues with CalDAV-Scheduling. There are now about 10 revisions of the spec, and not all solutions are up-to-date...

SCHEDULE=CLIENT; SCHEDULE=SERVER; SCHEDULE=NONE ... is a way to describe how email invitations are sent.
This is implemented for iCloud: iCal4OL will use SCHEDULE=CLIENT on the attendee line..


8)
Dates in e.g. <getlastmodified> and other date fields (DTSTAMP; LAST-MODIFIED; and  REV: in CardDAV), which must be in UTC (GMT) time!
Some implementations just forget to re-calculate the times and are using the local time!
Some CardDAV-SabreDAV implementation are NOT supporting <getlastmodified>, which make it impossible to "sync" contacts! Hey, <getlastmodified> is a MUST (WebDAV!!).


9)
LAST-MODIFIED just mirrored but not set by modifications on the server!

New Apple Solutions like iCloud and newest Darwin CalendarServer stopped supporting "LAST-MODIFIED:" in iCalendar Items -> don't follow this path, it's the dark side ;-)
Older versions did use wrongly(!) DTSTAMP for lastmodification time (without any LAST-MODIFIED), which was not spec conform, either! Do not copy this bug - still the dark side!

For most CalDAV Client implementation it's perhaps enough(!) to know, if an item has been changed or not.
But for a Sync Solution it becomes a nightmare... Which modification is newer??

iCal4OL can handle "by newer" (LAST-MODIFIED correctly set) or just like a real CalDAV-Client does (ETAG comparision).

iCal4OL forces the flag "older" for the iCloud, which will just test, if something has been changed.
If changed on both sides, and flag "etag" is not used, the server version will win.


(The flag "newer" (LAST-MODIFIED ignored, the OL version wins) can't work 100% correctly, due to logic issues....)

Flags "newer" or "older" can only be used, if flag "singleget", "multiget" or "sync" is present!



About all flags see http://ical.gutentag.ch/forum/viewtopic.php?id=28


If you have any questions about the correct server implementation of CalDAV/CardDAV protocol, post it here..

Regards
Roland

Last edited by Roland (2012-04-24 08:00:13)

Offline

 

Board footer