Re: .ics export violates RFC2445

[Carsten Dominik <dominik@science.uva.nl>]

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

> Carsten Dominik (carsten.dominik@gmail.com) 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.