From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: .ics export violates RFC2445 Date: Thu, 15 May 2008 10:33:17 +0200 Message-ID: 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> <20080429171635.GB9068@atlantic.linksys.moosehall> Mime-Version: 1.0 (Apple Message framework v919.2) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JwYtx-0005HI-CM for emacs-orgmode@gnu.org; Thu, 15 May 2008 04:33:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JwYtw-0005Gx-PH for emacs-orgmode@gnu.org; Thu, 15 May 2008 04:33:24 -0400 Received: from [199.232.76.173] (port=59595 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JwYtw-0005Gr-4b for emacs-orgmode@gnu.org; Thu, 15 May 2008 04:33:24 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]:36120) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JwYtv-0005ar-N5 for emacs-orgmode@gnu.org; Thu, 15 May 2008 04:33:24 -0400 Received: by ug-out-1314.google.com with SMTP id l31so1532242ugc.48 for ; Thu, 15 May 2008 01:33:22 -0700 (PDT) In-Reply-To: <20080429171635.GB9068@atlantic.linksys.moosehall> 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: Adam Spiers Cc: org-mode mailing list On Apr 29, 2008, at 7:16 PM, Adam Spiers wrote: >>> 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. Please get the latest GIT version of Org. Then set the variable (setq org-icalendar-force-UID t) and try to export to iCalendar. Right now, I am only forcing and using the ID for VEVENT. I am not using it for VTODO, because I am not sure if it is allowed to have the same UID for a VEVENT and a VTODO, if they originate from the same entry in a database? Do you or anyone else know what the rules are for this? - Carsten