Abstract: VCard and ICal are definitions of text-based PIM information in files. In OX terms, VCard defines contact data, while ICal defines both Tasks and Appointments. ICal internally identifies itself as VCalendar 2.0, which illustrates who closely related both protocols are. That is why questions on both formats are answered in one article.
This article deals with features that are in VCard and ICal but are problematic within the OX. This also applies to CardDAV and CalDAV, because those services are also based on these two formats.
ICal allows you to define an appointment which occurs "the second last sunday every month". OX simply does not. We only support counting from the beginning of a month, but not from the end. Since a month might have either four or five occurrences of a certain day, it is not possible for us to simply convert this.
Behavior: An ICal appointment containing this property is not imported.
ICal allows you to set an alarm which should be repeated four times before ending. This might be interesting for an alarm clock, but for a web-based tool with will be used asynchronous in most cases, we handle this differently. Therefore, OX does not support an ALARM with a REPEAT property.
Behavior: This property is ignored.
Reference: RFC 2445, 220.127.116.11 Repeat count
The basic problem: Open-Xchange only supports a fixed set of fields. VCards and ICals, on the other hand, allow for a theoretically unlimited amount of fields, sometimes by adding different types (thereby changing the semantic information, e.g. home and business addresses), sometimes by simply something (e.g. exceptions to an appointment series). This works in most cases (e.g. for appointment series) but not in others (see below).
Open-Xchange only supports one URL per user. VCards allow several. URL is not supported.
As said, Open-Xchange only supports a fixed set of phone number fields, all of which have a semantic meaning (so they are not used to store other phone numbers even if space is needed). VCards, on the other hand, allow for a theoretically unlimited amount of phone numbers via different type combinations (or repeating the same one, too).
In practice this is usually not much of a problem, for people do not have that many, but for all who are interested in the details:
This is how we map VCard fields to HTTP_API (OX contact fields):
|VCard type||OX column number||OX field name||Fallback OX fields||Fallback OX field names|
|cell||551||cellular_telephone1||552, 553||cellular_telephone2, telephone_other|
|voice,work||542||telephone_business1||543, 547, 553||telephone_business2, telephone_company, telephone_other|
|voice,home||548||telephone_home1||589, 553||telephone_home2, telephone_other|
|voice||542||telephone_business1||543, 547, 548, 589, 553||telephone_business2, telephone_company, telephone_home1, telephone_home2, telephone_other|
|fax||544||fax_business||550, 554||fax_home, fax_other|
Distribution lists are specific to OX. VCards do not really have a functional equivalent. So the export of distribution lists is not supported.
These are just the field names as given the the RFCs, since we are unable to guess what they will be called in the client app.
ATTACH, COMMENT, CONTACT, CREATED, DTSTAMP, EXRULE, GEO, ORGANIZER, PRIORITY, RDATE, REQUEST-STATUS, STATUS
GEO, KEY, LABEL, LOGO, MAILER, NAME, PRODID, PROFILE, REV, SORT-STRING, SOUND, SOURCE, TZ
ATTACH, COMMENT, CONTACT, EXDATE, EXRULE, GEO, LOCATION, ORGANIZER, REQUEST-STATUS, RESOURCES, RDATE, URL