From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Spiers Subject: Re: .ics export violates RFC2445 Date: Tue, 29 Apr 2008 18:16:35 +0100 Message-ID: <20080429171635.GB9068@atlantic.linksys.moosehall> References: <20071107205621.GT13544@atlantic.linksys.moosehall> <2DE7990C-2666-430E-91F5-B34C4A35699D@science.uva.nl> <20080429141240.GA9068@atlantic.linksys.moosehall> <2989BE0D-4A88-4DEC-B6A2-66B08661942F@science.uva.nl> Reply-To: Adam Spiers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JqtRZ-0006vi-Dv for emacs-orgmode@gnu.org; Tue, 29 Apr 2008 13:16:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JqtRY-0006vB-Hb for emacs-orgmode@gnu.org; Tue, 29 Apr 2008 13:16:41 -0400 Received: from [199.232.76.173] (port=37092 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JqtRY-0006v1-21 for emacs-orgmode@gnu.org; Tue, 29 Apr 2008 13:16:40 -0400 Received: from mail.beimborn.com ([70.84.38.100]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JqtRX-0002qQ-HU for emacs-orgmode@gnu.org; Tue, 29 Apr 2008 13:16:39 -0400 Received: from mail.beimborn.com (localhost.localdomain [127.0.0.1]) by mail.beimborn.com (8.12.11.20060308/8.12.8) with ESMTP id m3THGcWt022298 for ; Tue, 29 Apr 2008 12:16:38 -0500 Received: from localhost (localhost [[UNIX: localhost]]) by mail.beimborn.com (8.12.11.20060308/8.12.11/Submit) id m3THGbE8022292 for emacs-orgmode@gnu.org; Tue, 29 Apr 2008 18:16:37 +0100 Content-Disposition: inline In-Reply-To: <2989BE0D-4A88-4DEC-B6A2-66B08661942F@science.uva.nl> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: org-mode mailing list Carsten Dominik (dominik@science.uva.nl) wrote: > 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. Works great, thanks! > >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. Doh - you are right of course. > 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. I understand your hesitation - as an option that sounds perfect. I forgot to mention before that gcaldaemon http://gcaldaemon.sourceforge.net/ which is a very nice piece of software indeed, requires the UID field. If you provided that, then gcaldaemon would give us the solution to at least unidirectional synchronisation with Google Calendar. I have experimented with simply scp'ing the generated .ics file to a private location on my webserver and pointing Google Calendar at that private URL, but there is no way to force Google Calendar to reload the data after subsequent scp invocations. > P.S. Adam, I emailed you twice privately in the last few weeks, but > did not get any reply. Hrm :-/ I have issues with private mail currently due to receiving between 5,000 and 10,000 spam a day (not to mention being busy and still having yet to perfect GTD ;-). However I just replied to a couple of recent ones - were they the ones you were referring to?