Hi Ingo,

Thanks for reporting this issue.

I assumed that you were still using eGroupWare so started testing with it and compared with DaviCal. I can only reproduce this issue with eGroupware at the moment, but it seems that the iCalendar data that it generates when creating an event (from Lightning here) is not well accepted by KCalCore when read by the resource.

I'll have a closer look at it and keep you informed.

Cheers,
Grégory

This turned out to be pretty quick to narrow down. When creating an event with an attendee (or more, that works the same way), eGroupware rewrites the event and in particular the ATTENDEE properties. I couldn't find how the rewrite is done but for sure if you only specify an email address you end up with an invalid (as from two iCalendar validators I've tested) VEVENT that contains an EMAIL property that doesn't seem to be part of the standard (RFC5545).

If that works with an iPhone is likely due to a more lax validation. So either KCalCore is modified to accept this data (I'm not eager to add some specific workarounds, and it's unlikely to be well accepted by other devs), or I nag eGroupware devs to have this fixed. Guess what I'll do ? :)

I'll keep you informed via this report.

Cheers,
Grégory

Hi Grégory,

Hmm, guess what happened since the update of egroupware to latest dev trunk?
Akonadiconsole shows rawpaylod:
ATTENDEE;CN="Ratsdorf Ingo";RSVP=FALSE;PARTSTAT=ACCEPTED;
 ROLE=REQ-PARTICIPANT;X-UID=addressbook-2-cbd2bc7d9e888bb71460725c836b157f:
 mailto:ingo@envirology.co.nz

Bingo!
It would appear that the issue can be closed now. It was with egroupware and not KCalCore.

Cheers for the quick reply.

Cheers,
Ingo

Hi.

Sorry, I had to reopen this bug again.
The above is actually from KCalCore before it has been saved to egroupware.

Somethings that comes straight from egroupware is the following example.
And this will _NOT_ parsed by KCalCore.The attendee info will be deleted.

DTSTART;TZID=Pacific/Auckland:20110903T110000
DTEND;TZID=Pacific/Auckland:20110903T113000
ATTENDEE;CN=Ingo
  Ratsdorf;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CUTYPE=INDIVIDUAL;RSVP=FA
 LSE;EMAIL=***@envirology.co.nz;X-EGROUPWARE-UID=5:MAILTO:***@envirology.c
 o.nz
ATTENDEE;CN=Tatjana
  Ratsdorf;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CUTYPE=INDIVIDUAL;RSVP=FA
 LSE;EMAIL=***@envirology.co.nz;X-EGROUPWARE-UID=8:MAILTO:***@enviro
 logy.co.nz
ATTENDEE;CN=Jolan
  Ratsdorf;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL;RSVP=FAL
 SE;EMAIL=***@envirology.co.nz;X-EGROUPWARE-UID=11:MAILTO:***@envirology
 .co.nz
RRULE:FREQ=WEEKLY;BYDAY=SA;UNTIL=20110930T221500Z

I cannot find anything in the above that does not comply with RFC5545.
Can you?

Please see also Bug 282591 FYI.

Regards,
Ingo

Hi Ingo,

Yes, the culprit seems to be the 'EMAIL' property. I can't find it in the RFC at this place (it can be an action parameter to a 'VALARM', quoting with the RFC at hand). And it's also this parameter that is reported by one of the iCalendar validators I've tested (the other one crashed…).

My best guess is that 'EMAIL:test@test.com' the iCalendar data should be 'CN=test@test.com:MAILTO=test@test.com' if the CN can't be found. I'll contact the eGw devs with this and use this bug to communicate around this issue.

Cheers,
Grégory

Hi,

I agree that the 'EMAIL' property is not part of the pre described set of properties under the rfc spec, however, please note that the spec allows for 'other-param':

attendee   = "ATTENDEE" attparam ":" cal-address CRLF

       attparam   = *(
                  ;
                  ; The following are OPTIONAL,
                  ; but MUST NOT occur more than once.
                  ;
                  (";" cutypeparam) / (";" memberparam) /
                  (";" roleparam) / (";" partstatparam) /
                  (";" rsvpparam) / (";" deltoparam) /
                  (";" delfromparam) / (";" sentbyparam) /
                  (";" cnparam) / (";" dirparam) /
                  (";" languageparam) /
                  ;
                  ; The following is OPTIONAL,
                  ; and MAY occur more than once.
                  ;
                  (";" other-param)
                  ;
                  )

So to me the use of 'EMAIL' is totally legal and within the spec. I would assume that the devs in egroupware had a reason to include that property, which is effectively a double-up to 'MAIL-TO'.
Maybe some other client does not work without it? One that is not-compliant?
I realise that 'EMAIL' has a special meaning in other parts of the spec, however, for 'ATTENDEE' I cannot see it being illegal to use.

So as it stands, I see that KCalCore being too picky with it's parsing.

Cheers,
Ingo

Hi Ingo,

The 'other-param' is either a 'X-' property, that is correctly dealt with, or a IANA registered property. I couldn't find any on their website and have no idea how this should be treated by KCalCore. Maybe it would be better ignoring it and keeping it in the ATTENDEE.

Cheers,
Grégory

Hi,

After some debugging it appears that KCalCore removes the attendee because libical is unable to parse it. I guess it chokes on this property, and a fix must be done both in libical and in KCalCore.

Cheers,
Grégoy

In summary: some non-KOrganizer application is putting the non-standard EMAIL parameter into an attendee property.  so we need 1) libical to silently skip the non-standard parameters and 2) we need KCalCore to go along as well.

it is possible that 1) is already fixed in modern versions of libical.  someone needs to check libical 0.46

I have the latest kubuntu with KDE 4.7.1 and libical 0.44-3 and at least that combination is buggy.
I have patched egroupware to not include the EMAIL parameter and can confirm that it's working then.
However, as outlined before, illegal or unexpected or unknown parameters should rather be ignored when not used by KCalCore, even better stored with the event and returned on updates.

Please see also Bug 282591 regarding a not parsed FBURL, a bug that is present for years.

Hi Allen,

libical 0.46 is still unable to parse the ATTENDEE (the event fails the check at line 1319 of icalformat_p.cpp)

Cheers,
Grégory

I would appreciate a backtrace showing where in libical the crash happens.  I might be able to get a fix into libical for the 0.48 release which is coming very soon.

Hi Allen,

There's no crash. The ATTENDEE properties that libical is not able to parse are simply removed in kcalcore/icalformat_p.cpp. Here it's triggered by the presence of an unknown property (EMAIL), but the general fix would be to have these properties kept as is done with the X- params.

Cheers,
Grégory

According to my testing, libical 0.47 no longer returns a failure from icalproperty_get_value() on ATTENDEEs with unknown properties.

So... I think KCalCore will "simply work" once folks start using libical 0.47 and there's nothing I will do in KCalCore to support the non-RFC properties.  As Grégory points out, the way out of that is with X- properties.

This is fixed then, from a KDE point-of-view.  At least the attendee won't get lost.

How, that would be so cool.
Only issue is that ubuntu is still shipping libical 0.43... :-(
Might have to compile myself then. Hate it.

Allan, could I then off-topic point you to Bug #282591 regarding a not parsed FBURL, a bug that is present for years.

Ahh, ignore the last one, it's actually bug Bug #282761.
Sorry having so many open.... ;-)