Open goblin opened 3 years ago
According to rfc2445, regarding the "UID" property:
The current iCalendar standard is RFC5545, but the text is the same.
The fix is obviously to pass
--export-uid
when exporting, but that's too obscure and should be on by default, because without it, the exported iCal files are not RFC-compliant.
Unfortunately it is not as obvious as you might think, because --export-uid
serves a particular purpose for calcurse-caldav.
Calcurse v4.7.0 included several updates to import/export of iCal files (which I wrote), but mandatory export of UID were left out after an email exchange with @lfos. The reason being that UID is used for CalDAV synchronization. This usage conflicts with the RFC5545 requirement that UID must be a globally unique identifier.
@lfos, is there any particular reason why the UID property is used for CalDAV synchronization?
RFC5545 allows the definition of non-standard properties: https://tools.ietf.org/html/rfc5545#section-3.8.8.2.
Why not define a calcurse-specific property, X-CALCURSE-UID
, for synchronization purposes?
The current iCalendar standard is RFC5545, but the text is the same.
I got rfc2445 from https://calcurse.org/files/manual.html, perhaps it needs to be updated BTW.
@goblin, indeed.
The manual (doc/manual.txt
) has not been regularly maintained for several years (five or six), and an update is a major task. Do not rely upon it.
The man-page (doc/calcurse.1.txt
) is up to date, but covers only command line use.
According to rfc2445, regarding the "UID" property:
Trying to import an ical file to Korganizer which was exported without
--export-uid
doesn't work and results in this error on the console:So here I am, reporting it.
The fix is obviously to pass
--export-uid
when exporting, but that's too obscure and should be on by default, because without it, the exported iCal files are not RFC-compliant.The switch should probably remain there for backwards compatibility, but it should be a no-op when exporting to iCal.