emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] .ics export violates RFC2445


From: Carsten Dominik
Subject: Re: [Orgmode] .ics export violates RFC2445
Date: Tue, 29 Apr 2008 17:52:40 +0200


On Apr 29, 2008, at 4:12 PM, Adam Spiers wrote:

Carsten Dominik (address@hidden) wrote:
On  7Nov2007, at 9:56 PM, Adam Spiers wrote:
I use org-export-icalendar-combine-agenda-files to export my
appointments to an .ics file which I point korganizer at.

I noticed ages ago that if I have an appointment with a comma in,
e.g.:

** <2007-12-07 Fri 20:00> foo, bar

korganizer always shows it as "bar" rather than "foo, bar".  But I
never got round to investigating whether it was a bug with the export or korganizer or something else ... until now :-) I just took a quick look at the iCalendar spec, which is RFC2445, and discovered that the
SUMMARY field is defined as follows

 summary    = "SUMMARY" summparam ":" text CRLF

  -- from http://tools.ietf.org/html/rfc2445#section-4.8.1.12

And the definition of 'text' in this context explicitly states that
several characters, including commas, need to be escaped with a
backslash:

 http://tools.ietf.org/html/rfc2445#section-4.3.11

Sure enough, when I edited the .ics file and manually escaped the
comma, korganizer displayed the summary correctly.

fixed, thanks

- Carsten

This appears to have regressed in some recent version ...

Yes, seems there was still a bug.  Fixed now.


Also, it would be great if a UID field could be generated for each
event, perhaps by checksumming the contents of the event in some way.
The RFC says:

  Conformance: The property MUST be specified in the "VEVENT",
  "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.

    -- http://tools.ietf.org/html/rfc2445#section-4.8.4.7

The checksum would ensure that the UID field only changes when the
event details check, which would be a first step towards helping
synchronisation systems.  I'm vaguely suspicious that the lack of UIDs
currently confuses Google Calendar too.

A UID may be good.  However I think changing the UID when changing the
entry would be bad, because this would exactly *disable* synchronization.
To synchronize, you must know which entries to compare, and this is only
possible with a persistent UID.

I guess we could create one, but this UID would then have to be stored in the entry, as a property. Exporting to ical again must then re-use the old uid each time.

My org-id.el in the contrib directory allows already to create unique
identifiers, and it would be easy enough to include the domain to make them truely
unique, wordwide.

However, right now I am hesitating to force a property drawer onto every entry that ever is exported to iCalendar. But as an option, this might really be
good and eventually allow true synchronization.

- Carsten

P.S. Adam, I emailed you twice privately in the last few weeks, but
did not get any reply.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]