About CalDAV

Bernhard Reiter bernhard at intevation.de
Fri Jan 14 11:49:56 CET 2005


On Wednesday 12 January 2005 01:17, Helge Hess wrote:
> On 11. Jan 2005, at 12:13 Uhr, Martin Konold wrote:

> Since you claim that the standard is precise enough for doing
> invitations I'm surprised that you claim it isn't precise enough for
> storage. Isn't exactly the same precision required to perform correct
> iMIP?

Not really, as many clients are used to deal with incomplete data
and users are more likely to accept minor problems.
Beside: It is a widely used standards for invitations.

> Also I would be interested in
> b) what exactly is duplicate in iCalendar (please give an example of a
> construct  which expresses the same fact)
> b) what isn't precise enough - saying that there are multiple manners
> to express
>     the same is not the same like precision. The latter only requires
> that all
>     variants are precisely specified. To my best knowledge this is the
> case.
>
> iCalendar is quite complex, but this isn't because it duplicates stuff
> but because it models an extremely wide range of real world calendaring
> issues.

The complexity is a problem, you can find quite some discussions
in the kolab format list.

> Of course there are few (no?) clients
> which implement iCalendar completely. But since you only talk about
> Kolab clients, you could have used a specified subset of iCalendar
> which is implemented instead of doing something completely new from
> scratch.

Again reasons for this can be found in the archives
of  the kolab format list.
Using a subset of iCalendar and adding your own specification
would have made it a different format, while pretending to be
iCalendar. Nobody that started to come up with a compliant standard
solving all the problems coud do it.
So while we have put more than 20 qualified person days into
two attempts we claim the right to reverse the challenge.
Show us a draft spec solving the problems partly outlined in kolab format
and we reconsider.

> Of course the fixed iCalendar standard does exist. It just isn't
> implemented fully by anyone. Nitpicking, result is the same of course
> ;-)

Yes, it shows that something about iCalendar is suboptimal
and hard to describe and fix.
 
> >> I have another Q:
> >> Q: Why not the xCal draft?
> >
> > It is unfortunately incomplete for our purposes. (Mainly OL stuff
> > missing)
>
> Just out of interest, could you give some examples on Outlook features
> which you support in Kolab/XML are missing in xCal?

I guess you can also construct examples from the kolab-format archive.

Best,
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/users/attachments/20050114/c5921b80/attachment.p7s>


More information about the users mailing list