From ietf-calsify-bounces@osafoundation.org Tue May 5 13:39:32 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10493A6DBE for ; Tue, 5 May 2009 13:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruGq5quvvKkz for ; Tue, 5 May 2009 13:39:32 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 204F13A6A76 for ; Tue, 5 May 2009 13:39:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 154F6794496; Tue, 5 May 2009 13:40:59 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhYlWYDtsexv; Tue, 5 May 2009 13:40:58 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id E9789794490; Tue, 5 May 2009 13:40:55 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 21706794490 for ; Tue, 5 May 2009 13:40:53 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhq1lvFJXOSc for ; Tue, 5 May 2009 13:40:44 -0700 (PDT) Received: from mail-gx0-f158.google.com (mail-gx0-f158.google.com [209.85.217.158]) by leka.osafoundation.org (Postfix) with ESMTP id 6E35A79446A for ; Tue, 5 May 2009 13:40:44 -0700 (PDT) Received: by gxk2 with SMTP id 2so10008849gxk.3 for ; Tue, 05 May 2009 13:40:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.106.3 with SMTP id e3mr125060agc.54.1241556043745; Tue, 05 May 2009 13:40:43 -0700 (PDT) Date: Tue, 5 May 2009 16:40:43 -0400 Message-ID: From: Rick DeNatale To: ietf-calsify@osafoundation.org Subject: [ietf-calsify] Preference for multiple RDATE/EXDATE vs multiple values? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org I'm about to officially release a new ruby library for icalendar called ri_cal. Right now it's unofficially available on github at http://github.com/rubyredrick/ri_cal/tree/master Before the official release I'm trying to clean up the API for programatically creating calendars. I'm not quite sure what to do about the API for RDATE and EXDATE. The spec allows these to occur multiple times, and for each occurrence to contain one or more DATETIMEs, DATEs, or PERIODs. I was hoping that RFC2445bis would provide some guidance here since this is a complication of RFC2445, but it doesn't seem to. Is there a preference one way or another for EXDATE:20080301T120000,20080302T120000, vs EXDATE:20080301T120000 EXDATE:20080302T120000 FWIW this example* comes from a trouble report for the Apple ical.app which I found by googling: http://discussions.apple.com/thread.jspa?messageID=7315774 It looks like ical doesn't or at least didn't properly handle the multiple values per property case. Right now for properties which can appear multiple times in a component, my library provides methods of the form event.comment = "A comment" # Makes "A comment" the only comment property event.add_comment("another comment") # Adds a comment property event.add_comments("yet another comment", "still another") # adds multiple comment properties. in the case of exdate and rdate, I'm not sure whether I should allow the properties to be created with multiple values (I do handle this case on import) Now I could allow something like event.rdate = [val1, val2] # make rdate a single rdate property with two values event.add_rdate(val1, val2) # add a new rdate property with two values event.add_rdates([val1, val2], [val3, val4]) # add two rdate properties each with two different values. But this raises a question if val1 and val2 (or val3 and val4) are datetimes with different timezones, should they actually result in two rdate properties or raise an error? Is this a complication I should take on, or should I make the api work more like the comment family and just add a separate RDATE property for each value? *A secondary question is how such RDATE values in the example (which look like they should be DATE-TIMES with a floating timezone) should be handled in enumerating occurrences? Should it depend on whether or not the DTSTART of the component being enumerated has a timezone or not? -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Tue May 19 13:58:56 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BED23A6FE2 for ; Tue, 19 May 2009 13:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q--7pmc3R9-2 for ; Tue, 19 May 2009 13:58:52 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id F1F853A6FD9 for ; Tue, 19 May 2009 13:58:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id C7061794048; Tue, 19 May 2009 14:00:28 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-NteWDDeZIz; Tue, 19 May 2009 14:00:28 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 41672794030; Tue, 19 May 2009 14:00:26 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id EFA5579401C for ; Tue, 19 May 2009 14:00:22 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBlSlyJvEOST for ; Tue, 19 May 2009 14:00:12 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by leka.osafoundation.org (Postfix) with ESMTP id 8AB6E794046 for ; Tue, 19 May 2009 14:00:12 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id b38so35043ana.36 for ; Tue, 19 May 2009 14:00:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.202.8 with SMTP id z8mr894323anf.151.1242766811939; Tue, 19 May 2009 14:00:11 -0700 (PDT) Date: Tue, 19 May 2009 17:00:11 -0400 Message-ID: From: Rick DeNatale To: ietf-calsify@osafoundation.org Subject: [ietf-calsify] Calendar with no VTIMEZONE components but X-WR-TIMEZONE X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Someone pointed me to this icalendar file of Australian holidays for a test case: http://icalx.com/public/rohanl/Australian32Holidays.ics This contains NO VTIMEZONE components, but does have the calendar property: X-WR-TIMEZONE:Australia/Sydney Googling indicates that this is a non-standardized property, but it seems to be used by several calendar apps including Apple's ical.app and Google calendar. I know that it's non-standard, but it seems to be somewhat important for interoperability. I'm looking for some kind of information about what it means in general. It seems to indicate a default tzid for the whole calendar. In the absence of timezone components I'm not sure how to interpret the tzid, though. Australia/Sydney IS a time zone identifier in the Olsen database, is it standard practice to use olsen tzids in X-WR-TIMEZONE calendar attributes? I know that this is a bit off-topic for the group but I'm not sure where else to find a group of RFC 2445 experts. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu May 21 05:42:58 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3644C3A68E0 for ; Thu, 21 May 2009 05:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEmrPslLc1S7 for ; Thu, 21 May 2009 05:42:57 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 3AA203A698A for ; Thu, 21 May 2009 05:42:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id C47C977D719; Thu, 21 May 2009 05:44:22 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq8vLoLJvAzu; Thu, 21 May 2009 05:44:16 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 210FB79401B; Thu, 21 May 2009 05:44:11 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id E08C379401B for ; Thu, 21 May 2009 05:44:08 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q30m6yc8BSZ for ; Thu, 21 May 2009 05:44:00 -0700 (PDT) Received: from mail-fx0-f169.google.com (mail-fx0-f169.google.com [209.85.220.169]) by leka.osafoundation.org (Postfix) with ESMTP id 9CE6377D70F for ; Thu, 21 May 2009 05:44:00 -0700 (PDT) Received: by fxm17 with SMTP id 17so1485686fxm.27 for ; Thu, 21 May 2009 05:43:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.83.15 with SMTP id g15mr1313481fgb.64.1242909839238; Thu, 21 May 2009 05:43:59 -0700 (PDT) Date: Thu, 21 May 2009 14:43:59 +0200 Message-ID: <219d441c0905210543j31c69a6fj66322341001d8d4e@mail.gmail.com> From: Adrian Apthorp To: ietf-calsify@osafoundation.org Subject: [ietf-calsify] iCalendar VTODOs for Human Task Management X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1774307125==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --===============1774307125== Content-Type: multipart/alternative; boundary=000e0cd2559474a626046a6b7fda --000e0cd2559474a626046a6b7fda Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've been exploring the potential of using iCalendar VTODOs and calendar user agents as a means of communicating BPM orchestrated tasks to process participants. http://sourceforge.net/projects/taskcal This seems to be a natural application of the VTODO component but I don't see much if any activity in this area - hence I'm wondering if this is a dead-end...? But why create something new as in the WS-HumanTask co-ordination protocol when an existing standard could be put to use? I'm writing to this list to get a view on this use of iCalendar and on some of the gaps / questions I've identified: 1) Reason codes - adding a task reason code to a change in status adds the possibility of determining whether a task completed successfully, failed or some other condition. 2) Comment parameters - RFC 2445 on allows for basic parameters against a comment. If user wants to add a comment against a VTODO it's necessary to record date/time and user id....or is a VJOURNAL the right way to go? 3) CATEGORIES to identify the task or process. 4) Task specific input and output data and rendering - the ATTACH property seems the obvious way to communicate this, but need a standard format like XForms to handle task data so the rendering can be done locally. Also, the ATTACH property can only be updated by the organiser. Is there an opportunity here to make VTODOs a more widely used standard or have I misunderstood something? Adrian Apthorp --000e0cd2559474a626046a6b7fda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've been exploring the potential=A0of using iCalendar VTODOs and = calendar user agents as a means of communicating BPM orchestrated tasks to = process participants.
=A0
=A0
This seems to be a natural application of the VTODO component but I do= n't see much if any activity in this area - hence I'm wondering if = this is a dead-end...? But why create something new as in the WS-HumanTask = co-ordination protocol when an existing standard could be put to use?
=A0
I'm writing to this list to get a view on this use of=A0iCalendar= =A0and on some of the gaps / questions I've identified:
=A0
1) Reason codes - adding a task reason code to a change in status=A0ad= ds the possibility of determining whether a task completed successfully, fa= iled or some other condition.
=A0
2) Comment parameters - RFC 2445 on allows for basic parameters agains= t a comment. If user wants to add a comment against a VTODO it's necess= ary to record date/time and user id....or is a VJOURNAL the right way to go= ?
=A0
3) CATEGORIES to identify the task or process.
=A0
4) Task specific input and output data and rendering - the ATTACH prop= erty seems the obvious way to communicate this, but need a standard format = like XForms to handle task data so the rendering can be done locally. Also,= the ATTACH property can only be updated by the organiser.
=A0
Is there an opportunity here to make VTODOs a more widely used standar= d or have I misunderstood something?
=A0
=A0
Adrian Apthorp
=A0
=A0
=A0
--000e0cd2559474a626046a6b7fda-- --===============1774307125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============1774307125==-- From ietf-calsify-bounces@osafoundation.org Fri May 22 08:42:21 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830213A6C6E for ; Fri, 22 May 2009 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFmFcVQ9IrXw for ; Fri, 22 May 2009 08:42:19 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 5FFD93A6976 for ; Fri, 22 May 2009 08:42:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id BB36F7841ED; Fri, 22 May 2009 08:43:45 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EppIbLrga6wj; Fri, 22 May 2009 08:43:38 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 299D9794018; Fri, 22 May 2009 08:43:34 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 35CC77841F2 for ; Fri, 22 May 2009 08:43:33 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pldBdyCye88L for ; Fri, 22 May 2009 08:43:24 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by leka.osafoundation.org (Postfix) with ESMTP id 1106A7841ED for ; Fri, 22 May 2009 08:43:23 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1304839yxg.81 for ; Fri, 22 May 2009 08:43:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.144.14 with SMTP id r14mr7610258and.120.1243007003115; Fri, 22 May 2009 08:43:23 -0700 (PDT) Date: Fri, 22 May 2009 11:43:22 -0400 Message-ID: From: Rick DeNatale To: ietf-calsify@osafoundation.org Subject: [ietf-calsify] Mixed line delimiters X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org I'm a bit confused by how to handle escaping/unescaping line delimiters in icalendar data. I got a bug report from a user who is setting the description of an event to a string containing \r\n line breaks. Section 3 of RFC2445 and RFC2445bis both imply that lines are delimited by the \r\n combination. Although I think I've seen more usage of the posix style \n alone. Then in Section 3.3.11, it states that: An intentional formatted text line break MUST only be included in a "TEXT" property value by representing the line break with the character sequence of BACKSLASH (US-ASCII decimal 92), followed by a LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL LETTER N (US-ASCII decimal 78), that is "\n" or "\N". Should I read "intentional formatted line break" as being anyone of several characters or character sequences coming from the user? In other words when escaping the value of a TEXT property, should I convert anything which matches \n, \r\n, \r\n, or just \r to \n, or \N And is there a semantic difference between \n and \N -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri May 22 13:18:41 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E65D3A6927 for ; Fri, 22 May 2009 13:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRxo+AUX56BA for ; Fri, 22 May 2009 13:18:39 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id EAA123A6962 for ; Fri, 22 May 2009 13:18:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id B213D77D718; Fri, 22 May 2009 13:20:16 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcz4fb5D4tRE; Fri, 22 May 2009 13:20:10 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 445D477D714; Fri, 22 May 2009 13:20:07 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id EA36C77D709 for ; Fri, 22 May 2009 13:20:03 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhXf6t4X5G8H for ; Fri, 22 May 2009 13:19:56 -0700 (PDT) Received: from rgminet11.oracle.com (rcsinet11.oracle.com [148.87.113.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id DED7477D708 for ; Fri, 22 May 2009 13:19:55 -0700 (PDT) Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4MKKQEX009185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 May 2009 20:20:28 GMT Received: from hqdfmt02.oracle.com (hqdfmt02.oracle.com [148.87.35.12]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n4MKJxOO018981; Fri, 22 May 2009 20:20:01 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 22 May 2009 13:19:48 -0700 Message-ID: <4A1708E1.9040701@oracle.com> Date: Fri, 22 May 2009 16:19:45 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Rick DeNatale References: In-Reply-To: X-Source-IP: hqdfmt02.oracle.com [148.87.35.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4A1708E7.004F:SCFSTAT3499757,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] Mixed line delimiters X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Rick DeNatale wrote: > I'm a bit confused by how to handle escaping/unescaping line > delimiters in icalendar data. > > I got a bug report from a user who is setting the description of an > event to a string containing \r\n line breaks. > > Section 3 of RFC2445 and RFC2445bis both imply that lines are > delimited by the \r\n combination. Although I think I've seen more > usage of the posix style \n alone. > > Then in Section 3.3.11, it states that: > > An intentional formatted text line break MUST only be included in > a "TEXT" property value by representing the line break with the > character sequence of BACKSLASH (US-ASCII decimal 92), followed by > a LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL > LETTER N (US-ASCII decimal 78), that is "\n" or "\N". > > Should I read "intentional formatted line break" as being anyone of > several characters or character sequences coming from the user? In > other words when escaping the value of a TEXT property, should I > convert anything which matches \n, \r\n, \r\n, or just \r to \n, or \N Yes. > > And is there a semantic difference between \n and \N > > No. Cheers, Bernard _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 21706794490 for ; Tue, 5 May 2009 13:40:53 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[AWL=0.001, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhq1lvFJXOSc for ; Tue, 5 May 2009 13:40:44 -0700 (PDT) Received: from mail-gx0-f158.google.com (mail-gx0-f158.google.com [209.85.217.158]) by leka.osafoundation.org (Postfix) with ESMTP id 6E35A79446A for ; Tue, 5 May 2009 13:40:44 -0700 (PDT) Received: by gxk2 with SMTP id 2so10008849gxk.3 for ; Tue, 05 May 2009 13:40:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.106.3 with SMTP id e3mr125060agc.54.1241556043745; Tue, 05 May 2009 13:40:43 -0700 (PDT) Date: Tue, 5 May 2009 16:40:43 -0400 Message-ID: From: Rick DeNatale To: ietf-calsify@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ietf-calsify] Preference for multiple RDATE/EXDATE vs multiple values? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 20:40:53 -0000 I'm about to officially release a new ruby library for icalendar called ri_cal. Right now it's unofficially available on github at http://github.com/rubyredrick/ri_cal/tree/master Before the official release I'm trying to clean up the API for programatically creating calendars. I'm not quite sure what to do about the API for RDATE and EXDATE. The spec allows these to occur multiple times, and for each occurrence to contain one or more DATETIMEs, DATEs, or PERIODs. I was hoping that RFC2445bis would provide some guidance here since this is a complication of RFC2445, but it doesn't seem to. Is there a preference one way or another for EXDATE:20080301T120000,20080302T120000, vs EXDATE:20080301T120000 EXDATE:20080302T120000 FWIW this example* comes from a trouble report for the Apple ical.app which I found by googling: http://discussions.apple.com/thread.jspa?messageID=7315774 It looks like ical doesn't or at least didn't properly handle the multiple values per property case. Right now for properties which can appear multiple times in a component, my library provides methods of the form event.comment = "A comment" # Makes "A comment" the only comment property event.add_comment("another comment") # Adds a comment property event.add_comments("yet another comment", "still another") # adds multiple comment properties. in the case of exdate and rdate, I'm not sure whether I should allow the properties to be created with multiple values (I do handle this case on import) Now I could allow something like event.rdate = [val1, val2] # make rdate a single rdate property with two values event.add_rdate(val1, val2) # add a new rdate property with two values event.add_rdates([val1, val2], [val3, val4]) # add two rdate properties each with two different values. But this raises a question if val1 and val2 (or val3 and val4) are datetimes with different timezones, should they actually result in two rdate properties or raise an error? Is this a complication I should take on, or should I make the api work more like the comment family and just add a separate RDATE property for each value? *A secondary question is how such RDATE values in the example (which look like they should be DATE-TIMES with a floating timezone) should be handled in enumerating occurrences? Should it depend on whether or not the DTSTART of the component being enumerated has a timezone or not? -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale