From ietf-calsify-bounces@osafoundation.org Mon Nov 3 08:09:03 2008 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 4657E3A6C90 for ; Mon, 3 Nov 2008 08:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_56=0.6, J_CHICKENPOX_74=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 mShbL34ouRoU for ; Mon, 3 Nov 2008 08:09:02 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [64.127.108.190]) by core3.amsl.com (Postfix) with ESMTP id 77A823A6BF2 for ; Mon, 3 Nov 2008 08:08:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id DD8ED794032; Mon, 3 Nov 2008 08:08:27 -0800 (PST) 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 d8iSL4eVDrSQ; Mon, 3 Nov 2008 08:08:27 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 164D7794020; Mon, 3 Nov 2008 08:08:25 -0800 (PST) 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 AEE0F794020; Mon, 3 Nov 2008 08:08:16 -0800 (PST) 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 X4+I-TLMjySi; Mon, 3 Nov 2008 08:08:14 -0800 (PST) Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 12DDC794018; Mon, 3 Nov 2008 08:08:13 -0800 (PST) Received: from rgminet15.oracle.com (mail-router.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mA3G8AbM008975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Nov 2008 16:08:12 GMT Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mA3G7q8V025180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 16:08:00 GMT Received: from acsmt700.oracle.com (acsmt700.oracle.com [141.146.40.70]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id mA3FkMWc008688; Mon, 3 Nov 2008 08:46:22 -0700 Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Nov 2008 15:46:21 +0000 Message-ID: <490F1CCC.9040605@oracle.com> Date: Mon, 03 Nov 2008 10:46:20 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Daniel Gomez Brito References: <98357389BF0844489B5D6FD186C720489F160C@GMVMAIL1.gmv.es> In-Reply-To: <98357389BF0844489B5D6FD186C720489F160C@GMVMAIL1.gmv.es> X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Source-IP: rgmgw1.us.oracle.com [138.1.186.110] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010203.490F21E0.009D:SCFSTAT928724,ss=1,fgs=0 Cc: IETF Calsify , ietf-caldav@osafoundation.org Subject: Re: [ietf-calsify] [ietf-caldav] Question about recurring tasks. 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="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi Daniel, In section 4.8.5.4 Recurrence Rule of RFC 2445 it says: > The recurrence set is generated by considering the initial "DTSTART" > property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" > properties contained within the iCalendar object. As such, the "DTSTART" should always be specified in a calendar = component that also specify the "RRULE" property. That being said, this should probably be stated more clearly in rfc2445bis. To be very clear, in iCalendar recurrence instances of a recurring = "VTODO" are not computed based on the "DUE" property of the master = component. So to answer your question, a strict implementation should handle a = recurring task with no "DTSTART" as an invalid "VTODO" component, and a = relax implementation could probably fix the invalid "VTODO" component by = adding the missing "DTSTART" property with the same value as "DUE". Cheers, Bernard Daniel Gomez Brito wrote: > Hello: > = > = > = > What=92s the proper way to treat a recurring task with no dtstart propert= y? > = > It doesn=92t make sense to me but it seems there=92s a bunch of portable = > devices that let you build something like this: > = > = > = > BEGIN:VCALENDAR > = > VERSION:2.0 > = > PRODID:-//Test//Ver 1.0.0 //ES > = > BEGIN:VTODO > = > SUMMARY:cxcx > = > DESCRIPTION:xcx > = > CATEGORIES: > = > CLASS:PUBLIC > = > DUE;VALUE=3DDATE:20081030 > = > PRIORITY:5 > = > ORGANIZER: > = > PERCENT-COMPLETE:0 > = > STATUS:NEEDS-ACTION > = > RRULE:FREQ=3DWEEKLY;INTERVAL=3D1;BYDAY=3DTH > = > X-FUNAMBOL-FOLDER:DEFAULT_FOLDER > = > X-FUNAMBOL-ALLDAY:1 > = > UID:20081028T082036Z-2 > = > DTSTAMP:20081028T082035Z > = > END:VTODO > = > END:VCALENDAR > = > = > = > Regards. > = > = > = > ------------------------------------------------------------------------ > Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede = > contener informaci=F3n clasificada por su emisor como confidencial en el = > marco de su Sistema de Gesti=F3n de Seguridad de la Informaci=F3n siendo = > para uso exclusivo del destinatario, quedando prohibida su divulgaci=F3n = > copia o distribuci=F3n a terceros sin la autorizaci=F3n expresa del = > remitente. Si Vd. ha recibido este mensaje err=F3neamente, se ruega lo = > notifique al remitente y proceda a su borrado. Gracias por su colaboraci= =F3n. > ------------------------------------------------------------------------ > This message including any attachments may contain confidential = > information, according to our Information Security Management System, = > and intended solely for a specific individual to whom they are = > addressed. Any unauthorised copy, disclosure or distribution of this = > message is strictly forbidden. If you have received this transmission in = > error, please notify the sender immediately and delete it. > = > ------------------------------------------------------------------------ > = > = > ------------------------------------------------------------------------ > = > _______________________________________________ > ietf-caldav mailing list -- ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Nov 3 11:14:46 2008 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 506EB3A696C for ; Mon, 3 Nov 2008 11:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.228 X-Spam-Level: X-Spam-Status: No, score=0.228 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_74=0.6, MIME_QP_LONG_LINE=1.396] 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 vxKfTxjbgqbQ for ; Mon, 3 Nov 2008 11:14:45 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [64.127.108.190]) by core3.amsl.com (Postfix) with ESMTP id 457CD3A6846 for ; Mon, 3 Nov 2008 11:14:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id B7FA8794031; Mon, 3 Nov 2008 11:14:43 -0800 (PST) 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 KmaM8BuEPneh; Mon, 3 Nov 2008 11:14:43 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id F35DE79402F; Mon, 3 Nov 2008 11:14:41 -0800 (PST) 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 B43C8794018; Mon, 3 Nov 2008 11:14:29 -0800 (PST) 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 8Y0nAVhK3AD4; Mon, 3 Nov 2008 11:14:25 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id D1B6677D70E; Mon, 3 Nov 2008 11:14:25 -0800 (PST) Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id mA3HtECF025482; Mon, 3 Nov 2008 12:14:15 -0700 Received: from acsmt700.oracle.com (acsmt700.oracle.com [141.146.40.70]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id mA3G3VIQ013486; Mon, 3 Nov 2008 09:03:31 -0700 Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Nov 2008 16:03:30 +0000 Message-ID: <490F20D1.2060006@oracle.com> Date: Mon, 03 Nov 2008 11:03:29 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Daniel Gomez Brito References: <98357389BF0844489B5D6FD186C720489F160C@GMVMAIL1.gmv.es> <490F1CCC.9040605@oracle.com> In-Reply-To: <490F1CCC.9040605@oracle.com> X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Cc: IETF Calsify , ietf-caldav@osafoundation.org Subject: Re: [ietf-calsify] [ietf-caldav] Question about recurring tasks. 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="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org BTW, I just found the following info in the Calsify Working Group = Minutes for July 12, 2006: http://www.ietf.org/proceedings/06jul/minutes/calsify.txt > 7 Is DTSTART required in VTODO and VJOURNAL components when the RRULE > or EXRULE properties are defined in those components? > > Cyrus floated another idea that in the case of VTODO, perhaps the > recurrence could use the DUE property. Bernard suggested that perhaps > in the absence of DTSTART, it could default to DUE. > > Lisa pointed out that this needs more discussion beyond the room, > because different apps behave differently. > > In the end, some agreement that it's enough to clarify that for > recurring VTODOs, VJOURNALs, etc., they MUST specify DTSTART even > if it's otherwise optional. > > AI: Go forward with above clarification The clarification (issue 24) was made in the section that covers = "DTSTART", see: http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-c= alsify-rfc2445bis-09.changes.html#rfc.issue.#issue29+dtstart_in_recur_vtodo= _and_vjournal I believe similar text should appear in the "RRULE" section as well... Cheers, Bernard Bernard Desruisseaux wrote: > Hi Daniel, > = > In section 4.8.5.4 Recurrence Rule of RFC 2445 it says: > = > > The recurrence set is generated by considering the initial "DTSTART" > > property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" > > properties contained within the iCalendar object. > = > As such, the "DTSTART" should always be specified in a calendar = > component that also specify the "RRULE" property. > = > That being said, this should probably be stated more clearly in rfc2445bi= s. > = > To be very clear, in iCalendar recurrence instances of a recurring = > "VTODO" are not computed based on the "DUE" property of the master = > component. > = > So to answer your question, a strict implementation should handle a = > recurring task with no "DTSTART" as an invalid "VTODO" component, and a = > relax implementation could probably fix the invalid "VTODO" component by = > adding the missing "DTSTART" property with the same value as "DUE". > = > Cheers, > Bernard > = > Daniel Gomez Brito wrote: >> Hello: >> >> = >> >> What=92s the proper way to treat a recurring task with no dtstart proper= ty? >> >> It doesn=92t make sense to me but it seems there=92s a bunch of portable = >> devices that let you build something like this: >> >> = >> >> BEGIN:VCALENDAR >> >> VERSION:2.0 >> >> PRODID:-//Test//Ver 1.0.0 //ES >> >> BEGIN:VTODO >> >> SUMMARY:cxcx >> >> DESCRIPTION:xcx >> >> CATEGORIES: >> >> CLASS:PUBLIC >> >> DUE;VALUE=3DDATE:20081030 >> >> PRIORITY:5 >> >> ORGANIZER: >> >> PERCENT-COMPLETE:0 >> >> STATUS:NEEDS-ACTION >> >> RRULE:FREQ=3DWEEKLY;INTERVAL=3D1;BYDAY=3DTH >> >> X-FUNAMBOL-FOLDER:DEFAULT_FOLDER >> >> X-FUNAMBOL-ALLDAY:1 >> >> UID:20081028T082036Z-2 >> >> DTSTAMP:20081028T082035Z >> >> END:VTODO >> >> END:VCALENDAR >> >> = >> >> Regards. >> >> = >> >> ------------------------------------------------------------------------ >> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede = >> contener informaci=F3n clasificada por su emisor como confidencial en el = >> marco de su Sistema de Gesti=F3n de Seguridad de la Informaci=F3n siendo = >> para uso exclusivo del destinatario, quedando prohibida su divulgaci=F3n = >> copia o distribuci=F3n a terceros sin la autorizaci=F3n expresa del = >> remitente. Si Vd. ha recibido este mensaje err=F3neamente, se ruega lo = >> notifique al remitente y proceda a su borrado. Gracias por su = >> colaboraci=F3n. >> ------------------------------------------------------------------------ >> This message including any attachments may contain confidential = >> information, according to our Information Security Management System, = >> and intended solely for a specific individual to whom they are = >> addressed. Any unauthorised copy, disclosure or distribution of this = >> message is strictly forbidden. If you have received this transmission = >> in error, please notify the sender immediately and delete it. >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> ietf-caldav mailing list -- ietf-caldav@osafoundation.org >> See http://ietf.webdav.org/caldav/ for more CalDAV resources >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > = > = _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Nov 3 13:15:16 2008 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 05CAE3A6C9C for ; Mon, 3 Nov 2008 13:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 kO+ENdoGFRR4 for ; Mon, 3 Nov 2008 13:15:15 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [64.127.108.190]) by core3.amsl.com (Postfix) with ESMTP id 0A9C93A6A10 for ; Mon, 3 Nov 2008 13:15:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 58A66794037; Mon, 3 Nov 2008 13:15:13 -0800 (PST) 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 1pDzubaJttvr; Mon, 3 Nov 2008 13:15:13 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 1226C794035; Mon, 3 Nov 2008 13:15:10 -0800 (PST) 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 2B3E179402D for ; Mon, 3 Nov 2008 13:15:09 -0800 (PST) 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 Qt4SzR1nTO6x for ; Mon, 3 Nov 2008 13:15:06 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by leka.osafoundation.org (Postfix) with ESMTP id 505FC794035 for ; Mon, 3 Nov 2008 13:15:00 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 0) id 2295C3A6A86; Mon, 3 Nov 2008 13:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103211502.2295C3A6A86@core3.amsl.com> Date: Mon, 3 Nov 2008 13:15:02 -0800 (PST) Cc: ietf-calsify@osafoundation.org Subject: [ietf-calsify] I-D Action:draft-ietf-calsify-2446bis-08.txt 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: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF. Title : iCalendar Transport-Independent Interoperability Protocol (iTIP) Author(s) : C. Daboo Filename : draft-ietf-calsify-2446bis-08.txt Pages : 130 Date : 2008-11-03 This document specifies a protocol using the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol using specific interoperable methods of communications between systems. iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-calsify-2446bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03130817.I-D@ietf.org> --NextPart 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 --NextPart-- From ietf-calsify-bounces@osafoundation.org Tue Nov 4 11:02:56 2008 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 6FA963A696E for ; Tue, 4 Nov 2008 11:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.869 X-Spam-Level: X-Spam-Status: No, score=-103.869 tagged_above=-999 required=5 tests=[AWL=-1.270, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 QNQA-8ZgBa7F for ; Tue, 4 Nov 2008 11:02:55 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [64.127.108.190]) by core3.amsl.com (Postfix) with ESMTP id 8553D28C233 for ; Tue, 4 Nov 2008 11:02:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id DD4C4794039; Tue, 4 Nov 2008 11:02:29 -0800 (PST) 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 Chx69ncI0L7M; Tue, 4 Nov 2008 11:02:28 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id F055F79403F; Tue, 4 Nov 2008 11:02:27 -0800 (PST) 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 7AF28794041 for ; Tue, 4 Nov 2008 11:02:24 -0800 (PST) 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 u6F2Il--S2b5 for ; Tue, 4 Nov 2008 11:02:23 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by leka.osafoundation.org (Postfix) with ESMTP id 038DD794039 for ; Tue, 4 Nov 2008 11:02:22 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 65DD03A6CB3; Tue, 4 Nov 2008 11:01:24 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081104190125.65DD03A6CB3@core3.amsl.com> Date: Tue, 4 Nov 2008 11:01:25 -0800 (PST) Cc: ietf-calsify@osafoundation.org Subject: [ietf-calsify] Last Call: draft-ietf-calsify-rfc2445bis (Internet Calendaring and Scheduling Core Object Specification (iCalendar)) to Proposed Standard X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org The IESG has received a request from the Calendaring and Scheduling Standards Simplification WG (calsify) to consider the following document: - 'Internet Calendaring and Scheduling Core Object Specification (iCalendar) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13988&rfc_flag=0 _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Tue Nov 4 11:22:40 2008 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 295A63A696E for ; Tue, 4 Nov 2008 11:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.754 X-Spam-Level: X-Spam-Status: No, score=-103.754 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qJgZbrKhjeDX for ; Tue, 4 Nov 2008 11:22:39 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [64.127.108.190]) by core3.amsl.com (Postfix) with ESMTP id 3CEE93A6841 for ; Tue, 4 Nov 2008 11:22:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 368F979403E; Tue, 4 Nov 2008 11:02:12 -0800 (PST) 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 wP22cqoN29aQ; Tue, 4 Nov 2008 11:02:12 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 9089979403B; Tue, 4 Nov 2008 11:02:09 -0800 (PST) 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 723AC79403D for ; Tue, 4 Nov 2008 11:02:06 -0800 (PST) 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 Xzx0XqTea0tq for ; Tue, 4 Nov 2008 11:02:05 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by leka.osafoundation.org (Postfix) with ESMTP id 2D095794039 for ; Tue, 4 Nov 2008 11:02:04 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 170183A6C78; Tue, 4 Nov 2008 11:00:38 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081104190039.170183A6C78@core3.amsl.com> Date: Tue, 4 Nov 2008 11:00:39 -0800 (PST) Cc: ietf-calsify@osafoundation.org Subject: [ietf-calsify] Last Call: draft-ietf-calsify-2446bis (iCalendar Transport-Independent Interoperability Protocol (iTIP)) to Proposed Standard X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org The IESG has received a request from the Calendaring and Scheduling Standards Simplification WG (calsify) to consider the following document: - 'iCalendar Transport-Independent Interoperability Protocol (iTIP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13952&rfc_flag=0 _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Tue Nov 4 12:00:39 2008 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 A17D128C267 for ; Tue, 4 Nov 2008 12:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 jFpoItkS9vkV for ; Tue, 4 Nov 2008 12:00:38 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [64.127.108.190]) by core3.amsl.com (Postfix) with ESMTP id 9430A28C26B for ; Tue, 4 Nov 2008 12:00:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 5FB6079403B; Tue, 4 Nov 2008 12:00:02 -0800 (PST) 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 a9CFGEhxKjd1; Tue, 4 Nov 2008 12:00:02 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 71CF2794039; Tue, 4 Nov 2008 11:59:59 -0800 (PST) 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 67C09794039 for ; Tue, 4 Nov 2008 11:59:57 -0800 (PST) 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 v0QWGLSNsVRN for ; Tue, 4 Nov 2008 11:59:56 -0800 (PST) Received: from daboo.name (daboo.name [151.201.22.177]) by leka.osafoundation.org (Postfix) with ESMTP id AD90E794018 for ; Tue, 4 Nov 2008 11:59:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id BE023EA6227 for ; Tue, 4 Nov 2008 14:59:51 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nRF87tFckbf for ; Tue, 4 Nov 2008 14:59:51 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 8E2E3EA6220 for ; Tue, 4 Nov 2008 14:59:50 -0500 (EST) Date: Tue, 04 Nov 2008 14:59:47 -0400 From: Cyrus Daboo To: ietf-calsify@osafoundation.org Message-ID: <7870308886F25747791418D6@caldav.corp.apple.com> In-Reply-To: <20081104190039.170183A6C78@core3.amsl.com> References: <20081104190039.170183A6C78@core3.amsl.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [ietf-calsify] Last Call: draft-ietf-calsify-2446bis (iCalendar Transport-Independent Interoperability Protocol (iTIP)) to Proposed Standard 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 Hi, --On November 4, 2008 11:00:39 AM -0800 The IESG wrote: > The IESG has received a request from the Calendaring and Scheduling > Standards Simplification WG (calsify) to consider the following document: FYI last call of 2446bis was inadvertently asked for and has now been cancelled, so please ignore the above. To clarify, the -08 draft I posted yesterday contains many changes in response to Lisa's and Reinhold's reviews. Still outstanding are a bunch of "complex" issues from Reinhold's review. These will need more discussion. I will start posting these to the list soon so that we can work through them to resolution. The files on the wiki show the current status of dealing with Reinhold's issues: . -- Cyrus Daboo _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Nov 7 19:05:52 2008 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 8A0143A69A3 for ; Fri, 7 Nov 2008 19:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 lkIZ15vxEUU5 for ; Fri, 7 Nov 2008 19:05:51 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id C23D33A6996 for ; Fri, 7 Nov 2008 19:05:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 396EA77D709; Fri, 7 Nov 2008 19:05:49 -0800 (PST) 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 GkiU20SmoWcp; Fri, 7 Nov 2008 19:05:49 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 9AB1377D703; Fri, 7 Nov 2008 19:05:44 -0800 (PST) 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 4293977D703 for ; Fri, 7 Nov 2008 19:05:43 -0800 (PST) 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 gBLh1N7c26LK for ; Fri, 7 Nov 2008 19:05:41 -0800 (PST) Received: from omta0101.mta.everyone.net (imta-38.everyone.net [216.200.145.38]) by leka.osafoundation.org (Postfix) with ESMTP id D67EC77D6FB for ; Fri, 7 Nov 2008 19:05:40 -0800 (PST) Received: from sj1-dm05.mta.everyone.net (sj1-slb03-gw2 [172.16.1.96]) by omta0101.mta.everyone.net (Postfix) with ESMTP id AF47A7C36CE for ; Fri, 7 Nov 2008 19:05:40 -0800 (PST) X-Eon-Dm: sj1-dm05 Received: by sj1-dm05.mta.everyone.net (EON-AUTHRELAY2 - 4a5503fa) id sj1-dm05.49120860.41491 for ; Fri, 7 Nov 2008 19:05:40 -0800 X-Eon-Sig: AQH1/7xJFQIEgWZggwIAAAAB,3cc550a9f811f8f4cef667e49292d3c9 Message-ID: <49150142.9050706@everyone.net> Date: Fri, 07 Nov 2008 19:02:26 -0800 From: Caleb Richardson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: [ietf-calsify] Issue 9 of Reinhold Kainhofer's iTIP Review 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 Issue 9 of Reinhold Kainhofer's iTIP Review Hello, I have an issue with the changes recently made in rfc2445bis-09 and 2446bis-08 as a result of Issue 9 of Reinhold Kainhofer's iTIP Review. In the following statement was added: "Recurrence instances of a recurring component MAY have different sequence numbers." There were also some changes made to , although I am still trying to determine the implications of those changes. As discussed in this thread started by Cyrus Daboo (it occurred on this mailing list in October 2007): http://osdir.com/ml/ietf.calsify/2007-10/msg00004.html, there are severe consequences if two CUAs differ on their opinion of how to increment SEQUENCE. There is a good example of potential problems in that thread, and I believe the conclusion was that keeping one SEQUENCE per recurrence set was the superior approach. -- Caleb Richardson Everyone.net _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Sun Nov 9 09:44:22 2008 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 6F0AD3A6915 for ; Sun, 9 Nov 2008 09:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 S8yxXj32FVxy for ; Sun, 9 Nov 2008 09:44:21 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 437203A6805 for ; Sun, 9 Nov 2008 09:44:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 0AB953E3E6B; Sun, 9 Nov 2008 09:44:18 -0800 (PST) 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 6TvEpJKoErTW; Sun, 9 Nov 2008 09:44:17 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 0A2BF79401C; Sun, 9 Nov 2008 09:44:10 -0800 (PST) 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 AAFD877D70F; Sun, 9 Nov 2008 09:44:08 -0800 (PST) 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 3930P3coiIPB; Sun, 9 Nov 2008 09:44:08 -0800 (PST) Received: from arista.notesdev.ibm.com (arista.notesdev.ibm.com [205.159.212.203]) by leka.osafoundation.org (Postfix) with ESMTP id D485477D709; Sun, 9 Nov 2008 09:44:07 -0800 (PST) In-Reply-To: <49150142.9050706@everyone.net> To: Caleb Richardson Message-ID: Date: Sun, 9 Nov 2008 13:43:47 -0500 From: "Robert Ransdell" References: <49150142.9050706@everyone.net> MIME-Version: 1.0 X-KeepSent: FE5E1E17:0EE08146-852574FC:0066329E; name=$KeepSent; type=4 X-Mailer: Lotus Notes Build V85_11052008 November 05, 2008 X-Disclaimed: 59383 Cc: ietf-calsify@osafoundation.org, ietf-calsify-bounces@osafoundation.org Subject: Re: [ietf-calsify] Issue 9 of Reinhold Kainhofer's iTIP Review 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="===============1695247923==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --===============1695247923== Content-Type: multipart/alternative; boundary="=_alternative 00616BDD852574FC_=" --=_alternative 00616BDD852574FC_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable It does not work for bumping sequence number only on entire recurrence=20 set. When individual occurrences are rescheduled, the chair needs to check for = next sequence number over entire set and set that sequence just for that=20 occurrence one past the last sequence number used . The invitees will=20 accept that occurrence reschedule and return an accept/decline using that=20 sequence number. The chair matches response on sequence number for=20 occurrence and marks status updated/decline for that occurrence.=20 From: Caleb Richardson To: ietf-calsify@osafoundation.org Date: 11/07/2008 10:39 PM Subject: [ietf-calsify] Issue 9 of Reinhold Kainhofer's iTIP Review Sent by: ietf-calsify-bounces@osafoundation.org Issue 9 of Reinhold Kainhofer's iTIP Review Hello, I have an issue with the changes recently made in rfc2445bis-09 and=20 2446bis-08 as a result of Issue 9 of Reinhold Kainhofer's iTIP Review. In =20 the following statement was added: "Recurrence instances of a recurring component MAY have different=20 sequence numbers." There were also some changes made to , although I am still trying to=20 determine the implications of those changes. As discussed in this thread started by Cyrus Daboo (it occurred on this=20 mailing list in October 2007):=20 http://osdir.com/ml/ietf.calsify/2007-10/msg00004.html, there are severe=20 consequences if two CUAs differ on their opinion of how to increment=20 SEQUENCE. There is a good example of potential problems in that thread,=20 and I believe the conclusion was that keeping one SEQUENCE per=20 recurrence set was the superior approach. --=20 Caleb Richardson Everyone.net =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --=_alternative 00616BDD852574FC_= Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable It does not work for bumping sequence nu= mber only on entire recurrenceset.
= When individual occurrences are rescheduled,  the chair needs to check for next sequence number over entire set and set that sequence just for that occurrence one past the last sequence number used .  The invitees will accept that occurrence reschedule and return an accept/decline using that sequence number.  The chair matches response on sequence number for occurrence and marks status updated= /decline for that occurrence.


From:Caleb Richardson <caleb@everyone.net>= ;
To:ietf-calsify@osafound= ation.org
Date:11/07/2008 = 10:39 PM
Subject:[ietf-cal= sify] Issue 9 of Reinhold Kainhofer's iTIP Review
Sent by:ietf-= calsify-bounces@osafoundation.org



Issue 9 of Reinhold Kainhofer's iTIP Review

Hell= o,

I have an issue with the changes recently made in rfc2445bis-09 a= nd
2446bis-08 as a result of Issue 9 of Reinhold Kainhofer's iTIP Revie= w.

In <draft-ietf-calsify-rfc2445bis-09 section 3.8.7.4. Sequence= Number>
the following statement was added:

"Recurrence instances of= a recurring component MAY have different
sequence numbers."

There were also some changes made to <= ;draft-ietf-calsify-2446bis-08
section 2.1.5. Message Sequencing>, although I am still trying to determine the implications of those changes.

As discussed in this = thread started by Cyrus Daboo (it occurred on this
mailing list in October 2007):
http://osdir.= com/ml/ietf.calsify/2007-10/msg00004.html, there are severe
consequences if two CUAs differ on their opinion of ho= w to increment
SEQUENCE. There is a good example of potential problems = in that thread,
and I believe the conclusion was that keeping one SEQUENCE per
recu= rrence set was the superior approach.

--
Caleb Richardson
Eve= ryone.net
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
ietf-calsify mailing list
ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/= ietf-calsify


--=_alternative 00616BDD852574FC_=-- --===============1695247923== 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 --===============1695247923==-- From ietf-calsify-bounces@osafoundation.org Thu Nov 13 12:43:10 2008 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 3DE9A3A69CE for ; Thu, 13 Nov 2008 12:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 PuTB6MCJ-Oz2 for ; Thu, 13 Nov 2008 12:43:09 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 617C93A6953 for ; Thu, 13 Nov 2008 12:43:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id ED6A13E3EBF; Thu, 13 Nov 2008 12:43:06 -0800 (PST) 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 3GkqW5eNFBck; Thu, 13 Nov 2008 12:43:06 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id B63E43E3EB6; Thu, 13 Nov 2008 12:42:57 -0800 (PST) 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 C770D3E3EBE for ; Thu, 13 Nov 2008 12:42:52 -0800 (PST) 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 KD8Zu5yNr7DR for ; Thu, 13 Nov 2008 12:42:42 -0800 (PST) Received: from mail-gx0-f26.google.com (mail-gx0-f26.google.com [209.85.217.26]) by leka.osafoundation.org (Postfix) with ESMTP id 7286B3E3EAB for ; Thu, 13 Nov 2008 12:42:42 -0800 (PST) Received: by gxk7 with SMTP id 7so364871gxk.17 for ; Thu, 13 Nov 2008 12:42:41 -0800 (PST) Received: by 10.100.168.18 with SMTP id q18mr4799499ane.7.1226593279240; Thu, 13 Nov 2008 08:21:19 -0800 (PST) Received: from ?192.168.0.132? (pool-64-222-236-186.port.east.verizon.net [64.222.236.186]) by mx.google.com with ESMTPS id c29sm19254033anc.49.2008.11.13.08.21.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Nov 2008 08:21:18 -0800 (PST) Message-ID: <491C53F7.2040402@gmail.com> Date: Thu, 13 Nov 2008 11:21:11 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: [ietf-calsify] Pulling hair 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 Three prior posts have failed to reach the list. Fourth time the charm? -- Ken Shoemake _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Nov 13 12:52:50 2008 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 D031E3A69B2 for ; Thu, 13 Nov 2008 12:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 B6Z6pFsuyWFN for ; Thu, 13 Nov 2008 12:52:50 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 2FAA93A698B for ; Thu, 13 Nov 2008 12:52:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id C0AB73E3EC4; Thu, 13 Nov 2008 12:52:50 -0800 (PST) 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 Lb8koj851q9A; Thu, 13 Nov 2008 12:52:50 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 49B6D3E3EC2; Thu, 13 Nov 2008 12:52:48 -0800 (PST) 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 AFF3E3E3EBE for ; Thu, 13 Nov 2008 12:52:46 -0800 (PST) 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 WEf7rlf1-5Yd for ; Thu, 13 Nov 2008 12:52:46 -0800 (PST) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.251]) by leka.osafoundation.org (Postfix) with ESMTP id C787C3E3EC3 for ; Thu, 13 Nov 2008 12:52:45 -0800 (PST) Received: by ag-out-0708.google.com with SMTP id 23so1053203agd.11 for ; Thu, 13 Nov 2008 12:52:45 -0800 (PST) Received: by 10.90.120.14 with SMTP id s14mr8925188agc.20.1226555865261; Wed, 12 Nov 2008 21:57:45 -0800 (PST) Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id 8sm12370863agd.21.2008.11.12.21.57.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Nov 2008 21:57:44 -0800 (PST) Message-ID: <491BC1CE.1070609@gmail.com> Date: Thu, 13 Nov 2008 00:57:34 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: iCalendar group Subject: [ietf-calsify] Test post 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 My first two posts to this list have not appeared. This is a test. -- Ken Shoemake _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Nov 14 00:30:50 2008 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 DA5863A6A39 for ; Fri, 14 Nov 2008 00:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 26BIJsB-mDsd for ; Fri, 14 Nov 2008 00:30:49 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 9239B3A67E6 for ; Fri, 14 Nov 2008 00:30:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 2921C77D708; Fri, 14 Nov 2008 00:30:50 -0800 (PST) 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 NNhybJzP-SqH; Fri, 14 Nov 2008 00:30:40 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id B683477D700; Fri, 14 Nov 2008 00:30:36 -0800 (PST) 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 5F9B877D708 for ; Fri, 14 Nov 2008 00:30:34 -0800 (PST) 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 tCsB4n+ZA3YH for ; Fri, 14 Nov 2008 00:30:23 -0800 (PST) Received: from mail-gx0-f28.google.com (mail-gx0-f28.google.com [209.85.217.28]) by leka.osafoundation.org (Postfix) with ESMTP id 7989377D6FE for ; Fri, 14 Nov 2008 00:30:23 -0800 (PST) Received: by gxk9 with SMTP id 9so518537gxk.3 for ; Fri, 14 Nov 2008 00:30:22 -0800 (PST) Received: by 10.100.143.14 with SMTP id q14mr380806and.47.1226651422782; Fri, 14 Nov 2008 00:30:22 -0800 (PST) Received: from ?192.168.0.132? (pool-64-222-236-186.port.east.verizon.net [64.222.236.186]) by mx.google.com with ESMTPS id b32sm674384ana.54.2008.11.14.00.30.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 00:30:22 -0800 (PST) Message-ID: <491D371B.2060507@gmail.com> Date: Fri, 14 Nov 2008 03:30:19 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: [ietf-calsify] ABNF intent in rfc2445bis-09 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 With regard to syntax, first some context: Note that rfc4234 on ABNF says (section 3.1) ---------- LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing model. A string of contiguous characters (values) is parsed according to the rules defined in ABNF. For Internet specifications, there is some history of permitting linear white space (space and horizontal tab) to be freely and implicitly interspersed around major constructs, such as delimiting special characters or atomic strings. NOTE: This specification for ABNF does not provide for implicit specification of linear white space. Any grammar that wishes to permit linear white space around delimiters or string segments must specify it explicitly. ---------- One way to convey that implicit white space is not allowed is to state that the ABNF uses this newer rfc4234 instead of rfc2234; that's obscure and error prone compared to explicitly stating the intent. So now the question: In rfc2445, line folding is specified, but beyond that the explicit ABNF syntax apparently does not permit white space between tokens. For example, BEGIN:VEVENT would be correct but BEGIN: VEVENT would not. A robust parser will accept the latter anyway, but the spec might best spell out the intent: is such white space definitely allowed or definitely disallowed? Also: The IETF-Tools page () provides two tools for automatically combing through the ABNF in a specification (here, 'draft-ietf-calsify-rfc2445bis-09'). The first extracts lines of syntax; it is Bill Fenner's 'aex' (). Unfortunately, the current draft causes it to stumble in a few places. The second tool parses ABNF for errors; it is Bill's ABNF Parser, 'bap' (). It finds issues with the ABNF in the spec even after the obvious problems left by aex are cleaned up. Nevertheless, its strict read of the grammar seems to imply that white space between tokens is not formally allowed at present. Is there intent to make automatic extraction and parsing of the ABNF work? Is there intent to clarify the permissibility of white space between tokens? -- Ken Shoemake _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Nov 14 06:39:44 2008 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 F2AE53A6808 for ; Fri, 14 Nov 2008 06:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_52=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 234ggvSiBLO0 for ; Fri, 14 Nov 2008 06:39:42 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id CECC53A6767 for ; Fri, 14 Nov 2008 06:39:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 5B7BB7841EF; Fri, 14 Nov 2008 06:39:43 -0800 (PST) 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 WC+dn-wXAOzZ; Fri, 14 Nov 2008 06:39:33 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 2992477D718; Fri, 14 Nov 2008 06:39:29 -0800 (PST) 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 6198477D718 for ; Fri, 14 Nov 2008 06:39:28 -0800 (PST) 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 ILgXMy0+elsc for ; Fri, 14 Nov 2008 06:39:26 -0800 (PST) Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id E165777D717 for ; Fri, 14 Nov 2008 06:39:25 -0800 (PST) Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAEEd1lu001108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Nov 2008 14:39:03 GMT Received: from acsmt705.oracle.com (acsmt705.oracle.com [141.146.40.83]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAEEdJRq015114; Fri, 14 Nov 2008 14:39:20 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Nov 2008 14:39:05 +0000 Message-ID: <491D8D86.4090905@oracle.com> Date: Fri, 14 Nov 2008 09:39:02 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ken Shoemake References: <491D371B.2060507@gmail.com> In-Reply-To: <491D371B.2060507@gmail.com> X-Source-IP: acsmt705.oracle.com [141.146.40.83] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.491D8D8B.00A2:SCFSTAT928724,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 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 Hi Ken, See answer inline. Ken Shoemake wrote: > With regard to syntax, first some context: > > Note that rfc4234 on ABNF says (section 3.1) > ---------- > LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing > model. A string of contiguous characters (values) is parsed > according to the rules defined in ABNF. For Internet specifications, > there is some history of permitting linear white space (space and > horizontal tab) to be freely and implicitly interspersed around major > constructs, such as delimiting special characters or atomic strings. > > NOTE: > > This specification for ABNF does not provide for implicit > specification of linear white space. > > Any grammar that wishes to permit linear white space around > delimiters or string segments must specify it explicitly. > ---------- > One way to convey that implicit white space is not allowed is to state > that the ABNF uses this newer rfc4234 instead of rfc2234; that's obscure > and error prone compared to explicitly stating the intent. The draft already makes reference to RFC5234 (which obsoleted RFC4234): http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-09#section-1 > The memo also includes a formal grammar for the content type based on > the Internet ABNF defined in [RFC5234]. http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-09#section-2 > The notation used in this memo is the ABNF notation of [RFC5234]. > > > So now the question: > > In rfc2445, line folding is specified, but beyond that the explicit ABNF > syntax apparently does not permit white space between tokens. For example, > BEGIN:VEVENT > would be correct but > BEGIN: VEVENT > would not. A robust parser will accept the latter anyway, but the spec > might best spell out the intent: is such white space definitely allowed > or definitely disallowed? > > Also: > The IETF-Tools page () provides two tools for > automatically combing through the ABNF in a specification (here, > 'draft-ietf-calsify-rfc2445bis-09'). The first extracts lines of syntax; > it is Bill Fenner's 'aex' (). > Unfortunately, the current draft causes it to stumble in a few places. > The second tool parses ABNF for errors; it is Bill's ABNF Parser, 'bap' > (). It finds issues with the > ABNF in the spec even after the obvious problems left by aex are cleaned > up. Please clarify which issues are reported. Bill's ABNF Parser currently reports "No errors during parsing". That being said, it is reporting multiple differences between the original and Bill's "canonical" form. For instance, the draft currently specifies: "BEGIN" ":" "VCALENDAR" instead of: "BEGIN:VCALENDAR" Is this what you're making reference to? > Nevertheless, its strict read of the grammar seems to imply that > white space between tokens is not formally allowed at present. > > Is there intent to make automatic extraction and parsing of the ABNF > work? I've been using Julian Reschke's "extract-artwork.xslt" transformation against the XML version of the draft to extract ABNF from the draft. See: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork I was not aware of the existence of the 'aex' tool. How do you recommend to modify the draft such that 'aex' won't pick up the following lines by mistake: > c=US???(cn=Jim%20Dolittle)":mailto:jimdo@example.com > > TZID=America/New_York:19980119T020000 > > FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 > > BYMINUTE=30 > > FREQ=DAILY;COUNT=10;INTERVAL=2 > > TZID=America/New_York:083000 > > decimal = degrees + minutes/60 + seconds/3600. > > c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\, > > BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA > BYDAY=MO,WE,FR > > BYMONTHDAY=2,3,4,5,6,7,8 > Is there intent to clarify the permissibility of white space > between tokens? Given that we are already making reference to RFC5234, and that our intent is NOT to permit linear white space around delimiters or string segments, what change or clarifying text would you like to see added in the draft? Thanks, Bernard > > -- Ken Shoemake > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Nov 14 14:21:05 2008 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 8FABD28C14E for ; Fri, 14 Nov 2008 14:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 qzW6JCOWGELc for ; Fri, 14 Nov 2008 14:21:04 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id B8DF63A6A4A for ; Fri, 14 Nov 2008 14:21:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 0B58177D716; Fri, 14 Nov 2008 14:21:02 -0800 (PST) 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 kDN92YnOVDOR; Fri, 14 Nov 2008 14:21:01 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id EC2C077D70B; Fri, 14 Nov 2008 14:20:56 -0800 (PST) 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 5A0D577D70B for ; Fri, 14 Nov 2008 14:20:54 -0800 (PST) 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 tjHfb9amTEKo for ; Fri, 14 Nov 2008 14:20:39 -0800 (PST) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.249]) by leka.osafoundation.org (Postfix) with ESMTP id E9A5A77D709 for ; Fri, 14 Nov 2008 14:20:38 -0800 (PST) Received: by ag-out-0708.google.com with SMTP id 23so1512323agd.11 for ; Fri, 14 Nov 2008 14:20:38 -0800 (PST) Received: by 10.90.84.2 with SMTP id h2mr1115687agb.42.1226701238022; Fri, 14 Nov 2008 14:20:38 -0800 (PST) Received: from ?192.168.0.132? (pool-64-222-236-186.port.east.verizon.net [64.222.236.186]) by mx.google.com with ESMTPS id 38sm942671aga.4.2008.11.14.14.20.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 14:20:37 -0800 (PST) Message-ID: <491DF9B2.2080603@gmail.com> Date: Fri, 14 Nov 2008 17:20:34 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: [ietf-calsify] rfc2445bis-09 nit 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 In section 3.7.3, Product Identifier, the Description says "This property SHOULD not"; its capitalization needs to be changed to "This property SHOULD NOT", according to the nit finder. Also there is some complaint about boilerplate which may deserve attention. -- Ken _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Nov 14 23:48:11 2008 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 EC8A43A680C for ; Fri, 14 Nov 2008 23:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 IzPlV7aehqOq for ; Fri, 14 Nov 2008 23:48:10 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id DFCB03A6822 for ; Fri, 14 Nov 2008 23:48:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 2774177D6F9; Fri, 14 Nov 2008 23:48:11 -0800 (PST) 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 hsHhJlr2DcBs; Fri, 14 Nov 2008 23:48:01 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id A11137841ED; Fri, 14 Nov 2008 23:47:57 -0800 (PST) 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 5D07F77D709 for ; Fri, 14 Nov 2008 23:47:55 -0800 (PST) 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 hq8whFVUvjP5 for ; Fri, 14 Nov 2008 23:47:52 -0800 (PST) Received: from mail-gx0-f28.google.com (mail-gx0-f28.google.com [209.85.217.28]) by leka.osafoundation.org (Postfix) with ESMTP id AE0FF77D6F9 for ; Fri, 14 Nov 2008 23:47:52 -0800 (PST) Received: by gxk9 with SMTP id 9so765858gxk.3 for ; Fri, 14 Nov 2008 23:47:52 -0800 (PST) Received: by 10.100.190.14 with SMTP id n14mr880633anf.19.1226735271997; Fri, 14 Nov 2008 23:47:51 -0800 (PST) Received: from ?192.168.0.132? (pool-64-222-236-186.port.east.verizon.net [64.222.236.186]) by mx.google.com with ESMTPS id c14sm2458070ana.58.2008.11.14.23.47.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 23:47:51 -0800 (PST) Message-ID: <491E7EA0.4000808@gmail.com> Date: Sat, 15 Nov 2008 02:47:44 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: multipart/mixed; boundary="------------020208010108070901030609" Subject: [ietf-calsify] [Fwd: Re: ABNF intent in rfc2445bis-09] 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: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --------------020208010108070901030609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------020208010108070901030609 Content-Type: message/rfc822; name="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml" Return-Path: Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id m71sm791938rnd.3.2008.11.14.13.10.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 13:10:24 -0800 (PST) Message-ID: <491DE939.2090306@gmail.com> Date: Fri, 14 Nov 2008 16:10:17 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> In-Reply-To: <491D8D86.4090905@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > Given that we are already making reference to RFC5234, and that our > intent is NOT to permit linear white space around delimiters or string > segments, what change or clarifying text would you like to see added in > the draft? In section 2, Basic Grammar and Conventions, I would revise the text to include a new note, and move the note on notes, as follows. ---------- This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo. The notation used in this memo is the ABNF notation of [RFC5234]. Readers intending on implementing the format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. Note: Spaces and horizontal tabs (formally, linear white space) are only allowed where explicitly stated in the notation, never implicitly; see section 3.1 of [RFC5234]. All numeric values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. ---------- This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. The notation used in this memo is the ABNF notation of [RFC5234]. Readers intending on implementing the format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. All numeric values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo. ---------- The single new sentence provides two benefits. 1. It states the intent here, rather than forcing the reader to sift through and interpret a large secondary document. 2. It shields this document from historical interpretations of ABNF so there can be no question of accidental intent. Although files will be read by programs more than humans, text formats frequently admit flexible use of linear white space. When going against convention it is best to alert readers explicitly. -- Ken Shoemake --------------020208010108070901030609 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 --------------020208010108070901030609-- From ietf-calsify-bounces@osafoundation.org Fri Nov 14 23:48:44 2008 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 01BCB3A6822 for ; Fri, 14 Nov 2008 23:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 aCfbcU7X9iPg for ; Fri, 14 Nov 2008 23:48:43 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 226D53A680C for ; Fri, 14 Nov 2008 23:48:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 7665179401A; Fri, 14 Nov 2008 23:48:43 -0800 (PST) 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 Ta2wyGKnu2dG; Fri, 14 Nov 2008 23:48:33 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id F0C657841F3; Fri, 14 Nov 2008 23:48:32 -0800 (PST) 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 764BF794019 for ; Fri, 14 Nov 2008 23:48:31 -0800 (PST) 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 l7NY3g+qPHf7 for ; Fri, 14 Nov 2008 23:48:20 -0800 (PST) Received: from mail-gx0-f28.google.com (mail-gx0-f28.google.com [209.85.217.28]) by leka.osafoundation.org (Postfix) with ESMTP id 729847841F3 for ; Fri, 14 Nov 2008 23:48:20 -0800 (PST) Received: by mail-gx0-f28.google.com with SMTP id 9so765858gxk.3 for ; Fri, 14 Nov 2008 23:48:20 -0800 (PST) Received: by 10.100.3.4 with SMTP id 4mr879125anc.27.1226735300266; Fri, 14 Nov 2008 23:48:20 -0800 (PST) Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id b37sm999283ana.10.2008.11.14.23.48.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 23:48:19 -0800 (PST) Message-ID: <491E7EC1.9000106@gmail.com> Date: Sat, 15 Nov 2008 02:48:17 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: multipart/mixed; boundary="------------090601050806040306020607" Subject: [ietf-calsify] [Fwd: Re: ABNF intent in rfc2445bis-09] 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: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --------------090601050806040306020607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------090601050806040306020607 Content-Type: message/rfc822; name="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml" Return-Path: Received: from ?192.168.0.132? (pool-64-222-236-186.port.east.verizon.net [64.222.236.186]) by mx.google.com with ESMTPS id 38sm946771aga.4.2008.11.14.14.26.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 14:26:36 -0800 (PST) Message-ID: <491DFB1A.40409@gmail.com> Date: Fri, 14 Nov 2008 17:26:34 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> In-Reply-To: <491D8D86.4090905@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > I've been using Julian Reschke's "extract-artwork.xslt" transformation > against the XML version of the draft to extract ABNF from the draft. See: > > http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork Will the XML version be available when the standard is approved? If so, then extraction from that would indeed seem easier and more reliable than using a text-based tool like aex. Unfortunately, I cannot seem to find a copy of the draft in XML format in the obvious place, Where should I be looking? -- Ken --------------090601050806040306020607 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 --------------090601050806040306020607-- From ietf-calsify-bounces@osafoundation.org Sat Nov 15 00:32:35 2008 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 B01C03A67B3 for ; Sat, 15 Nov 2008 00:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 kZtWS692mAfJ for ; Sat, 15 Nov 2008 00:32:34 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id CA1A33A67B0 for ; Sat, 15 Nov 2008 00:32:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 20FBC7841ED; Sat, 15 Nov 2008 00:32:35 -0800 (PST) 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 hdez0gL+adqA; Sat, 15 Nov 2008 00:32:25 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id A76807841EF; Sat, 15 Nov 2008 00:32:22 -0800 (PST) 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 55ADA7841EF for ; Sat, 15 Nov 2008 00:32:20 -0800 (PST) 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 BboMMjMy1Scl for ; Sat, 15 Nov 2008 00:32:09 -0800 (PST) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.249]) by leka.osafoundation.org (Postfix) with ESMTP id 5C2A87841ED for ; Sat, 15 Nov 2008 00:32:09 -0800 (PST) Received: by ag-out-0708.google.com with SMTP id 23so1596898agd.11 for ; Sat, 15 Nov 2008 00:32:08 -0800 (PST) Received: by 10.90.51.13 with SMTP id y13mr1374317agy.10.1226737928733; Sat, 15 Nov 2008 00:32:08 -0800 (PST) Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id o61sm1858687hsc.7.2008.11.15.00.32.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 15 Nov 2008 00:32:08 -0800 (PST) Message-ID: <491E8901.2010201@gmail.com> Date: Sat, 15 Nov 2008 03:32:01 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> In-Reply-To: <491D8D86.4090905@oracle.com> Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 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 Trying reply again. Bernard Desruisseaux wrote: > Given that we are already making reference to RFC5234, and that our intent is NOT to permit linear white space around delimiters or string segments, what change or clarifying text would you like to see added in the draft? In section 2, Basic Grammar and Conventions, I would revise the text to include a new note, and move the note on notes, as follows. ---------- This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo. The notation used in this memo is the ABNF notation of [RFC5234]. Readers intending on implementing the format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. Note: Spaces and horizontal tabs (formally, linear white space) are only allowed where explicitly stated in the notation, never implicitly; see section 3.1 of [RFC5234]. All numeric values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. ---------- This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. The notation used in this memo is the ABNF notation of [RFC5234]. Readers intending on implementing the format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. All numeric values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo. ---------- The single new sentence provides two benefits. 1. It states the intent here, rather than forcing the reader to sift through and interpret a large secondary document. 2. It shields this document from historical interpretations of ABNF so there can be no question of accidental intent. Although files will be read by programs more than humans, text formats frequently admit flexible use of linear white space. When going against convention it is best to alert readers explicitly. -- Ken Shoemake _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Sat Nov 15 00:33:39 2008 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 913B93A67B3 for ; Sat, 15 Nov 2008 00:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 00UDHOOYDVWu for ; Sat, 15 Nov 2008 00:33:38 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id AE3423A67B0 for ; Sat, 15 Nov 2008 00:33:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id EB61E7841F4; Sat, 15 Nov 2008 00:33:38 -0800 (PST) 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 YXHF7xck4sr9; Sat, 15 Nov 2008 00:33:29 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id DD01F7841F2; Sat, 15 Nov 2008 00:33:28 -0800 (PST) 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 1EFF77841F2 for ; Sat, 15 Nov 2008 00:33:21 -0800 (PST) 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 SMo2ukUfsHQD for ; Sat, 15 Nov 2008 00:33:10 -0800 (PST) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.241]) by leka.osafoundation.org (Postfix) with ESMTP id 7753E7841EF for ; Sat, 15 Nov 2008 00:33:10 -0800 (PST) Received: by ag-out-0708.google.com with SMTP id 23so1597011agd.11 for ; Sat, 15 Nov 2008 00:33:10 -0800 (PST) Received: by 10.90.91.9 with SMTP id o9mr1334580agb.94.1226737989909; Sat, 15 Nov 2008 00:33:09 -0800 (PST) Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id y56sm1859392hsb.19.2008.11.15.00.33.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 15 Nov 2008 00:33:09 -0800 (PST) Message-ID: <491E8942.9030205@gmail.com> Date: Sat, 15 Nov 2008 03:33:06 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> In-Reply-To: <491D8D86.4090905@oracle.com> Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 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 Trying this reply again also. Bernard Desruisseaux wrote: > I've been using Julian Reschke's "extract-artwork.xslt" transformation against the XML version of the draft to extract ABNF from the draft. See: > > http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork Will the XML version be available when the standard is approved? If so, then extraction from that would indeed seem easier and more reliable than using a text-based tool like aex. Unfortunately, I cannot seem to find a copy of the draft in XML format in the obvious place, Where should I be looking? -- Ken _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Nov 17 07:55:33 2008 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 7D5FD3A6808 for ; Mon, 17 Nov 2008 07:55:33 -0800 (PST) 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=[AWL=0.600, BAYES_00=-2.599] 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 tduJZo38lLRv for ; Mon, 17 Nov 2008 07:55:32 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 9197E3A67A6 for ; Mon, 17 Nov 2008 07:55:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 544A23E3F4C; Mon, 17 Nov 2008 07:55:32 -0800 (PST) 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 gGD-r0EeRNqq; Mon, 17 Nov 2008 07:55:32 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id D42B077D6FF; Mon, 17 Nov 2008 07:55:29 -0800 (PST) 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 65C9B77D6FF for ; Mon, 17 Nov 2008 07:55:28 -0800 (PST) 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 YWxcviN3XG4N for ; Mon, 17 Nov 2008 07:55:26 -0800 (PST) Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 664933E3F45 for ; Mon, 17 Nov 2008 07:55:26 -0800 (PST) Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAHFtcKI005722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Nov 2008 15:55:39 GMT Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAHFtQ8k023725; Mon, 17 Nov 2008 15:55:33 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Nov 2008 15:55:11 +0000 Message-ID: <492193DD.6080502@oracle.com> Date: Mon, 17 Nov 2008 10:55:09 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ken Shoemake References: <491DF9B2.2080603@gmail.com> In-Reply-To: <491DF9B2.2080603@gmail.com> X-Source-IP: acsmt704.oracle.com [141.146.40.82] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.492193E8.01CB:SCFSTAT928724,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] rfc2445bis-09 nit 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 Hi Ken, The General Area Review Team (Gen-ART) also spotted this typo during their review. It's fixed now. Thanks, Bernard Ken Shoemake wrote: > In section 3.7.3, Product Identifier, the Description says "This > property SHOULD not"; its capitalization needs to be changed to "This > property SHOULD NOT", according to the nit finder. > > Also there is some complaint about boilerplate which may deserve attention. > > -- Ken > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Tue Nov 18 02:39:14 2008 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 B06C23A685A for ; Tue, 18 Nov 2008 02:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 iqhzVEgy4b+N for ; Tue, 18 Nov 2008 02:39:13 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id C711F3A67A8 for ; Tue, 18 Nov 2008 02:39:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 3969A7841EF; Tue, 18 Nov 2008 02:39:13 -0800 (PST) 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 PqgbTkcQ5zsR; Tue, 18 Nov 2008 02:39:03 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id DFDF37841F6; Tue, 18 Nov 2008 02:38:57 -0800 (PST) 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 C86AD7841F6 for ; Tue, 18 Nov 2008 02:38:55 -0800 (PST) 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 i8XeUoV9h3NR for ; Tue, 18 Nov 2008 02:38:54 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by leka.osafoundation.org (Postfix) with ESMTP id 3800C7841EF for ; Tue, 18 Nov 2008 02:38:54 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 31so1110176yxl.81 for ; Tue, 18 Nov 2008 02:38:53 -0800 (PST) Received: by 10.90.73.17 with SMTP id v17mr3375336aga.25.1227004733443; Tue, 18 Nov 2008 02:38:53 -0800 (PST) Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id 6sm4030897agd.37.2008.11.18.02.38.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Nov 2008 02:38:52 -0800 (PST) Message-ID: <49229B2F.7070105@gmail.com> Date: Tue, 18 Nov 2008 05:38:39 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> <491DE939.2090306@gmail.com> <1EC65F4E98D14B5D807BC9A5AF381767@NIGEL08> In-Reply-To: <1EC65F4E98D14B5D807BC9A5AF381767@NIGEL08> Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 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 Nigel Swinson wrote: > But then immediately proceeding that you've included two 20+ line > sections supposedly where one is different to the other. Sifting > through what you have changed is extremely difficult. Before I gave the change I stated that it consisted of moving the note on notes and including a new note. Perhaps it was confusing because I gave the new text first, and did not label which was old and which new. Still, I assumed that Bernard, who had asked "[W]hat change or clarifying text would you like to see added in the draft?", would have little difficulty with my reply. An ancient but still useful standard for changes is much as you suggest, however in this case it would obscure the fact that a paragraph (the note on notes) was moved. Moving that paragraph makes logical sense for two reasons: 1. It should precede the use of the indented note convention for my new remark. 2. It seems natural in the flow of exposition for it to follow the paragraph on formal and informal notation. Again, the only substantive change proposed is to add one new sentence. I am satisfied that such a note will suffice, and there is precedent. Among the ABNF given in rfc2445bis-09 is this: eventc = "BEGIN" ":" "VEVENT" CRLF eventprop *alarmc "END" ":" "VEVENT" CRLF Section 2.3 of [RFC5234] says that "ABNF strings are case insensitive", so implicitly we know that "begin:vevent" or "Begin:vEvent" are to be accepted along with "BEGIN:VEVENT". Yet rfc2445bis-09 finds it prudent to explicitly say "All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive." Adding the comment about white space is also prudent, as I hope we agree. -- Ken Shoemake _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Nov 19 12:42:06 2008 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 770D028C127 for ; Wed, 19 Nov 2008 12:42:06 -0800 (PST) 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_74=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 iwTDNn5OrGVI for ; Wed, 19 Nov 2008 12:42:05 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id CD6C73A6782 for ; Wed, 19 Nov 2008 12:42:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 2882D79402A; Wed, 19 Nov 2008 12:42:03 -0800 (PST) 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 ja3tHA9Cfqee; Wed, 19 Nov 2008 12:41:53 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 07C08794024; Wed, 19 Nov 2008 12:41:47 -0800 (PST) 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 D22D5794024 for ; Wed, 19 Nov 2008 12:41:45 -0800 (PST) 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 Yu4YXyh64K2i for ; Wed, 19 Nov 2008 12:41:45 -0800 (PST) Received: from web63103.mail.re1.yahoo.com (web63103.mail.re1.yahoo.com [69.147.96.245]) by leka.osafoundation.org (Postfix) with SMTP id 4E97779401D for ; Wed, 19 Nov 2008 12:41:45 -0800 (PST) Received: (qmail 9561 invoked by uid 60001); 19 Nov 2008 20:41:44 -0000 X-YMail-OSG: a7YSzbcVM1mJagbDIGxMMSfemm90oH9gyoXUAe.ZF_jkinjv2ykbvIYt590LUAnDw.GKYi9Z_byy4xgHaLxGYsni455UR7ybErU_HgUCkhon1rhsyV6uy5cKSKZwHJ0pe1fK45LiwbNbNXKrww_sn5gMt1Y- Received: from [71.119.123.156] by web63103.mail.re1.yahoo.com via HTTP; Wed, 19 Nov 2008 12:41:44 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 19 Nov 2008 12:41:44 -0800 (PST) From: Adrian Crum To: ietf-calsify@osafoundation.org MIME-Version: 1.0 Message-ID: <694410.9213.qm@web63103.mail.re1.yahoo.com> Subject: [ietf-calsify] EXRULE Question X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian.crum@yahoo.com 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 While browsing the internet I ran across the notes from 2006 regarding deprecating or removing EXRULE and EXDATE from RFC 2445. The comments made at the time indicated that no one was using it. I'm curious - without those properties, how would one express a Monday through Friday at 8:00 AM event, except on US federal holidays? I created an example iCalendar based on the original RFC: BEGIN:VCALENDAR PRODID:-//Apache Open For Business//Work Effort Calendar//EN VERSION:2.0 CALSCALE:GREGORIAN DESCRIPTION:Adrian's Calendar BEGIN:VEVENT DTSTAMP:20081112T180905Z CREATED:20081111T231419Z LAST-MODIFIED:20081111T232507Z X-ORG-OFBIZ-WORKEFFORT-ID:10020 SUMMARY:Work Schedule DESCRIPTION:Work Schedule ORGANIZER;CN=THE ADMINISTRATOR: DTSTART:20080101T000043 RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 END:VEVENT END:VCALENDAR I can't find any mention of an alternative to using the EXRULE property, so where would one go from here? -Adrian _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Nov 19 17:15:36 2008 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 4353C3A6BD1 for ; Wed, 19 Nov 2008 17:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 EaLgORuVVb0D for ; Wed, 19 Nov 2008 17:15:34 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id E0D973A6BD6 for ; Wed, 19 Nov 2008 17:15:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 137FD7841F2; Wed, 19 Nov 2008 17:15:34 -0800 (PST) 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 vIPOEuAQf4R5; Wed, 19 Nov 2008 17:15:32 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id CFB657841F0; Wed, 19 Nov 2008 17:15:27 -0800 (PST) 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 C9C157841F0 for ; Wed, 19 Nov 2008 17:15:24 -0800 (PST) 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 L8st0u0TXoVT for ; Wed, 19 Nov 2008 17:15:23 -0800 (PST) Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 4E4D37841EF for ; Wed, 19 Nov 2008 17:15:23 -0800 (PST) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAK1FaAw012407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Nov 2008 01:15:37 GMT Received: from acsmt700.oracle.com (acsmt700.oracle.com [141.146.40.70]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAK1FL86002012; Thu, 20 Nov 2008 01:15:22 GMT Received: from [141.144.96.142] (/141.144.96.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Nov 2008 01:15:15 +0000 Message-ID: <4924BA21.1000302@oracle.com> Date: Wed, 19 Nov 2008 20:15:13 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ken Shoemake References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> <491E8942.9030205@gmail.com> In-Reply-To: <491E8942.9030205@gmail.com> X-Source-IP: acsmt700.oracle.com [141.146.40.70] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020A.4924BA25.017B:SCFSTAT928724,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 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 Hi Ken, I finally submitted the XML version of the draft to the IETF. It is now available here: http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-09.xml It is also accessible from the "Calsify Status Pages" here: http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ Cheers, Bernard Ken Shoemake wrote: > Trying this reply again also. > > Bernard Desruisseaux wrote: > > I've been using Julian Reschke's "extract-artwork.xslt" > transformation against the XML version of the draft to extract ABNF from > the draft. See: > > > > > http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork > > > Will the XML version be available when the standard is approved? If so, > then extraction from that would indeed seem easier and more reliable > than using a text-based tool like aex. Unfortunately, I cannot seem to > find a copy of the draft in XML format in the obvious place, > > Where should I be looking? > > -- Ken > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Nov 19 17:34:30 2008 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 6807A3A6BD1 for ; Wed, 19 Nov 2008 17:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=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 j-bTytKfdWEW for ; Wed, 19 Nov 2008 17:34:29 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 0A1613A6BA4 for ; Wed, 19 Nov 2008 17:34:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 1A2927841F9; Wed, 19 Nov 2008 17:34:28 -0800 (PST) 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 2VCP4qMLMP1l; Wed, 19 Nov 2008 17:34:26 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id EF2DD7841F1; Wed, 19 Nov 2008 17:34:24 -0800 (PST) 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 2182F7841F1 for ; Wed, 19 Nov 2008 17:34:23 -0800 (PST) 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 Mi3tkaplNbgN for ; Wed, 19 Nov 2008 17:34:12 -0800 (PST) Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 579917841EF for ; Wed, 19 Nov 2008 17:34:12 -0800 (PST) Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAK1YQwI027375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Nov 2008 01:34:27 GMT Received: from acsmt703.oracle.com (acsmt703.oracle.com [141.146.40.81]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAK1YM5I001730; Thu, 20 Nov 2008 01:34:23 GMT Received: from [141.144.96.142] (/141.144.96.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Nov 2008 01:34:06 +0000 Message-ID: <4924BE8C.2030106@oracle.com> Date: Wed, 19 Nov 2008 20:34:04 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: adrian.crum@yahoo.com References: <694410.9213.qm@web63103.mail.re1.yahoo.com> In-Reply-To: <694410.9213.qm@web63103.mail.re1.yahoo.com> X-Source-IP: acsmt703.oracle.com [141.146.40.81] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010201.4924BE90.0016:SCFSTAT928724,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] EXRULE Question 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 Adrian Crum wrote: > While browsing the internet I ran across the notes from 2006 > regarding deprecating or removing EXRULE and EXDATE from RFC 2445. > The comments made at the time indicated that no one was using it. Only EXRULE was deprecated. EXDATE can still be used. > > I'm curious - without those properties, how would one express a > Monday through Friday at 8:00 AM event, except on US federal > holidays? Now, you are forced to specify EXDATE one by one. And of course the number of EXDATE needs to be finite... Which is what you'll end up with if you create your event with pretty much any calendar client in use today... Cheers, Bernard > > I created an example iCalendar based on the original RFC: > > BEGIN:VCALENDAR > PRODID:-//Apache Open For Business//Work Effort Calendar//EN > VERSION:2.0 > CALSCALE:GREGORIAN > DESCRIPTION:Adrian's Calendar > BEGIN:VEVENT > DTSTAMP:20081112T180905Z > CREATED:20081111T231419Z > LAST-MODIFIED:20081111T232507Z > X-ORG-OFBIZ-WORKEFFORT-ID:10020 > SUMMARY:Work Schedule > DESCRIPTION:Work Schedule > ORGANIZER;CN=THE ADMINISTRATOR: > DTSTART:20080101T000043 > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 > END:VEVENT > END:VCALENDAR > > I can't find any mention of an alternative to using the EXRULE property, so where would one go from here? > > -Adrian > > > > > > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Nov 19 20:33:28 2008 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 A7E093A681C for ; Wed, 19 Nov 2008 20:33:28 -0800 (PST) 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_74=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 EsT1YbOFsmrN for ; Wed, 19 Nov 2008 20:33:27 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id BBE4B3A6358 for ; Wed, 19 Nov 2008 20:33:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id C4DB97841F2; Wed, 19 Nov 2008 20:33:26 -0800 (PST) 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 80DYg1uY6fmt; Wed, 19 Nov 2008 20:33:26 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id CC9EA7841EF; Wed, 19 Nov 2008 20:33:21 -0800 (PST) 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 66D967841F0 for ; Wed, 19 Nov 2008 20:33:19 -0800 (PST) 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 GKrm6BwFe+Du for ; Wed, 19 Nov 2008 20:33:08 -0800 (PST) Received: from web63105.mail.re1.yahoo.com (web63105.mail.re1.yahoo.com [69.147.96.247]) by leka.osafoundation.org (Postfix) with SMTP id EC2DF7841EF for ; Wed, 19 Nov 2008 20:33:07 -0800 (PST) Received: (qmail 63264 invoked by uid 60001); 20 Nov 2008 04:33:07 -0000 X-YMail-OSG: 9B9CYLoVM1mzjpMg8Rt5Y0IDNednnWYPINqJg6YacNqrv6vPD1wWyu.e Received: from [76.167.216.213] by web63105.mail.re1.yahoo.com via HTTP; Wed, 19 Nov 2008 20:33:06 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 19 Nov 2008 20:33:06 -0800 (PST) From: Adrian Crum To: ietf-calsify@osafoundation.org MIME-Version: 1.0 Message-ID: <406748.62999.qm@web63105.mail.re1.yahoo.com> Subject: [ietf-calsify] Fw: Re: EXRULE Question X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian.crum@yahoo.com 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 Oops, I meant for this to go to the mailing list. --- On Wed, 11/19/08, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [ietf-calsify] EXRULE Question > To: "Bernard Desruisseaux" > Date: Wednesday, November 19, 2008, 8:26 PM > Thank you for the reply! > > That is very disappointing. Now I'm forced to define a > finite amount of discreet dates for exclusions instead of > specifying a few rules. > > I was better off with the original specification. > > Other than "no one is using EXRULE" - what is the > compelling reason to remove it from the RFC? Is everyone in > calcify that sure that it will never be used? > > I thought the objective was to simplify and clarify the > RFC, not cripple it. > > -Adrian > > > --- On Wed, 11/19/08, Bernard Desruisseaux > wrote: > > > From: Bernard Desruisseaux > > > Subject: Re: [ietf-calsify] EXRULE Question > > To: adrian.crum@yahoo.com > > Cc: ietf-calsify@osafoundation.org > > Date: Wednesday, November 19, 2008, 5:34 PM > > Adrian Crum wrote: > > > While browsing the internet I ran across the > notes > > from 2006 > > > regarding deprecating or removing EXRULE and > EXDATE > > from RFC 2445. > > > The comments made at the time indicated that no > one > > was using it. > > > > Only EXRULE was deprecated. EXDATE can still be used. > > > > > > > > I'm curious - without those properties, how > would > > one express a > > > Monday through Friday at 8:00 AM event, except on > US > > federal > > > holidays? > > > > Now, you are forced to specify EXDATE one by one. And > of > > course the number of EXDATE needs to be finite... > > > > Which is what you'll end up with if you create > your > > event with pretty much any calendar client in use > today... > > > > Cheers, > > Bernard > > > > > > > > I created an example iCalendar based on the > original > > RFC: > > > > BEGIN:VCALENDAR > > > PRODID:-//Apache Open For Business//Work Effort > > Calendar//EN > > > VERSION:2.0 > > > CALSCALE:GREGORIAN > > > DESCRIPTION:Adrian's Calendar > > > BEGIN:VEVENT > > > DTSTAMP:20081112T180905Z > > > CREATED:20081111T231419Z > > > LAST-MODIFIED:20081111T232507Z > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020 > > > SUMMARY:Work Schedule > > > DESCRIPTION:Work Schedule > > > ORGANIZER;CN=THE ADMINISTRATOR: > > > DTSTART:20080101T000043 > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 > > > END:VEVENT > > > END:VCALENDAR > > > > > > I can't find any mention of an alternative to > > using the EXRULE property, so where would one go from > here? > > > > > > -Adrian > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > ietf-calsify mailing list > > > ietf-calsify@osafoundation.org > > > > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Nov 19 21:24:38 2008 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 A5A2B3A67AC for ; Wed, 19 Nov 2008 21:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.376 X-Spam-Level: X-Spam-Status: No, score=-101.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100] 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 mrvaYjgx5BdC for ; Wed, 19 Nov 2008 21:24:37 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 42EB43A6358 for ; Wed, 19 Nov 2008 21:24:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 692767841EF; Wed, 19 Nov 2008 21:24:36 -0800 (PST) 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 mJFfv0Ai2AXX; Wed, 19 Nov 2008 21:24:35 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 487ED79401D; Wed, 19 Nov 2008 21:24:33 -0800 (PST) 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 88B2E79401D for ; Wed, 19 Nov 2008 21:24:31 -0800 (PST) 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 nAuYxEoCa1Bg for ; Wed, 19 Nov 2008 21:24:20 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by leka.osafoundation.org (Postfix) with ESMTP id 4E9497841EF for ; Wed, 19 Nov 2008 21:24:20 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 31so150477yxl.81 for ; Wed, 19 Nov 2008 21:24:19 -0800 (PST) Received: by 10.64.183.1 with SMTP id g1mr1688798qbf.26.1227158658589; Wed, 19 Nov 2008 21:24:18 -0800 (PST) Received: by 10.64.142.1 with HTTP; Wed, 19 Nov 2008 21:24:18 -0800 (PST) Message-ID: <91390c30811192124g1889e068h40e20f6ea1f0141e@mail.gmail.com> Date: Thu, 20 Nov 2008 16:24:18 +1100 From: "Ben Fortuna" To: adrian.crum@yahoo.com In-Reply-To: <406748.62999.qm@web63105.mail.re1.yahoo.com> MIME-Version: 1.0 References: <406748.62999.qm@web63105.mail.re1.yahoo.com> X-Google-Sender-Auth: 940263d6a8e578c1 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question 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="===============0549158910==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --===============0549158910== Content-Type: multipart/alternative; boundary="----=_Part_2456_5317785.1227158658574" ------=_Part_2456_5317785.1227158658574 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Adrian, I think you'll find it was removed as it is hard to implement, meaning that many CUAs either didn't support it or had a broken implementation. It should be possible to write some code that converts a recurrence rule to a list of dates in a specified period (see iCal4j), so from there it shouldn't be hard to convert an EXRULE to a list of EXDATES, and if you choose a large enough period of time it should achieve the same effect (albeit a bit more verbose). Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties, so things like this should ultimately be transparent. regards, ben On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum wrote: > Oops, I meant for this to go to the mailing list. > > > --- On Wed, 11/19/08, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [ietf-calsify] EXRULE Question > > To: "Bernard Desruisseaux" > > Date: Wednesday, November 19, 2008, 8:26 PM > > Thank you for the reply! > > > > That is very disappointing. Now I'm forced to define a > > finite amount of discreet dates for exclusions instead of > > specifying a few rules. > > > > I was better off with the original specification. > > > > Other than "no one is using EXRULE" - what is the > > compelling reason to remove it from the RFC? Is everyone in > > calcify that sure that it will never be used? > > > > I thought the objective was to simplify and clarify the > > RFC, not cripple it. > > > > -Adrian > > > > > > --- On Wed, 11/19/08, Bernard Desruisseaux > > wrote: > > > > > From: Bernard Desruisseaux > > > > > Subject: Re: [ietf-calsify] EXRULE Question > > > To: adrian.crum@yahoo.com > > > Cc: ietf-calsify@osafoundation.org > > > Date: Wednesday, November 19, 2008, 5:34 PM > > > Adrian Crum wrote: > > > > While browsing the internet I ran across the > > notes > > > from 2006 > > > > regarding deprecating or removing EXRULE and > > EXDATE > > > from RFC 2445. > > > > The comments made at the time indicated that no > > one > > > was using it. > > > > > > Only EXRULE was deprecated. EXDATE can still be used. > > > > > > > > > > > I'm curious - without those properties, how > > would > > > one express a > > > > Monday through Friday at 8:00 AM event, except on > > US > > > federal > > > > holidays? > > > > > > Now, you are forced to specify EXDATE one by one. And > > of > > > course the number of EXDATE needs to be finite... > > > > > > Which is what you'll end up with if you create > > your > > > event with pretty much any calendar client in use > > today... > > > > > > Cheers, > > > Bernard > > > > > > > > > > > I created an example iCalendar based on the > > original > > > RFC: > > > > > BEGIN:VCALENDAR > > > > PRODID:-//Apache Open For Business//Work Effort > > > Calendar//EN > > > > VERSION:2.0 > > > > CALSCALE:GREGORIAN > > > > DESCRIPTION:Adrian's Calendar > > > > BEGIN:VEVENT > > > > DTSTAMP:20081112T180905Z > > > > CREATED:20081111T231419Z > > > > LAST-MODIFIED:20081111T232507Z > > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020 > > > > SUMMARY:Work Schedule > > > > DESCRIPTION:Work Schedule > > > > ORGANIZER;CN=THE ADMINISTRATOR: > > > > DTSTART:20080101T000043 > > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 > > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 > > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH > > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 > > > > END:VEVENT > > > > END:VCALENDAR > > > > > > > > I can't find any mention of an alternative to > > > using the EXRULE property, so where would one go from > > here? > > > > > > > > -Adrian > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > ietf-calsify mailing list > > > > ietf-calsify@osafoundation.org > > > > > > > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > > > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -- Less Talk More Gossip http://elbento.com Dan Quayle - "This President is going to lead us out of this recovery." ------=_Part_2456_5317785.1227158658574 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Adrian,

I think you'll find it was removed as it is hard to implement, meaning that many CUAs either didn't support it or had a broken implementation.

It should be possible to write some code that converts a recurrence rule to a list of  dates in a specified period (see iCal4j), so from there it shouldn't be hard to convert an EXRULE to a list of EXDATES, and if you choose a large enough period of time it should achieve the same effect (albeit a bit more verbose).

Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties, so things like this should ultimately be transparent.

regards,
ben


On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum <adrian.crum@yahoo.com> wrote:
Oops, I meant for this to go to the mailing list.


--- On Wed, 11/19/08, Adrian Crum <adrian.crum@yahoo.com> wrote:

> From: Adrian Crum <adrian.crum@yahoo.com>
> Subject: Re: [ietf-calsify] EXRULE Question
> To: "Bernard Desruisseaux" <bernard.desruisseaux@oracle.com>
> Date: Wednesday, November 19, 2008, 8:26 PM
> Thank you for the reply!
>
> That is very disappointing. Now I'm forced to define a
> finite amount of discreet dates for exclusions instead of
> specifying a few rules.
>
> I was better off with the original specification.
>
> Other than "no one is using EXRULE" - what is the
> compelling reason to remove it from the RFC? Is everyone in
> calcify that sure that it will never be used?
>
> I thought the objective was to simplify and clarify the
> RFC, not cripple it.
>
> -Adrian
>
>
> --- On Wed, 11/19/08, Bernard Desruisseaux
> <bernard.desruisseaux@oracle.com> wrote:
>
> > From: Bernard Desruisseaux
> <bernard.desruisseaux@oracle.com>
> > Subject: Re: [ietf-calsify] EXRULE Question
> > To: adrian.crum@yahoo.com
> > Cc: ietf-calsify@osafoundation.org
> > Date: Wednesday, November 19, 2008, 5:34 PM
> > Adrian Crum wrote:
> > > While browsing the internet I ran across the
> notes
> > from 2006
> > > regarding deprecating or removing EXRULE and
> EXDATE
> > from RFC 2445.
> > > The comments made at the time indicated that no
> one
> > was using it.
> >
> > Only EXRULE was deprecated.  EXDATE can still be used.
> >
> > >
> > > I'm curious - without those properties, how
> would
> > one express a
> > > Monday through Friday at 8:00 AM event, except on
> US
> > federal
> > > holidays?
> >
> > Now, you are forced to specify EXDATE one by one. And
> of
> > course the number of EXDATE needs to be finite...
> >
> > Which is what you'll end up with if you create
> your
> > event with pretty much any calendar client in use
> today...
> >
> > Cheers,
> > Bernard
> >
> > >
> > > I created an example iCalendar based on the
> original
> > RFC: >
> > > BEGIN:VCALENDAR
> > > PRODID:-//Apache Open For Business//Work Effort
> > Calendar//EN
> > > VERSION:2.0
> > > CALSCALE:GREGORIAN
> > > DESCRIPTION:Adrian's Calendar
> > > BEGIN:VEVENT
> > > DTSTAMP:20081112T180905Z
> > > CREATED:20081111T231419Z
> > > LAST-MODIFIED:20081111T232507Z
> > > X-ORG-OFBIZ-WORKEFFORT-ID:10020
> > > SUMMARY:Work Schedule
> > > DESCRIPTION:Work Schedule
> > > ORGANIZER;CN=THE ADMINISTRATOR:
> > > DTSTART:20080101T000043
> > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
> > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
> > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
> > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
> > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
> > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
> > > END:VEVENT
> > > END:VCALENDAR
> > >
> > > I can't find any mention of an alternative to
> > using the EXRULE property, so where would one go from
> here?
> > >
> > > -Adrian
> > >
> > >
> > >
> > >
> > >
> > >
> _______________________________________________
> > > ietf-calsify mailing list
> > > ietf-calsify@osafoundation.org
> > >
> >
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> > >



_______________________________________________
ietf-calsify mailing list
ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



--
Less Talk More Gossip
http://elbento.com

Dan Quayle  - "This President is going to lead us out of this recovery." ------=_Part_2456_5317785.1227158658574-- --===============0549158910== 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 --===============0549158910==-- From ietf-calsify-bounces@osafoundation.org Wed Nov 19 21:26:45 2008 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 3159C3A67E7 for ; Wed, 19 Nov 2008 21:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.776 X-Spam-Level: X-Spam-Status: No, score=-100.776 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100] 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 xgexE9ql4+K0 for ; Wed, 19 Nov 2008 21:26:43 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id E9E3C3A6358 for ; Wed, 19 Nov 2008 21:26:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 01ACB794028; Wed, 19 Nov 2008 21:26:43 -0800 (PST) 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 7z6bqJ3XPIpk; Wed, 19 Nov 2008 21:26:39 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 76C227841F0; Wed, 19 Nov 2008 21:26:39 -0800 (PST) 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 621307841F0 for ; Wed, 19 Nov 2008 21:26:37 -0800 (PST) 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 MHTH8uPtv+JK for ; Wed, 19 Nov 2008 21:26:35 -0800 (PST) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.250]) by leka.osafoundation.org (Postfix) with ESMTP id ECCF47841EF for ; Wed, 19 Nov 2008 21:26:34 -0800 (PST) Received: by hs-out-0708.google.com with SMTP id 54so165502hsz.11 for ; Wed, 19 Nov 2008 21:26:34 -0800 (PST) Received: by 10.64.210.3 with SMTP id i3mr1684797qbg.30.1227158793852; Wed, 19 Nov 2008 21:26:33 -0800 (PST) Received: by 10.64.142.1 with HTTP; Wed, 19 Nov 2008 21:26:33 -0800 (PST) Message-ID: <91390c30811192126o4585d842n2ad1dba456450044@mail.gmail.com> Date: Thu, 20 Nov 2008 16:26:33 +1100 From: "Ben Fortuna" To: adrian.crum@yahoo.com In-Reply-To: <91390c30811192124g1889e068h40e20f6ea1f0141e@mail.gmail.com> MIME-Version: 1.0 References: <406748.62999.qm@web63105.mail.re1.yahoo.com> <91390c30811192124g1889e068h40e20f6ea1f0141e@mail.gmail.com> X-Google-Sender-Auth: 144749febf22f064 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question 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="===============0510115207==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --===============0510115207== Content-Type: multipart/alternative; boundary="----=_Part_2498_12805163.1227158793860" ------=_Part_2498_12805163.1227158793860 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry, that should read: "Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties *in iCal4j*, so things like this should ultimately be transparent." On Thu, Nov 20, 2008 at 4:24 PM, Ben Fortuna wrote: > Adrian, > > I think you'll find it was removed as it is hard to implement, meaning that > many CUAs either didn't support it or had a broken implementation. > > It should be possible to write some code that converts a recurrence rule to > a list of dates in a specified period (see iCal4j), so from there it > shouldn't be hard to convert an EXRULE to a list of EXDATES, and if you > choose a large enough period of time it should achieve the same effect > (albeit a bit more verbose). > > Once the new RFC is approved I might investigate supporting automatic > conversion of deprecated properties, so things like this should ultimately > be transparent. > > regards, > ben > > > > On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum wrote: > >> Oops, I meant for this to go to the mailing list. >> >> >> --- On Wed, 11/19/08, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [ietf-calsify] EXRULE Question >> > To: "Bernard Desruisseaux" >> > Date: Wednesday, November 19, 2008, 8:26 PM >> > Thank you for the reply! >> > >> > That is very disappointing. Now I'm forced to define a >> > finite amount of discreet dates for exclusions instead of >> > specifying a few rules. >> > >> > I was better off with the original specification. >> > >> > Other than "no one is using EXRULE" - what is the >> > compelling reason to remove it from the RFC? Is everyone in >> > calcify that sure that it will never be used? >> > >> > I thought the objective was to simplify and clarify the >> > RFC, not cripple it. >> > >> > -Adrian >> > >> > >> > --- On Wed, 11/19/08, Bernard Desruisseaux >> > wrote: >> > >> > > From: Bernard Desruisseaux >> > >> > > Subject: Re: [ietf-calsify] EXRULE Question >> > > To: adrian.crum@yahoo.com >> > > Cc: ietf-calsify@osafoundation.org >> > > Date: Wednesday, November 19, 2008, 5:34 PM >> > > Adrian Crum wrote: >> > > > While browsing the internet I ran across the >> > notes >> > > from 2006 >> > > > regarding deprecating or removing EXRULE and >> > EXDATE >> > > from RFC 2445. >> > > > The comments made at the time indicated that no >> > one >> > > was using it. >> > > >> > > Only EXRULE was deprecated. EXDATE can still be used. >> > > >> > > > >> > > > I'm curious - without those properties, how >> > would >> > > one express a >> > > > Monday through Friday at 8:00 AM event, except on >> > US >> > > federal >> > > > holidays? >> > > >> > > Now, you are forced to specify EXDATE one by one. And >> > of >> > > course the number of EXDATE needs to be finite... >> > > >> > > Which is what you'll end up with if you create >> > your >> > > event with pretty much any calendar client in use >> > today... >> > > >> > > Cheers, >> > > Bernard >> > > >> > > > >> > > > I created an example iCalendar based on the >> > original >> > > RFC: > >> > > > BEGIN:VCALENDAR >> > > > PRODID:-//Apache Open For Business//Work Effort >> > > Calendar//EN >> > > > VERSION:2.0 >> > > > CALSCALE:GREGORIAN >> > > > DESCRIPTION:Adrian's Calendar >> > > > BEGIN:VEVENT >> > > > DTSTAMP:20081112T180905Z >> > > > CREATED:20081111T231419Z >> > > > LAST-MODIFIED:20081111T232507Z >> > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020 >> > > > SUMMARY:Work Schedule >> > > > DESCRIPTION:Work Schedule >> > > > ORGANIZER;CN=THE ADMINISTRATOR: >> > > > DTSTART:20080101T000043 >> > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 >> > > > END:VEVENT >> > > > END:VCALENDAR >> > > > >> > > > I can't find any mention of an alternative to >> > > using the EXRULE property, so where would one go from >> > here? >> > > > >> > > > -Adrian >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > _______________________________________________ >> > > > ietf-calsify mailing list >> > > > ietf-calsify@osafoundation.org >> > > > >> > > >> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> > > > >> >> >> >> _______________________________________________ >> ietf-calsify mailing list >> ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> > > > -- > Dan Quayle - "This President is going to lead us out of this recovery." -- Fred Allen - "An associate producer is the only guy in Hollywood who will associate with a producer." ------=_Part_2498_12805163.1227158793860 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry, that should read:

"Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties in iCal4j, so things like this should ultimately be transparent."


On Thu, Nov 20, 2008 at 4:24 PM, Ben Fortuna <fortuna@users.sourceforge.net> wrote:
Adrian,

I think you'll find it was removed as it is hard to implement, meaning that many CUAs either didn't support it or had a broken implementation.

It should be possible to write some code that converts a recurrence rule to a list of  dates in a specified period (see iCal4j), so from there it shouldn't be hard to convert an EXRULE to a list of EXDATES, and if you choose a large enough period of time it should achieve the same effect (albeit a bit more verbose).

Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties, so things like this should ultimately be transparent.

regards,
ben



On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum <adrian.crum@yahoo.com> wrote:
Oops, I meant for this to go to the mailing list.


--- On Wed, 11/19/08, Adrian Crum <adrian.crum@yahoo.com> wrote:

> From: Adrian Crum <adrian.crum@yahoo.com>
> Subject: Re: [ietf-calsify] EXRULE Question
> To: "Bernard Desruisseaux" <bernard.desruisseaux@oracle.com>
> Date: Wednesday, November 19, 2008, 8:26 PM
> Thank you for the reply!
>
> That is very disappointing. Now I'm forced to define a
> finite amount of discreet dates for exclusions instead of
> specifying a few rules.
>
> I was better off with the original specification.
>
> Other than "no one is using EXRULE" - what is the
> compelling reason to remove it from the RFC? Is everyone in
> calcify that sure that it will never be used?
>
> I thought the objective was to simplify and clarify the
> RFC, not cripple it.
>
> -Adrian
>
>
> --- On Wed, 11/19/08, Bernard Desruisseaux
> <bernard.desruisseaux@oracle.com> wrote:
>
> > From: Bernard Desruisseaux
> <bernard.desruisseaux@oracle.com>
> > Subject: Re: [ietf-calsify] EXRULE Question
> > To: adrian.crum@yahoo.com
> > Cc: ietf-calsify@osafoundation.org
> > Date: Wednesday, November 19, 2008, 5:34 PM
> > Adrian Crum wrote:
> > > While browsing the internet I ran across the
> notes
> > from 2006
> > > regarding deprecating or removing EXRULE and
> EXDATE
> > from RFC 2445.
> > > The comments made at the time indicated that no
> one
> > was using it.
> >
> > Only EXRULE was deprecated.  EXDATE can still be used.
> >
> > >
> > > I'm curious - without those properties, how
> would
> > one express a
> > > Monday through Friday at 8:00 AM event, except on
> US
> > federal
> > > holidays?
> >
> > Now, you are forced to specify EXDATE one by one. And
> of
> > course the number of EXDATE needs to be finite...
> >
> > Which is what you'll end up with if you create
> your
> > event with pretty much any calendar client in use
> today...
> >
> > Cheers,
> > Bernard
> >
> > >
> > > I created an example iCalendar based on the
> original
> > RFC: >
> > > BEGIN:VCALENDAR
> > > PRODID:-//Apache Open For Business//Work Effort
> > Calendar//EN
> > > VERSION:2.0
> > > CALSCALE:GREGORIAN
> > > DESCRIPTION:Adrian's Calendar
> > > BEGIN:VEVENT
> > > DTSTAMP:20081112T180905Z
> > > CREATED:20081111T231419Z
> > > LAST-MODIFIED:20081111T232507Z
> > > X-ORG-OFBIZ-WORKEFFORT-ID:10020
> > > SUMMARY:Work Schedule
> > > DESCRIPTION:Work Schedule
> > > ORGANIZER;CN=THE ADMINISTRATOR:
> > > DTSTART:20080101T000043
> > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
> > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
> > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
> > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
> > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
> > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
> > > END:VEVENT
> > > END:VCALENDAR
> > >
> > > I can't find any mention of an alternative to
> > using the EXRULE property, so where would one go from
> here?
> > >
> > > -Adrian
> > >
> > >
> > >
> > >
> > >
> > >
> _______________________________________________
> > > ietf-calsify mailing list
> > > ietf-calsify@osafoundation.org
> > >
> >
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> > >



_______________________________________________
ietf-calsify mailing list
ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


--
Dan Quayle  - "This President is going to lead us out of this recovery."



--
Fred Allen  - "An associate producer is the only guy in Hollywood who will associate with a producer." ------=_Part_2498_12805163.1227158793860-- --===============0510115207== 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 --===============0510115207==-- From ietf-calsify-bounces@osafoundation.org Wed Nov 19 21:36:30 2008 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 2AD8B3A690A for ; Wed, 19 Nov 2008 21:36:30 -0800 (PST) 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_74=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 EIehjjP-xELP for ; Wed, 19 Nov 2008 21:36:29 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 3173B3A657C for ; Wed, 19 Nov 2008 21:36:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 4688F794026; Wed, 19 Nov 2008 21:36:28 -0800 (PST) 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 hGgB6GRRpvLB; Wed, 19 Nov 2008 21:36:25 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id D27CB79401D; Wed, 19 Nov 2008 21:36:23 -0800 (PST) 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 D483179401D for ; Wed, 19 Nov 2008 21:36:21 -0800 (PST) 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 X5T12bM1l7I1 for ; Wed, 19 Nov 2008 21:36:19 -0800 (PST) Received: from web63102.mail.re1.yahoo.com (web63102.mail.re1.yahoo.com [69.147.96.244]) by leka.osafoundation.org (Postfix) with SMTP id 702827841EF for ; Wed, 19 Nov 2008 21:36:19 -0800 (PST) Received: (qmail 51986 invoked by uid 60001); 20 Nov 2008 05:36:18 -0000 X-YMail-OSG: 5zP92_cVM1k_XQYTggCOXcfmqtd6bqSnWBzhVsaQ7iOu88fklV962n6vAL5Upj1UJvAdETVqI6V.3a5lBi3deLVtRbPbA5xlJhsfqZlRLkKuxbl5KYtryoknpDSY1r13ZML7GUvAW5MpIkEwyusyDqCQXBk- Received: from [76.167.216.213] by web63102.mail.re1.yahoo.com via HTTP; Wed, 19 Nov 2008 21:36:18 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 19 Nov 2008 21:36:18 -0800 (PST) From: Adrian Crum To: ietf-calsify@osafoundation.org In-Reply-To: <91390c30811192124g1889e068h40e20f6ea1f0141e@mail.gmail.com> MIME-Version: 1.0 Message-ID: <612821.51679.qm@web63102.mail.re1.yahoo.com> Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian.crum@yahoo.com 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 Ben, Thanks for the reply. I disagree that it is hard to implement. The original RFC was clear and easy to implement: 1. Create a union of all RDATEs and RRULEs 2. Create a union of all EXDATEs and EXRULEs 3. Create a difference of the two unions I know this is easy to implement because I've done it. My example works with the original RFC. I challenge anyone to prove that it doesn't work with the original RFC. Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS the original. That is the point I am trying to make. Calcify isn't just simplifying or clarifying the spec, it is breaking it. -Adrian --- On Wed, 11/19/08, Ben Fortuna wrote: > From: Ben Fortuna > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question > To: adrian.crum@yahoo.com > Cc: ietf-calsify@osafoundation.org > Date: Wednesday, November 19, 2008, 9:24 PM > Adrian, > > I think you'll find it was removed as it is hard to > implement, meaning that > many CUAs either didn't support it or had a broken > implementation. > > It should be possible to write some code that converts a > recurrence rule to > a list of dates in a specified period (see iCal4j), so > from there it > shouldn't be hard to convert an EXRULE to a list of > EXDATES, and if you > choose a large enough period of time it should achieve the > same effect > (albeit a bit more verbose). > > Once the new RFC is approved I might investigate supporting > automatic > conversion of deprecated properties, so things like this > should ultimately > be transparent. > > regards, > ben > > > On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum > wrote: > > > Oops, I meant for this to go to the mailing list. > > > > > > --- On Wed, 11/19/08, Adrian Crum > wrote: > > > > > From: Adrian Crum > > > Subject: Re: [ietf-calsify] EXRULE Question > > > To: "Bernard Desruisseaux" > > > > Date: Wednesday, November 19, 2008, 8:26 PM > > > Thank you for the reply! > > > > > > That is very disappointing. Now I'm forced to > define a > > > finite amount of discreet dates for exclusions > instead of > > > specifying a few rules. > > > > > > I was better off with the original specification. > > > > > > Other than "no one is using EXRULE" - > what is the > > > compelling reason to remove it from the RFC? Is > everyone in > > > calcify that sure that it will never be used? > > > > > > I thought the objective was to simplify and > clarify the > > > RFC, not cripple it. > > > > > > -Adrian > > > > > > > > > --- On Wed, 11/19/08, Bernard Desruisseaux > > > wrote: > > > > > > > From: Bernard Desruisseaux > > > > > > > Subject: Re: [ietf-calsify] EXRULE Question > > > > To: adrian.crum@yahoo.com > > > > Cc: ietf-calsify@osafoundation.org > > > > Date: Wednesday, November 19, 2008, 5:34 PM > > > > Adrian Crum wrote: > > > > > While browsing the internet I ran > across the > > > notes > > > > from 2006 > > > > > regarding deprecating or removing > EXRULE and > > > EXDATE > > > > from RFC 2445. > > > > > The comments made at the time indicated > that no > > > one > > > > was using it. > > > > > > > > Only EXRULE was deprecated. EXDATE can > still be used. > > > > > > > > > > > > > > I'm curious - without those > properties, how > > > would > > > > one express a > > > > > Monday through Friday at 8:00 AM event, > except on > > > US > > > > federal > > > > > holidays? > > > > > > > > Now, you are forced to specify EXDATE one by > one. And > > > of > > > > course the number of EXDATE needs to be > finite... > > > > > > > > Which is what you'll end up with if you > create > > > your > > > > event with pretty much any calendar client > in use > > > today... > > > > > > > > Cheers, > > > > Bernard > > > > > > > > > > > > > > I created an example iCalendar based on > the > > > original > > > > RFC: > > > > > > BEGIN:VCALENDAR > > > > > PRODID:-//Apache Open For > Business//Work Effort > > > > Calendar//EN > > > > > VERSION:2.0 > > > > > CALSCALE:GREGORIAN > > > > > DESCRIPTION:Adrian's Calendar > > > > > BEGIN:VEVENT > > > > > DTSTAMP:20081112T180905Z > > > > > CREATED:20081111T231419Z > > > > > LAST-MODIFIED:20081111T232507Z > > > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020 > > > > > SUMMARY:Work Schedule > > > > > DESCRIPTION:Work Schedule > > > > > ORGANIZER;CN=THE ADMINISTRATOR: > > > > > DTSTART:20080101T000043 > > > > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 > > > > > END:VEVENT > > > > > END:VCALENDAR > > > > > > > > > > I can't find any mention of an > alternative to > > > > using the EXRULE property, so where would > one go from > > > here? > > > > > > > > > > -Adrian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > ietf-calsify mailing list > > > > > ietf-calsify@osafoundation.org > > > > > > > > > > > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > > > > > > > > > _______________________________________________ > > ietf-calsify mailing list > > ietf-calsify@osafoundation.org > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > > -- > Less Talk More Gossip > http://elbento.com > > Dan Quayle - "This President is going to lead us out > of this recovery." _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Nov 20 03:12:37 2008 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 71C303A69B6 for ; Thu, 20 Nov 2008 03:12:37 -0800 (PST) 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_74=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 XRR1DSfALGNj for ; Thu, 20 Nov 2008 03:12:35 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id AC6243A6837 for ; Thu, 20 Nov 2008 03:12:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id CA5147841F1; Thu, 20 Nov 2008 03:12:34 -0800 (PST) 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 wVzy-yV77U4u; Thu, 20 Nov 2008 03:12:34 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 5CA6477D700; Thu, 20 Nov 2008 03:12:29 -0800 (PST) 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 B1EFF77D700 for ; Thu, 20 Nov 2008 03:12:26 -0800 (PST) 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 nkXBzZR3p09R for ; Thu, 20 Nov 2008 03:12:14 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id CE3FB77D6FF for ; Thu, 20 Nov 2008 03:12:13 -0800 (PST) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.8/8.13.8/Debian-3) with ESMTP id mAKBCAtj015817; Thu, 20 Nov 2008 12:12:10 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org, adrian.crum@yahoo.com Date: Thu, 20 Nov 2008 12:12:05 +0100 User-Agent: KMail/1.9.10 References: <612821.51679.qm@web63102.mail.re1.yahoo.com> In-Reply-To: <612821.51679.qm@web63102.mail.re1.yahoo.com> Content-Disposition: inline Message-Id: <200811201212.09374.reinhold@kainhofer.com> Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 20. November 2008 schrieb Adrian Crum: > I disagree that it is hard to implement. So do I. While KOrganizer has no GUI for creating EXRULE, our libkcal library supports an arbitrary number of RRULEs and EXRULEs. KOrganizer of course also correctly shows these events. > The original RFC was clear and > easy to implement: > > 1. Create a union of all RDATEs and RRULEs > 2. Create a union of all EXDATEs and EXRULEs > 3. Create a difference of the two unions Exactly. Once you have some code creating the recurrence set for one rule, the rest is really simple. Cheers, Reinhold > I know this is easy to implement because I've done it. My example works > with the original RFC. I challenge anyone to prove that it doesn't work > with the original RFC. > > Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS > the original. > > That is the point I am trying to make. Calcify isn't just simplifying or > clarifying the spec, it is breaking it. > > -Adrian > > --- On Wed, 11/19/08, Ben Fortuna wrote: > > From: Ben Fortuna > > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question > > To: adrian.crum@yahoo.com > > Cc: ietf-calsify@osafoundation.org > > Date: Wednesday, November 19, 2008, 9:24 PM > > Adrian, > > > > I think you'll find it was removed as it is hard to > > implement, meaning that > > many CUAs either didn't support it or had a broken > > implementation. > > > > It should be possible to write some code that converts a > > recurrence rule to > > a list of dates in a specified period (see iCal4j), so > > from there it > > shouldn't be hard to convert an EXRULE to a list of > > EXDATES, and if you > > choose a large enough period of time it should achieve the > > same effect > > (albeit a bit more verbose). > > > > Once the new RFC is approved I might investigate supporting > > automatic > > conversion of deprecated properties, so things like this > > should ultimately > > be transparent. > > > > regards, > > ben > > > > > > On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum > > > > wrote: > > > Oops, I meant for this to go to the mailing list. > > > > > > > > > --- On Wed, 11/19/08, Adrian Crum > > > > wrote: > > > > From: Adrian Crum > > > > Subject: Re: [ietf-calsify] EXRULE Question > > > > To: "Bernard Desruisseaux" > > > > > > > > > > Date: Wednesday, November 19, 2008, 8:26 PM > > > > Thank you for the reply! > > > > > > > > That is very disappointing. Now I'm forced to > > > > define a > > > > > > finite amount of discreet dates for exclusions > > > > instead of > > > > > > specifying a few rules. > > > > > > > > I was better off with the original specification. > > > > > > > > Other than "no one is using EXRULE" - > > > > what is the > > > > > > compelling reason to remove it from the RFC? Is > > > > everyone in > > > > > > calcify that sure that it will never be used? > > > > > > > > I thought the objective was to simplify and > > > > clarify the > > > > > > RFC, not cripple it. > > > > > > > > -Adrian > > > > > > > > > > > > --- On Wed, 11/19/08, Bernard Desruisseaux > > > > > > > > wrote: > > > > > From: Bernard Desruisseaux > > > > > > > > > > > > > > > > > Subject: Re: [ietf-calsify] EXRULE Question > > > > > To: adrian.crum@yahoo.com > > > > > Cc: ietf-calsify@osafoundation.org > > > > > Date: Wednesday, November 19, 2008, 5:34 PM > > > > > > > > > > Adrian Crum wrote: > > > > > > While browsing the internet I ran > > > > across the > > > > > > notes > > > > > > > > > from 2006 > > > > > > > > > > > regarding deprecating or removing > > > > EXRULE and > > > > > > EXDATE > > > > > > > > > from RFC 2445. > > > > > > > > > > > The comments made at the time indicated > > > > that no > > > > > > one > > > > > > > > > was using it. > > > > > > > > > > Only EXRULE was deprecated. EXDATE can > > > > still be used. > > > > > > > > I'm curious - without those > > > > properties, how > > > > > > would > > > > > > > > > one express a > > > > > > > > > > > Monday through Friday at 8:00 AM event, > > > > except on > > > > > > US > > > > > > > > > federal > > > > > > > > > > > holidays? > > > > > > > > > > Now, you are forced to specify EXDATE one by > > > > one. And > > > > > > of > > > > > > > > > course the number of EXDATE needs to be > > > > finite... > > > > > > > Which is what you'll end up with if you > > > > create > > > > > > your > > > > > > > > > event with pretty much any calendar client > > > > in use > > > > > > today... > > > > > > > > > Cheers, > > > > > Bernard > > > > > > > > > > > I created an example iCalendar based on > > > > the > > > > > > original > > > > > > > > > RFC: > > > > > > > > > > > > BEGIN:VCALENDAR > > > > > > PRODID:-//Apache Open For > > > > Business//Work Effort > > > > > > > Calendar//EN > > > > > > > > > > > VERSION:2.0 > > > > > > CALSCALE:GREGORIAN > > > > > > DESCRIPTION:Adrian's Calendar > > > > > > BEGIN:VEVENT > > > > > > DTSTAMP:20081112T180905Z > > > > > > CREATED:20081111T231419Z > > > > > > LAST-MODIFIED:20081111T232507Z > > > > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020 > > > > > > SUMMARY:Work Schedule > > > > > > DESCRIPTION:Work Schedule > > > > > > ORGANIZER;CN=THE ADMINISTRATOR: > > > > > > DTSTART:20080101T000043 > > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 > > > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 > > > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 > > > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH > > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 > > > > > > > > END:VEVENT > > > > > > END:VCALENDAR > > > > > > > > > > > > I can't find any mention of an > > > > alternative to > > > > > > > using the EXRULE property, so where would > > > > one go from > > > > > > here? > > > > > > > > > > -Adrian > > > > > > > > _______________________________________________ > > > > > > > > > > ietf-calsify mailing list > > > > > > ietf-calsify@osafoundation.org > > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > _______________________________________________ > > > ietf-calsify mailing list > > > ietf-calsify@osafoundation.org > > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > > > > > > -- > > Less Talk More Gossip > > http://elbento.com > > > > Dan Quayle - "This President is going to lead us out > > of this recovery." > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJJUYJTqjEwhXvPN0RApRkAJ0a2C8kKowuzBGEhLR5d1chFgUgsgCdE7Bf R/+5ecN8D5w4XUQqlFyBhLQ= =nrSO -----END PGP SIGNATURE----- _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Nov 20 05:05:59 2008 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 4279D3A6768 for ; Thu, 20 Nov 2008 05:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 uxVBQ1M-6dw6 for ; Thu, 20 Nov 2008 05:05:58 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 51D1B3A63D2 for ; Thu, 20 Nov 2008 05:05:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 4D368794024; Thu, 20 Nov 2008 05:05:57 -0800 (PST) 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 h6Va6RfZepjD; Thu, 20 Nov 2008 05:05:47 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 8BDEA77D6FE; Thu, 20 Nov 2008 05:05:41 -0800 (PST) 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 A15AF77D6FE for ; Thu, 20 Nov 2008 05:04:45 -0800 (PST) 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 OgtbjrYrXdTT for ; Thu, 20 Nov 2008 05:04:36 -0800 (PST) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by leka.osafoundation.org (Postfix) with ESMTP id 502DF77D6FB for ; Thu, 20 Nov 2008 05:04:36 -0800 (PST) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 628208689bc42837d65b316acd4bd2d1 X-Spam-Score-Summary: 2, 0, 0, 47f6250fe99c435d, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, adrian.crum@yahoo.com:ietf-calsify@osafoundation.org, RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:988:989:1155:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2076:2393:2559:2562:2693:2828:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3874:3876:3877:4250:5007:6114:7875:8501, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from NIGEL08 (unverified [192.168.1.103]) by mail.rockliffe.com (Rockliffe SMTPRA 9.0.1) with ESMTP id ; Thu, 20 Nov 2008 05:04:33 -0800 Message-ID: <4740FB101D26453C8E01391DCC93229F@NIGEL08> From: "Nigel Swinson" To: References: <612821.51679.qm@web63102.mail.re1.yahoo.com> Date: Thu, 20 Nov 2008 13:04:30 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question 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 > Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS > the original. > > That is the point I am trying to make. Calcify isn't just simplifying or > clarifying the spec, it is breaking it. Dropping EXRULE doesn't mean it can never exist, it just means it doesn't exist in the base spec. This makes the spec overall simpler to implement, which will increase the number of implementations, and maximize interoperability. I class the two most complex areas of iCalendar to be timezone processing and recurrence, and think dropping EXRULE from the "base" spec was an excellent idea as it simplifies one of those complex areas, while still providing in the "base" spec a way to achieve the same functionality - using EXDATE. Perhaps there's a need for an extension to iCalendar that defines all the stuff that got taken out, so implementations like yours can cite support for the extended specification, and new impelementations can start with the base spec, and then later on consider implementing the extended specifications? Nigel _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Nov 20 07:07:31 2008 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 DAE9A3A6989 for ; Thu, 20 Nov 2008 07:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 MCWVfbMdUKxm for ; Thu, 20 Nov 2008 07:07:31 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id F11553A692F for ; Thu, 20 Nov 2008 07:07:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 17A9777D700; Thu, 20 Nov 2008 07:07:30 -0800 (PST) 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 ZmQnUMnzcpFo; Thu, 20 Nov 2008 07:07:29 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 68DBC77D6FE; Thu, 20 Nov 2008 07:07:25 -0800 (PST) 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 660B477D6FE for ; Thu, 20 Nov 2008 07:07:23 -0800 (PST) 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 JAAM27-m0ecW for ; Thu, 20 Nov 2008 07:07:13 -0800 (PST) Received: from daboo.name (daboo.name [151.201.22.177]) by leka.osafoundation.org (Postfix) with ESMTP id B890577D6FB for ; Thu, 20 Nov 2008 07:07:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7BC55F2865F; Thu, 20 Nov 2008 10:07:05 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yk39jCidt1e; Thu, 20 Nov 2008 10:07:05 -0500 (EST) Received: from [130.129.29.197] (unknown [130.129.29.197]) by daboo.name (Postfix) with ESMTP id 87A24F28658; Thu, 20 Nov 2008 10:07:04 -0500 (EST) Date: Thu, 20 Nov 2008 09:07:04 -0600 From: Cyrus Daboo To: adrian.crum@yahoo.com, ietf-calsify@osafoundation.org Message-ID: In-Reply-To: <612821.51679.qm@web63102.mail.re1.yahoo.com> References: <612821.51679.qm@web63102.mail.re1.yahoo.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question 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 Hi Adrian, --On November 19, 2008 9:36:18 PM -0800 Adrian Crum wrote: > I disagree that it is hard to implement. The original RFC was clear and > easy to implement: Actually it was not clear. Without restating all the discussion we had before on this, there are some clear ambiguities in the spec that meant interpretation of EXRULE was up to the implementer. Just because you implemented it in a way that works for your data does not mean it will work the same way in some other product/library. As an example, the original spec states in the EXRULE definition: "The "DTSTART" defines the first instance in the recurrence set.". The (correct) reading of this is that an EXRULE will always exclude the first instance in any recurrence set. This means, if you really don't want the first instance cancelled, you have to adjust the event in some way to create a fake "first" instance that is OK to cancel, and then hope the rule does not match the second etc but in doing that you may break the behavior of RRULEs also present. That is just one example of ambiguity and lack of clarity. Whilst it might have been possible to tighten up the definitions like this, the WG looked not only looked at these ambiguities but also at how widely the feature was supported and used (interoperably) and then came to consensus on removal. -- Cyrus Daboo _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Nov 20 07:58:54 2008 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 37BEA3A67DB for ; Thu, 20 Nov 2008 07:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 i4IewwV7yiEg for ; Thu, 20 Nov 2008 07:58:53 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 2A93A3A67B5 for ; Thu, 20 Nov 2008 07:58:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 3241D77D700; Thu, 20 Nov 2008 07:58:52 -0800 (PST) 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 UxxszYXn5tGL; Thu, 20 Nov 2008 07:58:51 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id D2A4F77D6FE; Thu, 20 Nov 2008 07:58:47 -0800 (PST) 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 44BD477D6FE for ; Thu, 20 Nov 2008 07:58:46 -0800 (PST) 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 ME1MY7GhVPCw for ; Thu, 20 Nov 2008 07:58:35 -0800 (PST) Received: from web63107.mail.re1.yahoo.com (web63107.mail.re1.yahoo.com [69.147.97.2]) by leka.osafoundation.org (Postfix) with SMTP id 40D6B77D6FB for ; Thu, 20 Nov 2008 07:58:35 -0800 (PST) Received: (qmail 41729 invoked by uid 60001); 20 Nov 2008 15:58:34 -0000 X-YMail-OSG: 75LjEyAVM1nRSVVIc.n_rFDwKSnEgxFX5LzDG4fr25BPplvx7ncjTViomX3E0M5xzLONvAkzaicoGUkW9a7RmfFvrKCiVnI4QbzREuBb.mLWTB_bxk4b9JTh6UT4V72sz.COMR6hqSl.eECwPnqShxSqxVQ- Received: from [71.119.123.156] by web63107.mail.re1.yahoo.com via HTTP; Thu, 20 Nov 2008 07:58:34 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Thu, 20 Nov 2008 07:58:34 -0800 (PST) From: Adrian Crum To: ietf-calsify@osafoundation.org MIME-Version: 1.0 Message-ID: <357145.41096.qm@web63107.mail.re1.yahoo.com> Subject: [ietf-calsify] Fw: Re: Fw: Re: EXRULE Question X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian.crum@yahoo.com 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 Oops, I did it again. --- On Thu, 11/20/08, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question > To: "Cyrus Daboo" > Date: Thursday, November 20, 2008, 7:58 AM > Many thanks to everyone who replied! > > I'm late bringing this subject up because I didn't > discover it until recently. I was working on integrating > iCalendar with an open source ERP program and when certain > CUAs didn't accept the program's output I ended up > here. > > I spent two days reading through the Calcify documentation > and archives, so I know this effort has been a struggle for > everyone involved. > > During my research I could see right away that EXRULE was > not the problem, it was DTSTART. DTSTART is ambiguous, not > EXRULE. > > Anyway, I'll accept the draft as-is. I would be > interested in participating in the discussion of a potential > "iCalendar V3." I'm not an expert on the RFC, > but I have experience coding calendar software - so I'm > not a novice either. > > -Adrian > > > --- On Thu, 11/20/08, Cyrus Daboo > wrote: > > > From: Cyrus Daboo > > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question > > To: adrian.crum@yahoo.com, > ietf-calsify@osafoundation.org > > Date: Thursday, November 20, 2008, 7:07 AM > > Hi Adrian, > > > > --On November 19, 2008 9:36:18 PM -0800 Adrian Crum > > wrote: > > > > > I disagree that it is hard to implement. The > original > > RFC was clear and > > > easy to implement: > > > > Actually it was not clear. Without restating all the > > discussion we had before on this, there are some clear > > ambiguities in the spec that meant interpretation of > EXRULE > > was up to the implementer. Just because you > implemented it > > in a way that works for your data does not mean it > will work > > the same way in some other product/library. > > > > As an example, the original spec states in the EXRULE > > definition: "The "DTSTART" defines the > first > > instance in the recurrence set.". The (correct) > reading > > of this is that an EXRULE will always exclude the > first > > instance in any recurrence set. This means, if you > really > > don't want the first instance cancelled, you have > to > > adjust the event in some way to create a fake > > "first" instance that is OK to cancel, and > then > > hope the rule does not match the second etc but in > doing > > that you may break the behavior of RRULEs also > present. > > > > That is just one example of ambiguity and lack of > clarity. > > Whilst it might have been possible to tighten up the > > definitions like this, the WG looked not only looked > at > > these ambiguities but also at how widely the feature > was > > supported and used (interoperably) and then came to > > consensus on removal. > > > > -- Cyrus Daboo _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Nov 20 08:10:36 2008 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 60A4A28C169 for ; Thu, 20 Nov 2008 08:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, J_CHICKENPOX_74=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 XICW74ZKlKug for ; Thu, 20 Nov 2008 08:10:35 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 2E6133A6943 for ; Thu, 20 Nov 2008 08:10:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 4DD8677D708; Thu, 20 Nov 2008 08:10:34 -0800 (PST) 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 aa34CtMGcmFb; Thu, 20 Nov 2008 08:10:31 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 7108D77D6FE; Thu, 20 Nov 2008 08:10:27 -0800 (PST) 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 6E93977D6FE for ; Thu, 20 Nov 2008 08:09:47 -0800 (PST) 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 Vw2kPTWr808Y for ; Thu, 20 Nov 2008 08:09:45 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 5030377D6FB for ; Thu, 20 Nov 2008 08:09:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="eml'208?scan'208,208";a="26283265" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2008 16:09:40 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKG9eRm025949 for ; Thu, 20 Nov 2008 17:09:40 +0100 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp4896.cisco.com [10.61.83.31]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKG9d8c029056 for ; Thu, 20 Nov 2008 16:09:39 GMT Message-ID: <49258BC3.4010604@cisco.com> Date: Thu, 20 Nov 2008 17:09:39 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081119 Shredder/3.0b1pre MIME-Version: 1.0 To: CALSIFY Mailinglist Content-Type: multipart/mixed; boundary="------------000303030605050206050200" Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [ietf-calsify] [Fwd: Re: Fw: Re: EXRULE Question] 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: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --------------000303030605050206050200 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit For some silly reason now I didn't CC the group. Duh... --------------000303030605050206050200 Content-Type: message/rfc822; name="Re: [ietf-calsify] Fw: Re: EXRULE Question.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re: [ietf-calsify] Fw: Re: EXRULE Question.eml" X-Mozilla-Keys: Message-ID: <49253A2D.3020802@cisco.com> Date: Thu, 20 Nov 2008 11:21:33 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081118 Shredder/3.0b1pre MIME-Version: 1.0 To: adrian.crum@yahoo.com Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question References: <612821.51679.qm@web63102.mail.re1.yahoo.com> In-Reply-To: <612821.51679.qm@web63102.mail.re1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit WG Chair hat on. We are well past working group last call (it occurred prior to summer). Aside from editorial nits there should be no further changes to this document, as we are now suffering from "great is the enemy of good". Bernard, all other changes at this point should be handled after IETF-wide last call. Adrian, I encourage you to accept the document as it is, given that you've had quite a while to provide feedback prior to last call. Eliot On 11/20/08 6:36 AM, Adrian Crum wrote: > Ben, > > Thanks for the reply. > > I disagree that it is hard to implement. The original RFC was clear and easy to implement: > > 1. Create a union of all RDATEs and RRULEs > 2. Create a union of all EXDATEs and EXRULEs > 3. Create a difference of the two unions > > I know this is easy to implement because I've done it. My example works with the original RFC. I challenge anyone to prove that it doesn't work with the original RFC. > > Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS the original. > > That is the point I am trying to make. Calcify isn't just simplifying or clarifying the spec, it is breaking it. > > -Adrian > > > > --- On Wed, 11/19/08, Ben Fortuna wrote: > > >> From: Ben Fortuna >> Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question >> To: adrian.crum@yahoo.com >> Cc: ietf-calsify@osafoundation.org >> Date: Wednesday, November 19, 2008, 9:24 PM >> Adrian, >> >> I think you'll find it was removed as it is hard to >> implement, meaning that >> many CUAs either didn't support it or had a broken >> implementation. >> >> It should be possible to write some code that converts a >> recurrence rule to >> a list of dates in a specified period (see iCal4j), so >> from there it >> shouldn't be hard to convert an EXRULE to a list of >> EXDATES, and if you >> choose a large enough period of time it should achieve the >> same effect >> (albeit a bit more verbose). >> >> Once the new RFC is approved I might investigate supporting >> automatic >> conversion of deprecated properties, so things like this >> should ultimately >> be transparent. >> >> regards, >> ben >> >> >> On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum >> wrote: >> >> >>> Oops, I meant for this to go to the mailing list. >>> >>> >>> --- On Wed, 11/19/08, Adrian Crum >>> >> wrote: >> >>>> From: Adrian Crum >>>> Subject: Re: [ietf-calsify] EXRULE Question >>>> To: "Bernard Desruisseaux" >>>> >> >> >>>> Date: Wednesday, November 19, 2008, 8:26 PM >>>> Thank you for the reply! >>>> >>>> That is very disappointing. Now I'm forced to >>>> >> define a >> >>>> finite amount of discreet dates for exclusions >>>> >> instead of >> >>>> specifying a few rules. >>>> >>>> I was better off with the original specification. >>>> >>>> Other than "no one is using EXRULE" - >>>> >> what is the >> >>>> compelling reason to remove it from the RFC? Is >>>> >> everyone in >> >>>> calcify that sure that it will never be used? >>>> >>>> I thought the objective was to simplify and >>>> >> clarify the >> >>>> RFC, not cripple it. >>>> >>>> -Adrian >>>> >>>> >>>> --- On Wed, 11/19/08, Bernard Desruisseaux >>>> wrote: >>>> >>>> >>>>> From: Bernard Desruisseaux >>>>> >>>> >>>> >>>>> Subject: Re: [ietf-calsify] EXRULE Question >>>>> To: adrian.crum@yahoo.com >>>>> Cc: ietf-calsify@osafoundation.org >>>>> Date: Wednesday, November 19, 2008, 5:34 PM >>>>> Adrian Crum wrote: >>>>> >>>>>> While browsing the internet I ran >>>>>> >> across the >> >>>> notes >>>> >>>>> from 2006 >>>>> >>>>>> regarding deprecating or removing >>>>>> >> EXRULE and >> >>>> EXDATE >>>> >>>>> from RFC 2445. >>>>> >>>>>> The comments made at the time indicated >>>>>> >> that no >> >>>> one >>>> >>>>> was using it. >>>>> >>>>> Only EXRULE was deprecated. EXDATE can >>>>> >> still be used. >> >>>>>> I'm curious - without those >>>>>> >> properties, how >> >>>> would >>>> >>>>> one express a >>>>> >>>>>> Monday through Friday at 8:00 AM event, >>>>>> >> except on >> >>>> US >>>> >>>>> federal >>>>> >>>>>> holidays? >>>>>> >>>>> Now, you are forced to specify EXDATE one by >>>>> >> one. And >> >>>> of >>>> >>>>> course the number of EXDATE needs to be >>>>> >> finite... >> >>>>> Which is what you'll end up with if you >>>>> >> create >> >>>> your >>>> >>>>> event with pretty much any calendar client >>>>> >> in use >> >>>> today... >>>> >>>>> Cheers, >>>>> Bernard >>>>> >>>>> >>>>>> I created an example iCalendar based on >>>>>> >> the >> >>>> original >>>> >>>>> RFC:> >>>>> >>>>>> BEGIN:VCALENDAR >>>>>> PRODID:-//Apache Open For >>>>>> >> Business//Work Effort >> >>>>> Calendar//EN >>>>> >>>>>> VERSION:2.0 >>>>>> CALSCALE:GREGORIAN >>>>>> DESCRIPTION:Adrian's Calendar >>>>>> BEGIN:VEVENT >>>>>> DTSTAMP:20081112T180905Z >>>>>> CREATED:20081111T231419Z >>>>>> LAST-MODIFIED:20081111T232507Z >>>>>> X-ORG-OFBIZ-WORKEFFORT-ID:10020 >>>>>> SUMMARY:Work Schedule >>>>>> DESCRIPTION:Work Schedule >>>>>> ORGANIZER;CN=THE ADMINISTRATOR: >>>>>> DTSTART:20080101T000043 >>>>>> >>>>>> >> RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 >> >>>>>> EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO >>>>>> >>>>>> >> EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 >> >>>>>> EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO >>>>>> >>>>>> >> EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO >> >> EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 >> >>>>>> EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO >>>>>> >>>>>> >> EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO >> >> EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 >> >> EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH >> >> EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 >> >>>>>> END:VEVENT >>>>>> END:VCALENDAR >>>>>> >>>>>> I can't find any mention of an >>>>>> >> alternative to >> >>>>> using the EXRULE property, so where would >>>>> >> one go from >> >>>> here? >>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> >>>>>> ietf-calsify mailing list >>>>>> ietf-calsify@osafoundation.org >>>>>> >>>>>> >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> >>> >>> _______________________________________________ >>> ietf-calsify mailing list >>> ietf-calsify@osafoundation.org >>> >>> >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> >> >> -- >> Less Talk More Gossip >> http://elbento.com >> >> Dan Quayle - "This President is going to lead us out >> of this recovery." >> > > > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > --------------000303030605050206050200 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 --------------000303030605050206050200-- From ietf-calsify-bounces@osafoundation.org Thu Nov 20 09:03:22 2008 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 1C4D328C25E for ; Thu, 20 Nov 2008 09:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 W7jDI07IV9BR for ; Thu, 20 Nov 2008 09:03:20 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 401B428C25F for ; Thu, 20 Nov 2008 09:03:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 45B063E3EB9; Thu, 20 Nov 2008 09:03:19 -0800 (PST) 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 7dwa9wiVFl4w; Thu, 20 Nov 2008 09:03:19 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id D914677D6FB; Thu, 20 Nov 2008 09:03:13 -0800 (PST) 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 7C18C77D6FB for ; Thu, 20 Nov 2008 09:03:11 -0800 (PST) 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 SnHcQw3TyVbw for ; Thu, 20 Nov 2008 09:03:00 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 0A2D93E3E58 for ; Thu, 20 Nov 2008 09:02:59 -0800 (PST) Received: from curie.fam.tuwien.ac.at (curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.8/8.13.8/Debian-3) with ESMTP id mAKH2trK025178; Thu, 20 Nov 2008 18:02:57 +0100 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org, adrian.crum@yahoo.com Date: Thu, 20 Nov 2008 18:04:45 +0100 User-Agent: KMail/1.9.10 References: <357145.41096.qm@web63107.mail.re1.yahoo.com> In-Reply-To: <357145.41096.qm@web63107.mail.re1.yahoo.com> Content-Disposition: inline Message-Id: <200811201804.46517.reinhold@kainhofer.com> Subject: Re: [ietf-calsify] Fw: Re: Fw: Re: EXRULE Question 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 20. November 2008 schrieb Adrian Crum: > During my research I could see right away that EXRULE was > not the problem, it was DTSTART. DTSTART is ambiguous, not > EXRULE. Actually, it was not DTSTART, either, but rather a side-comment on the COUNT attribute for RRULE, which messed things up: " The COUNT rule part defines the number of occurrences at which to range-bound the recurrence. The "DTSTART" property value, if specified, counts as the first occurrence." The problem was that most people read that last sentence as "The DTSTART is always the first occurrence of a recurrence rule". While in my opinion it simply meant "If the DTSTART matches the rule, it counts as one occurrence for the purpose of calculating the end date using the COUNT value." The reason why such a clarifying (yeah, I agree it didn't meet its purpose!) sentence was needed was that the generation of the whole recurrence set was defined as DTSTART + all occurrences generated by RRULE +..., but already existing times are not added a second time. So, if the DTSTART matched the rule, it would not be added to the recurrence rule again, but it would count towards COUNT. If you interpret it like this, then suddenly all those problems with RRULE and EXRULE vanish and things just work. Anyway, the possible confusion about DTSTART being always generated (by the wrong interpretation of the quoted sentence) by an RRULE, even if it doesn't match the rule, is now solved in rfc2445bis by the requirement that the RRULE should always match the DTSTART. And I completely agree with the others that EXRULE was hardly ever used, and I don't know a single application that provides a GUI way to handle EXRULEs at all. Sure, you can't represent some events any more (but the same can be said about the new requirement of having at most one RRULE), but I don't see this as a real showstopper, as there have always been some events that cannot be represented (even with full RRULE/EXRULE power), like the US election day. So, I don't have any problem with EXRULE being deprecated. I see more problems with forbidding multiple RRULEs, but even that is no big deal to me. Cheers, Reinhold > > > > Anyway, I'll accept the draft as-is. I would be > > interested in participating in the discussion of a potential > > "iCalendar V3." I'm not an expert on the RFC, > > but I have experience coding calendar software - so I'm > > not a novice either. > > > > -Adrian > > > > > > --- On Thu, 11/20/08, Cyrus Daboo > > > > wrote: > > > From: Cyrus Daboo > > > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question > > > To: adrian.crum@yahoo.com, > > > > ietf-calsify@osafoundation.org > > > > > Date: Thursday, November 20, 2008, 7:07 AM > > > Hi Adrian, > > > > > > --On November 19, 2008 9:36:18 PM -0800 Adrian Crum > > > > > > wrote: > > > > I disagree that it is hard to implement. The > > > > original > > > > > RFC was clear and > > > > > > > easy to implement: > > > > > > Actually it was not clear. Without restating all the > > > discussion we had before on this, there are some clear > > > ambiguities in the spec that meant interpretation of > > > > EXRULE > > > > > was up to the implementer. Just because you > > > > implemented it > > > > > in a way that works for your data does not mean it > > > > will work > > > > > the same way in some other product/library. > > > > > > As an example, the original spec states in the EXRULE > > > definition: "The "DTSTART" defines the > > > > first > > > > > instance in the recurrence set.". The (correct) > > > > reading > > > > > of this is that an EXRULE will always exclude the > > > > first > > > > > instance in any recurrence set. This means, if you > > > > really > > > > > don't want the first instance cancelled, you have > > > > to > > > > > adjust the event in some way to create a fake > > > "first" instance that is OK to cancel, and > > > > then > > > > > hope the rule does not match the second etc but in > > > > doing > > > > > that you may break the behavior of RRULEs also > > > > present. > > > > > That is just one example of ambiguity and lack of > > > > clarity. > > > > > Whilst it might have been possible to tighten up the > > > definitions like this, the WG looked not only looked > > > > at > > > > > these ambiguities but also at how widely the feature > > > > was > > > > > supported and used (interoperably) and then came to > > > consensus on removal. > > > > > > -- Cyrus Daboo > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJJZiuTqjEwhXvPN0RApQmAKCNJuZWP+tQGovrMzv533KNIddPTwCfd+mr aouDgT59yRjwkeGWBVKBwWA= =QdiS -----END PGP SIGNATURE----- _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Nov 20 09:24:12 2008 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 8C57E3A67FA for ; Thu, 20 Nov 2008 09:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 lyN40+ruDfxh for ; Thu, 20 Nov 2008 09:24:11 -0800 (PST) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 2FFAF3A6A27 for ; Thu, 20 Nov 2008 09:24:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 5158479401D; Thu, 20 Nov 2008 09:24:10 -0800 (PST) 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 LzKqqiHTo6UM; Thu, 20 Nov 2008 09:24:00 -0800 (PST) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 3A241794024; Thu, 20 Nov 2008 09:23:59 -0800 (PST) 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 2D6EF794024 for ; Thu, 20 Nov 2008 09:23:57 -0800 (PST) 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 hW8aEbMQt4xH for ; Thu, 20 Nov 2008 09:23:45 -0800 (PST) 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 AAF6579401D for ; Thu, 20 Nov 2008 09:23:45 -0800 (PST) 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 mAKHOF6V007935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Nov 2008 17:24:16 GMT Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAKHNm9K020782; Thu, 20 Nov 2008 17:23:49 GMT Received: from [141.144.109.195] (/141.144.109.195) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Nov 2008 09:23:32 -0800 Message-ID: <49259D10.9060808@oracle.com> Date: Thu, 20 Nov 2008 12:23:28 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Reinhold Kainhofer References: <357145.41096.qm@web63107.mail.re1.yahoo.com> <200811201804.46517.reinhold@kainhofer.com> In-Reply-To: <200811201804.46517.reinhold@kainhofer.com> X-Source-IP: acsmt704.oracle.com [141.146.40.82] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010208.49259D16.004C:SCFSTAT928724,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] Fw: Re: Fw: Re: EXRULE Question 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 Reinhold Kainhofer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am Donnerstag, 20. November 2008 schrieb Adrian Crum: >> During my research I could see right away that EXRULE was >> not the problem, it was DTSTART. DTSTART is ambiguous, not >> EXRULE. > > Actually, it was not DTSTART, either, but rather a side-comment on the COUNT > attribute for RRULE, which messed things up: > > " The COUNT rule part defines the number of occurrences at which to > range-bound the recurrence. The "DTSTART" property value, if > specified, counts as the first occurrence." > > The problem was that most people read that last sentence as "The DTSTART is > always the first occurrence of a recurrence rule". While in my opinion it > simply meant "If the DTSTART matches the rule, it counts as one occurrence > for the purpose of calculating the end date using the COUNT value." > The reason why such a clarifying (yeah, I agree it didn't meet its purpose!) > sentence was needed was that the generation of the whole recurrence set was > defined as DTSTART + all occurrences generated by RRULE +..., but already > existing times are not added a second time. So, if the DTSTART matched the > rule, it would not be added to the recurrence rule again, but it would count > towards COUNT. > If you interpret it like this, then suddenly all those problems with RRULE and > EXRULE vanish and things just work. > > Anyway, the possible confusion about DTSTART being always generated (by the > wrong interpretation of the quoted sentence) by an RRULE, even if it doesn't > match the rule, is now solved in rfc2445bis by the requirement that the RRULE > should always match the DTSTART. > > And I completely agree with the others that EXRULE was hardly ever used, and I > don't know a single application that provides a GUI way to handle EXRULEs at > all. > Sure, you can't represent some events any more (but the same can be said about > the new requirement of having at most one RRULE), but I don't see this as a > real showstopper, as there have always been some events that cannot be > represented (even with full RRULE/EXRULE power), like the US election day. Actually, you've picked a bad example here! See: http://tools.ietf.org/html/rfc2445#page-124 Easter, for instance, would have been a good example. Cheers, Bernard > > So, I don't have any problem with EXRULE being deprecated. I see more problems > with forbidding multiple RRULEs, but even that is no big deal to me. > > Cheers, > Reinhold > > >>> Anyway, I'll accept the draft as-is. I would be >>> interested in participating in the discussion of a potential >>> "iCalendar V3." I'm not an expert on the RFC, >>> but I have experience coding calendar software - so I'm >>> not a novice either. >>> >>> -Adrian >>> >>> >>> --- On Thu, 11/20/08, Cyrus Daboo >>> >>> wrote: >>>> From: Cyrus Daboo >>>> Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question >>>> To: adrian.crum@yahoo.com, >>> ietf-calsify@osafoundation.org >>> >>>> Date: Thursday, November 20, 2008, 7:07 AM >>>> Hi Adrian, >>>> >>>> --On November 19, 2008 9:36:18 PM -0800 Adrian Crum >>>> >>>> wrote: >>>>> I disagree that it is hard to implement. The >>> original >>> >>>> RFC was clear and >>>> >>>>> easy to implement: >>>> Actually it was not clear. Without restating all the >>>> discussion we had before on this, there are some clear >>>> ambiguities in the spec that meant interpretation of >>> EXRULE >>> >>>> was up to the implementer. Just because you >>> implemented it >>> >>>> in a way that works for your data does not mean it >>> will work >>> >>>> the same way in some other product/library. >>>> >>>> As an example, the original spec states in the EXRULE >>>> definition: "The "DTSTART" defines the >>> first >>> >>>> instance in the recurrence set.". The (correct) >>> reading >>> >>>> of this is that an EXRULE will always exclude the >>> first >>> >>>> instance in any recurrence set. This means, if you >>> really >>> >>>> don't want the first instance cancelled, you have >>> to >>> >>>> adjust the event in some way to create a fake >>>> "first" instance that is OK to cancel, and >>> then >>> >>>> hope the rule does not match the second etc but in >>> doing >>> >>>> that you may break the behavior of RRULEs also >>> present. >>> >>>> That is just one example of ambiguity and lack of >>> clarity. >>> >>>> Whilst it might have been possible to tighten up the >>>> definitions like this, the WG looked not only looked >>> at >>> >>>> these ambiguities but also at how widely the feature >>> was >>> >>>> supported and used (interoperably) and then came to >>>> consensus on removal. >>>> >>>> -- Cyrus Daboo >> _______________________________________________ >> ietf-calsify mailing list >> ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > - -- > - ------------------------------------------------------------------ > Reinhold Kainhofer, Vienna University of Technology, Austria > email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ > * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ > * K Desktop Environment, http://www.kde.org, KOrganizer maintainer > * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFJJZiuTqjEwhXvPN0RApQmAKCNJuZWP+tQGovrMzv533KNIddPTwCfd+mr > aouDgT59yRjwkeGWBVKBwWA= > =QdiS > -----END PGP SIGNATURE----- > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ 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 2D6EF794024 for ; Thu, 20 Nov 2008 09:23:57 -0800 (PST) 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.000, BAYES_00=-2.599] 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 hW8aEbMQt4xH for ; Thu, 20 Nov 2008 09:23:45 -0800 (PST) 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 AAF6579401D for ; Thu, 20 Nov 2008 09:23:45 -0800 (PST) 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 mAKHOF6V007935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Nov 2008 17:24:16 GMT Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAKHNm9K020782; Thu, 20 Nov 2008 17:23:49 GMT Received: from [141.144.109.195] (/141.144.109.195) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Nov 2008 09:23:32 -0800 Message-ID: <49259D10.9060808@oracle.com> Date: Thu, 20 Nov 2008 12:23:28 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Reinhold Kainhofer References: <357145.41096.qm@web63107.mail.re1.yahoo.com> <200811201804.46517.reinhold@kainhofer.com> In-Reply-To: <200811201804.46517.reinhold@kainhofer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt704.oracle.com [141.146.40.82] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010208.49259D16.004C:SCFSTAT928724,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] Fw: Re: Fw: Re: EXRULE Question 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: Thu, 20 Nov 2008 17:23:57 -0000 Reinhold Kainhofer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am Donnerstag, 20. November 2008 schrieb Adrian Crum: >> During my research I could see right away that EXRULE was >> not the problem, it was DTSTART. DTSTART is ambiguous, not >> EXRULE. > > Actually, it was not DTSTART, either, but rather a side-comment on the COUNT > attribute for RRULE, which messed things up: > > " The COUNT rule part defines the number of occurrences at which to > range-bound the recurrence. The "DTSTART" property value, if > specified, counts as the first occurrence." > > The problem was that most people read that last sentence as "The DTSTART is > always the first occurrence of a recurrence rule". While in my opinion it > simply meant "If the DTSTART matches the rule, it counts as one occurrence > for the purpose of calculating the end date using the COUNT value." > The reason why such a clarifying (yeah, I agree it didn't meet its purpose!) > sentence was needed was that the generation of the whole recurrence set was > defined as DTSTART + all occurrences generated by RRULE +..., but already > existing times are not added a second time. So, if the DTSTART matched the > rule, it would not be added to the recurrence rule again, but it would count > towards COUNT. > If you interpret it like this, then suddenly all those problems with RRULE and > EXRULE vanish and things just work. > > Anyway, the possible confusion about DTSTART being always generated (by the > wrong interpretation of the quoted sentence) by an RRULE, even if it doesn't > match the rule, is now solved in rfc2445bis by the requirement that the RRULE > should always match the DTSTART. > > And I completely agree with the others that EXRULE was hardly ever used, and I > don't know a single application that provides a GUI way to handle EXRULEs at > all. > Sure, you can't represent some events any more (but the same can be said about > the new requirement of having at most one RRULE), but I don't see this as a > real showstopper, as there have always been some events that cannot be > represented (even with full RRULE/EXRULE power), like the US election day. Actually, you've picked a bad example here! See: http://tools.ietf.org/html/rfc2445#page-124 Easter, for instance, would have been a good example. Cheers, Bernard > > So, I don't have any problem with EXRULE being deprecated. I see more problems > with forbidding multiple RRULEs, but even that is no big deal to me. > > Cheers, > Reinhold > > >>> Anyway, I'll accept the draft as-is. I would be >>> interested in participating in the discussion of a potential >>> "iCalendar V3." I'm not an expert on the RFC, >>> but I have experience coding calendar software - so I'm >>> not a novice either. >>> >>> -Adrian >>> >>> >>> --- On Thu, 11/20/08, Cyrus Daboo >>> >>> wrote: >>>> From: Cyrus Daboo >>>> Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question >>>> To: adrian.crum@yahoo.com, >>> ietf-calsify@osafoundation.org >>> >>>> Date: Thursday, November 20, 2008, 7:07 AM >>>> Hi Adrian, >>>> >>>> --On November 19, 2008 9:36:18 PM -0800 Adrian Crum >>>> >>>> wrote: >>>>> I disagree that it is hard to implement. The >>> original >>> >>>> RFC was clear and >>>> >>>>> easy to implement: >>>> Actually it was not clear. Without restating all the >>>> discussion we had before on this, there are some clear >>>> ambiguities in the spec that meant interpretation of >>> EXRULE >>> >>>> was up to the implementer. Just because you >>> implemented it >>> >>>> in a way that works for your data does not mean it >>> will work >>> >>>> the same way in some other product/library. >>>> >>>> As an example, the original spec states in the EXRULE >>>> definition: "The "DTSTART" defines the >>> first >>> >>>> instance in the recurrence set.". The (correct) >>> reading >>> >>>> of this is that an EXRULE will always exclude the >>> first >>> >>>> instance in any recurrence set. This means, if you >>> really >>> >>>> don't want the first instance cancelled, you have >>> to >>> >>>> adjust the event in some way to create a fake >>>> "first" instance that is OK to cancel, and >>> then >>> >>>> hope the rule does not match the second etc but in >>> doing >>> >>>> that you may break the behavior of RRULEs also >>> present. >>> >>>> That is just one example of ambiguity and lack of >>> clarity. >>> >>>> Whilst it might have been possible to tighten up the >>>> definitions like this, the WG looked not only looked >>> at >>> >>>> these ambiguities but also at how widely the feature >>> was >>> >>>> supported and used (interoperably) and then came to >>>> consensus on removal. >>>> >>>> -- Cyrus Daboo >> _______________________________________________ >> ietf-calsify mailing list >> ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > - -- > - ------------------------------------------------------------------ > Reinhold Kainhofer, Vienna University of Technology, Austria > email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ > * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ > * K Desktop Environment, http://www.kde.org, KOrganizer maintainer > * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFJJZiuTqjEwhXvPN0RApQmAKCNJuZWP+tQGovrMzv533KNIddPTwCfd+mr > aouDgT59yRjwkeGWBVKBwWA= > =QdiS > -----END PGP SIGNATURE----- > _______________________________________________ > 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 7C18C77D6FB for ; Thu, 20 Nov 2008 09:03:11 -0800 (PST) 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.000, BAYES_00=-2.599] 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 SnHcQw3TyVbw for ; Thu, 20 Nov 2008 09:03:00 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 0A2D93E3E58 for ; Thu, 20 Nov 2008 09:02:59 -0800 (PST) Received: from curie.fam.tuwien.ac.at (curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.8/8.13.8/Debian-3) with ESMTP id mAKH2trK025178; Thu, 20 Nov 2008 18:02:57 +0100 From: Reinhold Kainhofer Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org, adrian.crum@yahoo.com Date: Thu, 20 Nov 2008 18:04:45 +0100 User-Agent: KMail/1.9.10 References: <357145.41096.qm@web63107.mail.re1.yahoo.com> In-Reply-To: <357145.41096.qm@web63107.mail.re1.yahoo.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811201804.46517.reinhold@kainhofer.com> Subject: Re: [ietf-calsify] Fw: Re: Fw: Re: EXRULE Question 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: Thu, 20 Nov 2008 17:03:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 20. November 2008 schrieb Adrian Crum: > During my research I could see right away that EXRULE was > not the problem, it was DTSTART. DTSTART is ambiguous, not > EXRULE. Actually, it was not DTSTART, either, but rather a side-comment on the COUNT attribute for RRULE, which messed things up: " The COUNT rule part defines the number of occurrences at which to range-bound the recurrence. The "DTSTART" property value, if specified, counts as the first occurrence." The problem was that most people read that last sentence as "The DTSTART is always the first occurrence of a recurrence rule". While in my opinion it simply meant "If the DTSTART matches the rule, it counts as one occurrence for the purpose of calculating the end date using the COUNT value." The reason why such a clarifying (yeah, I agree it didn't meet its purpose!) sentence was needed was that the generation of the whole recurrence set was defined as DTSTART + all occurrences generated by RRULE +..., but already existing times are not added a second time. So, if the DTSTART matched the rule, it would not be added to the recurrence rule again, but it would count towards COUNT. If you interpret it like this, then suddenly all those problems with RRULE and EXRULE vanish and things just work. Anyway, the possible confusion about DTSTART being always generated (by the wrong interpretation of the quoted sentence) by an RRULE, even if it doesn't match the rule, is now solved in rfc2445bis by the requirement that the RRULE should always match the DTSTART. And I completely agree with the others that EXRULE was hardly ever used, and I don't know a single application that provides a GUI way to handle EXRULEs at all. Sure, you can't represent some events any more (but the same can be said about the new requirement of having at most one RRULE), but I don't see this as a real showstopper, as there have always been some events that cannot be represented (even with full RRULE/EXRULE power), like the US election day. So, I don't have any problem with EXRULE being deprecated. I see more problems with forbidding multiple RRULEs, but even that is no big deal to me. Cheers, Reinhold > > > > Anyway, I'll accept the draft as-is. I would be > > interested in participating in the discussion of a potential > > "iCalendar V3." I'm not an expert on the RFC, > > but I have experience coding calendar software - so I'm > > not a novice either. > > > > -Adrian > > > > > > --- On Thu, 11/20/08, Cyrus Daboo > > > > wrote: > > > From: Cyrus Daboo > > > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question > > > To: adrian.crum@yahoo.com, > > > > ietf-calsify@osafoundation.org > > > > > Date: Thursday, November 20, 2008, 7:07 AM > > > Hi Adrian, > > > > > > --On November 19, 2008 9:36:18 PM -0800 Adrian Crum > > > > > > wrote: > > > > I disagree that it is hard to implement. The > > > > original > > > > > RFC was clear and > > > > > > > easy to implement: > > > > > > Actually it was not clear. Without restating all the > > > discussion we had before on this, there are some clear > > > ambiguities in the spec that meant interpretation of > > > > EXRULE > > > > > was up to the implementer. Just because you > > > > implemented it > > > > > in a way that works for your data does not mean it > > > > will work > > > > > the same way in some other product/library. > > > > > > As an example, the original spec states in the EXRULE > > > definition: "The "DTSTART" defines the > > > > first > > > > > instance in the recurrence set.". The (correct) > > > > reading > > > > > of this is that an EXRULE will always exclude the > > > > first > > > > > instance in any recurrence set. This means, if you > > > > really > > > > > don't want the first instance cancelled, you have > > > > to > > > > > adjust the event in some way to create a fake > > > "first" instance that is OK to cancel, and > > > > then > > > > > hope the rule does not match the second etc but in > > > > doing > > > > > that you may break the behavior of RRULEs also > > > > present. > > > > > That is just one example of ambiguity and lack of > > > > clarity. > > > > > Whilst it might have been possible to tighten up the > > > definitions like this, the WG looked not only looked > > > > at > > > > > these ambiguities but also at how widely the feature > > > > was > > > > > supported and used (interoperably) and then came to > > > consensus on removal. > > > > > > -- Cyrus Daboo > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJJZiuTqjEwhXvPN0RApQmAKCNJuZWP+tQGovrMzv533KNIddPTwCfd+mr aouDgT59yRjwkeGWBVKBwWA= =QdiS -----END PGP SIGNATURE----- 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 6E93977D6FE for ; Thu, 20 Nov 2008 08:09:47 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-50 required=4 tests=[AWL=-0.800, BAYES_00=-2.599] 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 Vw2kPTWr808Y for ; Thu, 20 Nov 2008 08:09:45 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 5030377D6FB for ; Thu, 20 Nov 2008 08:09:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="eml'208?scan'208,208";a="26283265" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2008 16:09:40 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKG9eRm025949 for ; Thu, 20 Nov 2008 17:09:40 +0100 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp4896.cisco.com [10.61.83.31]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKG9d8c029056 for ; Thu, 20 Nov 2008 16:09:39 GMT Message-ID: <49258BC3.4010604@cisco.com> Date: Thu, 20 Nov 2008 17:09:39 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081119 Shredder/3.0b1pre MIME-Version: 1.0 To: CALSIFY Mailinglist Content-Type: multipart/mixed; boundary="------------000303030605050206050200" Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [ietf-calsify] [Fwd: Re: Fw: Re: EXRULE Question] 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: Thu, 20 Nov 2008 16:09:47 -0000 This is a multi-part message in MIME format. --------------000303030605050206050200 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit For some silly reason now I didn't CC the group. Duh... --------------000303030605050206050200 Content-Type: message/rfc822; name="Re: [ietf-calsify] Fw: Re: EXRULE Question.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re: [ietf-calsify] Fw: Re: EXRULE Question.eml" X-Mozilla-Keys: Message-ID: <49253A2D.3020802@cisco.com> Date: Thu, 20 Nov 2008 11:21:33 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081118 Shredder/3.0b1pre MIME-Version: 1.0 To: adrian.crum@yahoo.com Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question References: <612821.51679.qm@web63102.mail.re1.yahoo.com> In-Reply-To: <612821.51679.qm@web63102.mail.re1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit WG Chair hat on. We are well past working group last call (it occurred prior to summer). Aside from editorial nits there should be no further changes to this document, as we are now suffering from "great is the enemy of good". Bernard, all other changes at this point should be handled after IETF-wide last call. Adrian, I encourage you to accept the document as it is, given that you've had quite a while to provide feedback prior to last call. Eliot On 11/20/08 6:36 AM, Adrian Crum wrote: > Ben, > > Thanks for the reply. > > I disagree that it is hard to implement. The original RFC was clear and easy to implement: > > 1. Create a union of all RDATEs and RRULEs > 2. Create a union of all EXDATEs and EXRULEs > 3. Create a difference of the two unions > > I know this is easy to implement because I've done it. My example works with the original RFC. I challenge anyone to prove that it doesn't work with the original RFC. > > Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS the original. > > That is the point I am trying to make. Calcify isn't just simplifying or clarifying the spec, it is breaking it. > > -Adrian > > > > --- On Wed, 11/19/08, Ben Fortuna wrote: > > >> From: Ben Fortuna >> Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question >> To: adrian.crum@yahoo.com >> Cc: ietf-calsify@osafoundation.org >> Date: Wednesday, November 19, 2008, 9:24 PM >> Adrian, >> >> I think you'll find it was removed as it is hard to >> implement, meaning that >> many CUAs either didn't support it or had a broken >> implementation. >> >> It should be possible to write some code that converts a >> recurrence rule to >> a list of dates in a specified period (see iCal4j), so >> from there it >> shouldn't be hard to convert an EXRULE to a list of >> EXDATES, and if you >> choose a large enough period of time it should achieve the >> same effect >> (albeit a bit more verbose). >> >> Once the new RFC is approved I might investigate supporting >> automatic >> conversion of deprecated properties, so things like this >> should ultimately >> be transparent. >> >> regards, >> ben >> >> >> On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum >> wrote: >> >> >>> Oops, I meant for this to go to the mailing list. >>> >>> >>> --- On Wed, 11/19/08, Adrian Crum >>> >> wrote: >> >>>> From: Adrian Crum >>>> Subject: Re: [ietf-calsify] EXRULE Question >>>> To: "Bernard Desruisseaux" >>>> >> >> >>>> Date: Wednesday, November 19, 2008, 8:26 PM >>>> Thank you for the reply! >>>> >>>> That is very disappointing. Now I'm forced to >>>> >> define a >> >>>> finite amount of discreet dates for exclusions >>>> >> instead of >> >>>> specifying a few rules. >>>> >>>> I was better off with the original specification. >>>> >>>> Other than "no one is using EXRULE" - >>>> >> what is the >> >>>> compelling reason to remove it from the RFC? Is >>>> >> everyone in >> >>>> calcify that sure that it will never be used? >>>> >>>> I thought the objective was to simplify and >>>> >> clarify the >> >>>> RFC, not cripple it. >>>> >>>> -Adrian >>>> >>>> >>>> --- On Wed, 11/19/08, Bernard Desruisseaux >>>> wrote: >>>> >>>> >>>>> From: Bernard Desruisseaux >>>>> >>>> >>>> >>>>> Subject: Re: [ietf-calsify] EXRULE Question >>>>> To: adrian.crum@yahoo.com >>>>> Cc: ietf-calsify@osafoundation.org >>>>> Date: Wednesday, November 19, 2008, 5:34 PM >>>>> Adrian Crum wrote: >>>>> >>>>>> While browsing the internet I ran >>>>>> >> across the >> >>>> notes >>>> >>>>> from 2006 >>>>> >>>>>> regarding deprecating or removing >>>>>> >> EXRULE and >> >>>> EXDATE >>>> >>>>> from RFC 2445. >>>>> >>>>>> The comments made at the time indicated >>>>>> >> that no >> >>>> one >>>> >>>>> was using it. >>>>> >>>>> Only EXRULE was deprecated. EXDATE can >>>>> >> still be used. >> >>>>>> I'm curious - without those >>>>>> >> properties, how >> >>>> would >>>> >>>>> one express a >>>>> >>>>>> Monday through Friday at 8:00 AM event, >>>>>> >> except on >> >>>> US >>>> >>>>> federal >>>>> >>>>>> holidays? >>>>>> >>>>> Now, you are forced to specify EXDATE one by >>>>> >> one. And >> >>>> of >>>> >>>>> course the number of EXDATE needs to be >>>>> >> finite... >> >>>>> Which is what you'll end up with if you >>>>> >> create >> >>>> your >>>> >>>>> event with pretty much any calendar client >>>>> >> in use >> >>>> today... >>>> >>>>> Cheers, >>>>> Bernard >>>>> >>>>> >>>>>> I created an example iCalendar based on >>>>>> >> the >> >>>> original >>>> >>>>> RFC:> >>>>> >>>>>> BEGIN:VCALENDAR >>>>>> PRODID:-//Apache Open For >>>>>> >> Business//Work Effort >> >>>>> Calendar//EN >>>>> >>>>>> VERSION:2.0 >>>>>> CALSCALE:GREGORIAN >>>>>> DESCRIPTION:Adrian's Calendar >>>>>> BEGIN:VEVENT >>>>>> DTSTAMP:20081112T180905Z >>>>>> CREATED:20081111T231419Z >>>>>> LAST-MODIFIED:20081111T232507Z >>>>>> X-ORG-OFBIZ-WORKEFFORT-ID:10020 >>>>>> SUMMARY:Work Schedule >>>>>> DESCRIPTION:Work Schedule >>>>>> ORGANIZER;CN=THE ADMINISTRATOR: >>>>>> DTSTART:20080101T000043 >>>>>> >>>>>> >> RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 >> >>>>>> EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO >>>>>> >>>>>> >> EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 >> >>>>>> EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO >>>>>> >>>>>> >> EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO >> >> EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 >> >>>>>> EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO >>>>>> >>>>>> >> EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO >> >> EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 >> >> EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH >> >> EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 >> >>>>>> END:VEVENT >>>>>> END:VCALENDAR >>>>>> >>>>>> I can't find any mention of an >>>>>> >> alternative to >> >>>>> using the EXRULE property, so where would >>>>> >> one go from >> >>>> here? >>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> >>>>>> ietf-calsify mailing list >>>>>> ietf-calsify@osafoundation.org >>>>>> >>>>>> >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> >>> >>> _______________________________________________ >>> ietf-calsify mailing list >>> ietf-calsify@osafoundation.org >>> >>> >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> >> >> -- >> Less Talk More Gossip >> http://elbento.com >> >> Dan Quayle - "This President is going to lead us out >> of this recovery." >> > > > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > --------------000303030605050206050200-- 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 44BD477D6FE for ; Thu, 20 Nov 2008 07:58:46 -0800 (PST) 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.000, BAYES_00=-2.599] 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 ME1MY7GhVPCw for ; Thu, 20 Nov 2008 07:58:35 -0800 (PST) Received: from web63107.mail.re1.yahoo.com (web63107.mail.re1.yahoo.com [69.147.97.2]) by leka.osafoundation.org (Postfix) with SMTP id 40D6B77D6FB for ; Thu, 20 Nov 2008 07:58:35 -0800 (PST) Received: (qmail 41729 invoked by uid 60001); 20 Nov 2008 15:58:34 -0000 X-YMail-OSG: 75LjEyAVM1nRSVVIc.n_rFDwKSnEgxFX5LzDG4fr25BPplvx7ncjTViomX3E0M5xzLONvAkzaicoGUkW9a7RmfFvrKCiVnI4QbzREuBb.mLWTB_bxk4b9JTh6UT4V72sz.COMR6hqSl.eECwPnqShxSqxVQ- Received: from [71.119.123.156] by web63107.mail.re1.yahoo.com via HTTP; Thu, 20 Nov 2008 07:58:34 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Thu, 20 Nov 2008 07:58:34 -0800 (PST) From: Adrian Crum To: ietf-calsify@osafoundation.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <357145.41096.qm@web63107.mail.re1.yahoo.com> Subject: [ietf-calsify] Fw: Re: Fw: Re: EXRULE Question X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian.crum@yahoo.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 15:58:46 -0000 Oops, I did it again. --- On Thu, 11/20/08, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question > To: "Cyrus Daboo" > Date: Thursday, November 20, 2008, 7:58 AM > Many thanks to everyone who replied! > > I'm late bringing this subject up because I didn't > discover it until recently. I was working on integrating > iCalendar with an open source ERP program and when certain > CUAs didn't accept the program's output I ended up > here. > > I spent two days reading through the Calcify documentation > and archives, so I know this effort has been a struggle for > everyone involved. > > During my research I could see right away that EXRULE was > not the problem, it was DTSTART. DTSTART is ambiguous, not > EXRULE. > > Anyway, I'll accept the draft as-is. I would be > interested in participating in the discussion of a potential > "iCalendar V3." I'm not an expert on the RFC, > but I have experience coding calendar software - so I'm > not a novice either. > > -Adrian > > > --- On Thu, 11/20/08, Cyrus Daboo > wrote: > > > From: Cyrus Daboo > > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question > > To: adrian.crum@yahoo.com, > ietf-calsify@osafoundation.org > > Date: Thursday, November 20, 2008, 7:07 AM > > Hi Adrian, > > > > --On November 19, 2008 9:36:18 PM -0800 Adrian Crum > > wrote: > > > > > I disagree that it is hard to implement. The > original > > RFC was clear and > > > easy to implement: > > > > Actually it was not clear. Without restating all the > > discussion we had before on this, there are some clear > > ambiguities in the spec that meant interpretation of > EXRULE > > was up to the implementer. Just because you > implemented it > > in a way that works for your data does not mean it > will work > > the same way in some other product/library. > > > > As an example, the original spec states in the EXRULE > > definition: "The "DTSTART" defines the > first > > instance in the recurrence set.". The (correct) > reading > > of this is that an EXRULE will always exclude the > first > > instance in any recurrence set. This means, if you > really > > don't want the first instance cancelled, you have > to > > adjust the event in some way to create a fake > > "first" instance that is OK to cancel, and > then > > hope the rule does not match the second etc but in > doing > > that you may break the behavior of RRULEs also > present. > > > > That is just one example of ambiguity and lack of > clarity. > > Whilst it might have been possible to tighten up the > > definitions like this, the WG looked not only looked > at > > these ambiguities but also at how widely the feature > was > > supported and used (interoperably) and then came to > > consensus on removal. > > > > -- Cyrus Daboo 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 660B477D6FE for ; Thu, 20 Nov 2008 07:07:23 -0800 (PST) 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=[BAYES_00=-2.599] 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 JAAM27-m0ecW for ; Thu, 20 Nov 2008 07:07:13 -0800 (PST) Received: from daboo.name (daboo.name [151.201.22.177]) by leka.osafoundation.org (Postfix) with ESMTP id B890577D6FB for ; Thu, 20 Nov 2008 07:07:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 7BC55F2865F; Thu, 20 Nov 2008 10:07:05 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yk39jCidt1e; Thu, 20 Nov 2008 10:07:05 -0500 (EST) Received: from [130.129.29.197] (unknown [130.129.29.197]) by daboo.name (Postfix) with ESMTP id 87A24F28658; Thu, 20 Nov 2008 10:07:04 -0500 (EST) Date: Thu, 20 Nov 2008 09:07:04 -0600 From: Cyrus Daboo To: adrian.crum@yahoo.com, ietf-calsify@osafoundation.org Message-ID: In-Reply-To: <612821.51679.qm@web63102.mail.re1.yahoo.com> References: <612821.51679.qm@web63102.mail.re1.yahoo.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question 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: Thu, 20 Nov 2008 15:07:23 -0000 Hi Adrian, --On November 19, 2008 9:36:18 PM -0800 Adrian Crum wrote: > I disagree that it is hard to implement. The original RFC was clear and > easy to implement: Actually it was not clear. Without restating all the discussion we had before on this, there are some clear ambiguities in the spec that meant interpretation of EXRULE was up to the implementer. Just because you implemented it in a way that works for your data does not mean it will work the same way in some other product/library. As an example, the original spec states in the EXRULE definition: "The "DTSTART" defines the first instance in the recurrence set.". The (correct) reading of this is that an EXRULE will always exclude the first instance in any recurrence set. This means, if you really don't want the first instance cancelled, you have to adjust the event in some way to create a fake "first" instance that is OK to cancel, and then hope the rule does not match the second etc but in doing that you may break the behavior of RRULEs also present. That is just one example of ambiguity and lack of clarity. Whilst it might have been possible to tighten up the definitions like this, the WG looked not only looked at these ambiguities but also at how widely the feature was supported and used (interoperably) and then came to consensus on removal. -- Cyrus Daboo 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 A15AF77D6FE for ; Thu, 20 Nov 2008 05:04:45 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.518 X-Spam-Level: X-Spam-Status: No, score=0.518 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, FORGED_MUA_OUTLOOK=3.116, STOX_REPLY_TYPE=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 OgtbjrYrXdTT for ; Thu, 20 Nov 2008 05:04:36 -0800 (PST) Received: from mail.rockliffe.com (mail.rockliffe.com [216.34.131.10]) by leka.osafoundation.org (Postfix) with ESMTP id 502DF77D6FB for ; Thu, 20 Nov 2008 05:04:36 -0800 (PST) X-Spam-Score-scoring_explanation: X-Spam-Score-spf_status: X-Spam-Score-Spamcatcher1: 628208689bc42837d65b316acd4bd2d1 X-Spam-Score-Summary: 2, 0, 0, 47f6250fe99c435d, a0ea87fb493ec7f7, nigel.swinson@mailsite.com, adrian.crum@yahoo.com:ietf-calsify@osafoundation.org, RULES_HIT:355:379:539:540:541:542:543:567:599:601:973:988:989:1155:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2076:2393:2559:2562:2693:2828:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3874:3876:3877:4250:5007:6114:7875:8501, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none X-Spam-Score-rbl_summary: none X-Spam-Score-Phishing_status: no X-Spam-Score-Countries: X-Spam-Score-Charsets: iso-8859-1 Received: from NIGEL08 (unverified [192.168.1.103]) by mail.rockliffe.com (Rockliffe SMTPRA 9.0.1) with ESMTP id ; Thu, 20 Nov 2008 05:04:33 -0800 Message-ID: <4740FB101D26453C8E01391DCC93229F@NIGEL08> From: "Nigel Swinson" To: References: <612821.51679.qm@web63102.mail.re1.yahoo.com> Date: Thu, 20 Nov 2008 13:04:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question 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: Thu, 20 Nov 2008 13:04:45 -0000 > Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS > the original. > > That is the point I am trying to make. Calcify isn't just simplifying or > clarifying the spec, it is breaking it. Dropping EXRULE doesn't mean it can never exist, it just means it doesn't exist in the base spec. This makes the spec overall simpler to implement, which will increase the number of implementations, and maximize interoperability. I class the two most complex areas of iCalendar to be timezone processing and recurrence, and think dropping EXRULE from the "base" spec was an excellent idea as it simplifies one of those complex areas, while still providing in the "base" spec a way to achieve the same functionality - using EXDATE. Perhaps there's a need for an extension to iCalendar that defines all the stuff that got taken out, so implementations like yours can cite support for the extended specification, and new impelementations can start with the base spec, and then later on consider implementing the extended specifications? Nigel 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 B1EFF77D700 for ; Thu, 20 Nov 2008 03:12:26 -0800 (PST) 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] 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 nkXBzZR3p09R for ; Thu, 20 Nov 2008 03:12:14 -0800 (PST) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id CE3FB77D6FF for ; Thu, 20 Nov 2008 03:12:13 -0800 (PST) Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.8/8.13.8/Debian-3) with ESMTP id mAKBCAtj015817; Thu, 20 Nov 2008 12:12:10 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org, adrian.crum@yahoo.com Date: Thu, 20 Nov 2008 12:12:05 +0100 User-Agent: KMail/1.9.10 References: <612821.51679.qm@web63102.mail.re1.yahoo.com> In-Reply-To: <612821.51679.qm@web63102.mail.re1.yahoo.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811201212.09374.reinhold@kainhofer.com> Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question 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: Thu, 20 Nov 2008 11:12:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Donnerstag, 20. November 2008 schrieb Adrian Crum: > I disagree that it is hard to implement. So do I. While KOrganizer has no GUI for creating EXRULE, our libkcal library supports an arbitrary number of RRULEs and EXRULEs. KOrganizer of course also correctly shows these events. > The original RFC was clear and > easy to implement: > > 1. Create a union of all RDATEs and RRULEs > 2. Create a union of all EXDATEs and EXRULEs > 3. Create a difference of the two unions Exactly. Once you have some code creating the recurrence set for one rule, the rest is really simple. Cheers, Reinhold > I know this is easy to implement because I've done it. My example works > with the original RFC. I challenge anyone to prove that it doesn't work > with the original RFC. > > Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS > the original. > > That is the point I am trying to make. Calcify isn't just simplifying or > clarifying the spec, it is breaking it. > > -Adrian > > --- On Wed, 11/19/08, Ben Fortuna wrote: > > From: Ben Fortuna > > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question > > To: adrian.crum@yahoo.com > > Cc: ietf-calsify@osafoundation.org > > Date: Wednesday, November 19, 2008, 9:24 PM > > Adrian, > > > > I think you'll find it was removed as it is hard to > > implement, meaning that > > many CUAs either didn't support it or had a broken > > implementation. > > > > It should be possible to write some code that converts a > > recurrence rule to > > a list of dates in a specified period (see iCal4j), so > > from there it > > shouldn't be hard to convert an EXRULE to a list of > > EXDATES, and if you > > choose a large enough period of time it should achieve the > > same effect > > (albeit a bit more verbose). > > > > Once the new RFC is approved I might investigate supporting > > automatic > > conversion of deprecated properties, so things like this > > should ultimately > > be transparent. > > > > regards, > > ben > > > > > > On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum > > > > wrote: > > > Oops, I meant for this to go to the mailing list. > > > > > > > > > --- On Wed, 11/19/08, Adrian Crum > > > > wrote: > > > > From: Adrian Crum > > > > Subject: Re: [ietf-calsify] EXRULE Question > > > > To: "Bernard Desruisseaux" > > > > > > > > > > Date: Wednesday, November 19, 2008, 8:26 PM > > > > Thank you for the reply! > > > > > > > > That is very disappointing. Now I'm forced to > > > > define a > > > > > > finite amount of discreet dates for exclusions > > > > instead of > > > > > > specifying a few rules. > > > > > > > > I was better off with the original specification. > > > > > > > > Other than "no one is using EXRULE" - > > > > what is the > > > > > > compelling reason to remove it from the RFC? Is > > > > everyone in > > > > > > calcify that sure that it will never be used? > > > > > > > > I thought the objective was to simplify and > > > > clarify the > > > > > > RFC, not cripple it. > > > > > > > > -Adrian > > > > > > > > > > > > --- On Wed, 11/19/08, Bernard Desruisseaux > > > > > > > > wrote: > > > > > From: Bernard Desruisseaux > > > > > > > > > > > > > > > > > Subject: Re: [ietf-calsify] EXRULE Question > > > > > To: adrian.crum@yahoo.com > > > > > Cc: ietf-calsify@osafoundation.org > > > > > Date: Wednesday, November 19, 2008, 5:34 PM > > > > > > > > > > Adrian Crum wrote: > > > > > > While browsing the internet I ran > > > > across the > > > > > > notes > > > > > > > > > from 2006 > > > > > > > > > > > regarding deprecating or removing > > > > EXRULE and > > > > > > EXDATE > > > > > > > > > from RFC 2445. > > > > > > > > > > > The comments made at the time indicated > > > > that no > > > > > > one > > > > > > > > > was using it. > > > > > > > > > > Only EXRULE was deprecated. EXDATE can > > > > still be used. > > > > > > > > I'm curious - without those > > > > properties, how > > > > > > would > > > > > > > > > one express a > > > > > > > > > > > Monday through Friday at 8:00 AM event, > > > > except on > > > > > > US > > > > > > > > > federal > > > > > > > > > > > holidays? > > > > > > > > > > Now, you are forced to specify EXDATE one by > > > > one. And > > > > > > of > > > > > > > > > course the number of EXDATE needs to be > > > > finite... > > > > > > > Which is what you'll end up with if you > > > > create > > > > > > your > > > > > > > > > event with pretty much any calendar client > > > > in use > > > > > > today... > > > > > > > > > Cheers, > > > > > Bernard > > > > > > > > > > > I created an example iCalendar based on > > > > the > > > > > > original > > > > > > > > > RFC: > > > > > > > > > > > > BEGIN:VCALENDAR > > > > > > PRODID:-//Apache Open For > > > > Business//Work Effort > > > > > > > Calendar//EN > > > > > > > > > > > VERSION:2.0 > > > > > > CALSCALE:GREGORIAN > > > > > > DESCRIPTION:Adrian's Calendar > > > > > > BEGIN:VEVENT > > > > > > DTSTAMP:20081112T180905Z > > > > > > CREATED:20081111T231419Z > > > > > > LAST-MODIFIED:20081111T232507Z > > > > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020 > > > > > > SUMMARY:Work Schedule > > > > > > DESCRIPTION:Work Schedule > > > > > > ORGANIZER;CN=THE ADMINISTRATOR: > > > > > > DTSTART:20080101T000043 > > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 > > > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 > > > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 > > > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH > > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 > > > > > > > > END:VEVENT > > > > > > END:VCALENDAR > > > > > > > > > > > > I can't find any mention of an > > > > alternative to > > > > > > > using the EXRULE property, so where would > > > > one go from > > > > > > here? > > > > > > > > > > -Adrian > > > > > > > > _______________________________________________ > > > > > > > > > > ietf-calsify mailing list > > > > > > ietf-calsify@osafoundation.org > > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > _______________________________________________ > > > ietf-calsify mailing list > > > ietf-calsify@osafoundation.org > > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > > > > > > -- > > Less Talk More Gossip > > http://elbento.com > > > > Dan Quayle - "This President is going to lead us out > > of this recovery." > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify - -- - ------------------------------------------------------------------ Reinhold Kainhofer, Vienna University of Technology, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJJUYJTqjEwhXvPN0RApRkAJ0a2C8kKowuzBGEhLR5d1chFgUgsgCdE7Bf R/+5ecN8D5w4XUQqlFyBhLQ= =nrSO -----END PGP SIGNATURE----- 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 D483179401D for ; Wed, 19 Nov 2008 21:36:21 -0800 (PST) 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.000, BAYES_00=-2.599] 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 X5T12bM1l7I1 for ; Wed, 19 Nov 2008 21:36:19 -0800 (PST) Received: from web63102.mail.re1.yahoo.com (web63102.mail.re1.yahoo.com [69.147.96.244]) by leka.osafoundation.org (Postfix) with SMTP id 702827841EF for ; Wed, 19 Nov 2008 21:36:19 -0800 (PST) Received: (qmail 51986 invoked by uid 60001); 20 Nov 2008 05:36:18 -0000 X-YMail-OSG: 5zP92_cVM1k_XQYTggCOXcfmqtd6bqSnWBzhVsaQ7iOu88fklV962n6vAL5Upj1UJvAdETVqI6V.3a5lBi3deLVtRbPbA5xlJhsfqZlRLkKuxbl5KYtryoknpDSY1r13ZML7GUvAW5MpIkEwyusyDqCQXBk- Received: from [76.167.216.213] by web63102.mail.re1.yahoo.com via HTTP; Wed, 19 Nov 2008 21:36:18 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 19 Nov 2008 21:36:18 -0800 (PST) From: Adrian Crum To: ietf-calsify@osafoundation.org In-Reply-To: <91390c30811192124g1889e068h40e20f6ea1f0141e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <612821.51679.qm@web63102.mail.re1.yahoo.com> Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian.crum@yahoo.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 05:36:22 -0000 Ben, Thanks for the reply. I disagree that it is hard to implement. The original RFC was clear and easy to implement: 1. Create a union of all RDATEs and RRULEs 2. Create a union of all EXDATEs and EXRULEs 3. Create a difference of the two unions I know this is easy to implement because I've done it. My example works with the original RFC. I challenge anyone to prove that it doesn't work with the original RFC. Now it doesn't work with the DRAFT RFC. So, in essence, the draft BREAKS the original. That is the point I am trying to make. Calcify isn't just simplifying or clarifying the spec, it is breaking it. -Adrian --- On Wed, 11/19/08, Ben Fortuna wrote: > From: Ben Fortuna > Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question > To: adrian.crum@yahoo.com > Cc: ietf-calsify@osafoundation.org > Date: Wednesday, November 19, 2008, 9:24 PM > Adrian, > > I think you'll find it was removed as it is hard to > implement, meaning that > many CUAs either didn't support it or had a broken > implementation. > > It should be possible to write some code that converts a > recurrence rule to > a list of dates in a specified period (see iCal4j), so > from there it > shouldn't be hard to convert an EXRULE to a list of > EXDATES, and if you > choose a large enough period of time it should achieve the > same effect > (albeit a bit more verbose). > > Once the new RFC is approved I might investigate supporting > automatic > conversion of deprecated properties, so things like this > should ultimately > be transparent. > > regards, > ben > > > On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum > wrote: > > > Oops, I meant for this to go to the mailing list. > > > > > > --- On Wed, 11/19/08, Adrian Crum > wrote: > > > > > From: Adrian Crum > > > Subject: Re: [ietf-calsify] EXRULE Question > > > To: "Bernard Desruisseaux" > > > > Date: Wednesday, November 19, 2008, 8:26 PM > > > Thank you for the reply! > > > > > > That is very disappointing. Now I'm forced to > define a > > > finite amount of discreet dates for exclusions > instead of > > > specifying a few rules. > > > > > > I was better off with the original specification. > > > > > > Other than "no one is using EXRULE" - > what is the > > > compelling reason to remove it from the RFC? Is > everyone in > > > calcify that sure that it will never be used? > > > > > > I thought the objective was to simplify and > clarify the > > > RFC, not cripple it. > > > > > > -Adrian > > > > > > > > > --- On Wed, 11/19/08, Bernard Desruisseaux > > > wrote: > > > > > > > From: Bernard Desruisseaux > > > > > > > Subject: Re: [ietf-calsify] EXRULE Question > > > > To: adrian.crum@yahoo.com > > > > Cc: ietf-calsify@osafoundation.org > > > > Date: Wednesday, November 19, 2008, 5:34 PM > > > > Adrian Crum wrote: > > > > > While browsing the internet I ran > across the > > > notes > > > > from 2006 > > > > > regarding deprecating or removing > EXRULE and > > > EXDATE > > > > from RFC 2445. > > > > > The comments made at the time indicated > that no > > > one > > > > was using it. > > > > > > > > Only EXRULE was deprecated. EXDATE can > still be used. > > > > > > > > > > > > > > I'm curious - without those > properties, how > > > would > > > > one express a > > > > > Monday through Friday at 8:00 AM event, > except on > > > US > > > > federal > > > > > holidays? > > > > > > > > Now, you are forced to specify EXDATE one by > one. And > > > of > > > > course the number of EXDATE needs to be > finite... > > > > > > > > Which is what you'll end up with if you > create > > > your > > > > event with pretty much any calendar client > in use > > > today... > > > > > > > > Cheers, > > > > Bernard > > > > > > > > > > > > > > I created an example iCalendar based on > the > > > original > > > > RFC: > > > > > > BEGIN:VCALENDAR > > > > > PRODID:-//Apache Open For > Business//Work Effort > > > > Calendar//EN > > > > > VERSION:2.0 > > > > > CALSCALE:GREGORIAN > > > > > DESCRIPTION:Adrian's Calendar > > > > > BEGIN:VEVENT > > > > > DTSTAMP:20081112T180905Z > > > > > CREATED:20081111T231419Z > > > > > LAST-MODIFIED:20081111T232507Z > > > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020 > > > > > SUMMARY:Work Schedule > > > > > DESCRIPTION:Work Schedule > > > > > ORGANIZER;CN=THE ADMINISTRATOR: > > > > > DTSTART:20080101T000043 > > > > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH > > > > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 > > > > > END:VEVENT > > > > > END:VCALENDAR > > > > > > > > > > I can't find any mention of an > alternative to > > > > using the EXRULE property, so where would > one go from > > > here? > > > > > > > > > > -Adrian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > ietf-calsify mailing list > > > > > ietf-calsify@osafoundation.org > > > > > > > > > > > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > > > > > > > > > _______________________________________________ > > ietf-calsify mailing list > > ietf-calsify@osafoundation.org > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > > -- > Less Talk More Gossip > http://elbento.com > > Dan Quayle - "This President is going to lead us out > of this recovery." 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 621307841F0 for ; Wed, 19 Nov 2008 21:26:37 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 MHTH8uPtv+JK for ; Wed, 19 Nov 2008 21:26:35 -0800 (PST) Received: from hs-out-0708.google.com (hs-out-0708.google.com [64.233.178.250]) by leka.osafoundation.org (Postfix) with ESMTP id ECCF47841EF for ; Wed, 19 Nov 2008 21:26:34 -0800 (PST) Received: by hs-out-0708.google.com with SMTP id 54so165502hsz.11 for ; Wed, 19 Nov 2008 21:26:34 -0800 (PST) Received: by 10.64.210.3 with SMTP id i3mr1684797qbg.30.1227158793852; Wed, 19 Nov 2008 21:26:33 -0800 (PST) Received: by 10.64.142.1 with HTTP; Wed, 19 Nov 2008 21:26:33 -0800 (PST) Message-ID: <91390c30811192126o4585d842n2ad1dba456450044@mail.gmail.com> Date: Thu, 20 Nov 2008 16:26:33 +1100 From: "Ben Fortuna" Sender: benfortuna@gmail.com To: adrian.crum@yahoo.com In-Reply-To: <91390c30811192124g1889e068h40e20f6ea1f0141e@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2498_12805163.1227158793860" References: <406748.62999.qm@web63105.mail.re1.yahoo.com> <91390c30811192124g1889e068h40e20f6ea1f0141e@mail.gmail.com> X-Google-Sender-Auth: 144749febf22f064 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question 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: Thu, 20 Nov 2008 05:26:37 -0000 ------=_Part_2498_12805163.1227158793860 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry, that should read: "Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties *in iCal4j*, so things like this should ultimately be transparent." On Thu, Nov 20, 2008 at 4:24 PM, Ben Fortuna wrote: > Adrian, > > I think you'll find it was removed as it is hard to implement, meaning that > many CUAs either didn't support it or had a broken implementation. > > It should be possible to write some code that converts a recurrence rule to > a list of dates in a specified period (see iCal4j), so from there it > shouldn't be hard to convert an EXRULE to a list of EXDATES, and if you > choose a large enough period of time it should achieve the same effect > (albeit a bit more verbose). > > Once the new RFC is approved I might investigate supporting automatic > conversion of deprecated properties, so things like this should ultimately > be transparent. > > regards, > ben > > > > On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum wrote: > >> Oops, I meant for this to go to the mailing list. >> >> >> --- On Wed, 11/19/08, Adrian Crum wrote: >> >> > From: Adrian Crum >> > Subject: Re: [ietf-calsify] EXRULE Question >> > To: "Bernard Desruisseaux" >> > Date: Wednesday, November 19, 2008, 8:26 PM >> > Thank you for the reply! >> > >> > That is very disappointing. Now I'm forced to define a >> > finite amount of discreet dates for exclusions instead of >> > specifying a few rules. >> > >> > I was better off with the original specification. >> > >> > Other than "no one is using EXRULE" - what is the >> > compelling reason to remove it from the RFC? Is everyone in >> > calcify that sure that it will never be used? >> > >> > I thought the objective was to simplify and clarify the >> > RFC, not cripple it. >> > >> > -Adrian >> > >> > >> > --- On Wed, 11/19/08, Bernard Desruisseaux >> > wrote: >> > >> > > From: Bernard Desruisseaux >> > >> > > Subject: Re: [ietf-calsify] EXRULE Question >> > > To: adrian.crum@yahoo.com >> > > Cc: ietf-calsify@osafoundation.org >> > > Date: Wednesday, November 19, 2008, 5:34 PM >> > > Adrian Crum wrote: >> > > > While browsing the internet I ran across the >> > notes >> > > from 2006 >> > > > regarding deprecating or removing EXRULE and >> > EXDATE >> > > from RFC 2445. >> > > > The comments made at the time indicated that no >> > one >> > > was using it. >> > > >> > > Only EXRULE was deprecated. EXDATE can still be used. >> > > >> > > > >> > > > I'm curious - without those properties, how >> > would >> > > one express a >> > > > Monday through Friday at 8:00 AM event, except on >> > US >> > > federal >> > > > holidays? >> > > >> > > Now, you are forced to specify EXDATE one by one. And >> > of >> > > course the number of EXDATE needs to be finite... >> > > >> > > Which is what you'll end up with if you create >> > your >> > > event with pretty much any calendar client in use >> > today... >> > > >> > > Cheers, >> > > Bernard >> > > >> > > > >> > > > I created an example iCalendar based on the >> > original >> > > RFC: > >> > > > BEGIN:VCALENDAR >> > > > PRODID:-//Apache Open For Business//Work Effort >> > > Calendar//EN >> > > > VERSION:2.0 >> > > > CALSCALE:GREGORIAN >> > > > DESCRIPTION:Adrian's Calendar >> > > > BEGIN:VEVENT >> > > > DTSTAMP:20081112T180905Z >> > > > CREATED:20081111T231419Z >> > > > LAST-MODIFIED:20081111T232507Z >> > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020 >> > > > SUMMARY:Work Schedule >> > > > DESCRIPTION:Work Schedule >> > > > ORGANIZER;CN=THE ADMINISTRATOR: >> > > > DTSTART:20080101T000043 >> > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH >> > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 >> > > > END:VEVENT >> > > > END:VCALENDAR >> > > > >> > > > I can't find any mention of an alternative to >> > > using the EXRULE property, so where would one go from >> > here? >> > > > >> > > > -Adrian >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > _______________________________________________ >> > > > ietf-calsify mailing list >> > > > ietf-calsify@osafoundation.org >> > > > >> > > >> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> > > > >> >> >> >> _______________________________________________ >> ietf-calsify mailing list >> ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify >> > > > -- > Dan Quayle - "This President is going to lead us out of this recovery." -- Fred Allen - "An associate producer is the only guy in Hollywood who will associate with a producer." ------=_Part_2498_12805163.1227158793860 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry, that should read:

"Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties in iCal4j, so things like this should ultimately be transparent."


On Thu, Nov 20, 2008 at 4:24 PM, Ben Fortuna <fortuna@users.sourceforge.net> wrote:
Adrian,

I think you'll find it was removed as it is hard to implement, meaning that many CUAs either didn't support it or had a broken implementation.

It should be possible to write some code that converts a recurrence rule to a list of  dates in a specified period (see iCal4j), so from there it shouldn't be hard to convert an EXRULE to a list of EXDATES, and if you choose a large enough period of time it should achieve the same effect (albeit a bit more verbose).

Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties, so things like this should ultimately be transparent.

regards,
ben



On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum <adrian.crum@yahoo.com> wrote:
Oops, I meant for this to go to the mailing list.


--- On Wed, 11/19/08, Adrian Crum <adrian.crum@yahoo.com> wrote:

> From: Adrian Crum <adrian.crum@yahoo.com>
> Subject: Re: [ietf-calsify] EXRULE Question
> To: "Bernard Desruisseaux" <bernard.desruisseaux@oracle.com>
> Date: Wednesday, November 19, 2008, 8:26 PM
> Thank you for the reply!
>
> That is very disappointing. Now I'm forced to define a
> finite amount of discreet dates for exclusions instead of
> specifying a few rules.
>
> I was better off with the original specification.
>
> Other than "no one is using EXRULE" - what is the
> compelling reason to remove it from the RFC? Is everyone in
> calcify that sure that it will never be used?
>
> I thought the objective was to simplify and clarify the
> RFC, not cripple it.
>
> -Adrian
>
>
> --- On Wed, 11/19/08, Bernard Desruisseaux
> <bernard.desruisseaux@oracle.com> wrote:
>
> > From: Bernard Desruisseaux
> <bernard.desruisseaux@oracle.com>
> > Subject: Re: [ietf-calsify] EXRULE Question
> > To: adrian.crum@yahoo.com
> > Cc: ietf-calsify@osafoundation.org
> > Date: Wednesday, November 19, 2008, 5:34 PM
> > Adrian Crum wrote:
> > > While browsing the internet I ran across the
> notes
> > from 2006
> > > regarding deprecating or removing EXRULE and
> EXDATE
> > from RFC 2445.
> > > The comments made at the time indicated that no
> one
> > was using it.
> >
> > Only EXRULE was deprecated.  EXDATE can still be used.
> >
> > >
> > > I'm curious - without those properties, how
> would
> > one express a
> > > Monday through Friday at 8:00 AM event, except on
> US
> > federal
> > > holidays?
> >
> > Now, you are forced to specify EXDATE one by one. And
> of
> > course the number of EXDATE needs to be finite...
> >
> > Which is what you'll end up with if you create
> your
> > event with pretty much any calendar client in use
> today...
> >
> > Cheers,
> > Bernard
> >
> > >
> > > I created an example iCalendar based on the
> original
> > RFC: >
> > > BEGIN:VCALENDAR
> > > PRODID:-//Apache Open For Business//Work Effort
> > Calendar//EN
> > > VERSION:2.0
> > > CALSCALE:GREGORIAN
> > > DESCRIPTION:Adrian's Calendar
> > > BEGIN:VEVENT
> > > DTSTAMP:20081112T180905Z
> > > CREATED:20081111T231419Z
> > > LAST-MODIFIED:20081111T232507Z
> > > X-ORG-OFBIZ-WORKEFFORT-ID:10020
> > > SUMMARY:Work Schedule
> > > DESCRIPTION:Work Schedule
> > > ORGANIZER;CN=THE ADMINISTRATOR:
> > > DTSTART:20080101T000043
> > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
> > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
> > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
> > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
> > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
> > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
> > > END:VEVENT
> > > END:VCALENDAR
> > >
> > > I can't find any mention of an alternative to
> > using the EXRULE property, so where would one go from
> here?
> > >
> > > -Adrian
> > >
> > >
> > >
> > >
> > >
> > >
> _______________________________________________
> > > ietf-calsify mailing list
> > > ietf-calsify@osafoundation.org
> > >
> >
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> > >



_______________________________________________
ietf-calsify mailing list
ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


--
Dan Quayle  - "This President is going to lead us out of this recovery."



--
Fred Allen  - "An associate producer is the only guy in Hollywood who will associate with a producer." ------=_Part_2498_12805163.1227158793860-- 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 88B2E79401D for ; Wed, 19 Nov 2008 21:24:31 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 nAuYxEoCa1Bg for ; Wed, 19 Nov 2008 21:24:20 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by leka.osafoundation.org (Postfix) with ESMTP id 4E9497841EF for ; Wed, 19 Nov 2008 21:24:20 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 31so150477yxl.81 for ; Wed, 19 Nov 2008 21:24:19 -0800 (PST) Received: by 10.64.183.1 with SMTP id g1mr1688798qbf.26.1227158658589; Wed, 19 Nov 2008 21:24:18 -0800 (PST) Received: by 10.64.142.1 with HTTP; Wed, 19 Nov 2008 21:24:18 -0800 (PST) Message-ID: <91390c30811192124g1889e068h40e20f6ea1f0141e@mail.gmail.com> Date: Thu, 20 Nov 2008 16:24:18 +1100 From: "Ben Fortuna" Sender: benfortuna@gmail.com To: adrian.crum@yahoo.com In-Reply-To: <406748.62999.qm@web63105.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2456_5317785.1227158658574" References: <406748.62999.qm@web63105.mail.re1.yahoo.com> X-Google-Sender-Auth: 940263d6a8e578c1 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] Fw: Re: EXRULE Question 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: Thu, 20 Nov 2008 05:24:31 -0000 ------=_Part_2456_5317785.1227158658574 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Adrian, I think you'll find it was removed as it is hard to implement, meaning that many CUAs either didn't support it or had a broken implementation. It should be possible to write some code that converts a recurrence rule to a list of dates in a specified period (see iCal4j), so from there it shouldn't be hard to convert an EXRULE to a list of EXDATES, and if you choose a large enough period of time it should achieve the same effect (albeit a bit more verbose). Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties, so things like this should ultimately be transparent. regards, ben On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum wrote: > Oops, I meant for this to go to the mailing list. > > > --- On Wed, 11/19/08, Adrian Crum wrote: > > > From: Adrian Crum > > Subject: Re: [ietf-calsify] EXRULE Question > > To: "Bernard Desruisseaux" > > Date: Wednesday, November 19, 2008, 8:26 PM > > Thank you for the reply! > > > > That is very disappointing. Now I'm forced to define a > > finite amount of discreet dates for exclusions instead of > > specifying a few rules. > > > > I was better off with the original specification. > > > > Other than "no one is using EXRULE" - what is the > > compelling reason to remove it from the RFC? Is everyone in > > calcify that sure that it will never be used? > > > > I thought the objective was to simplify and clarify the > > RFC, not cripple it. > > > > -Adrian > > > > > > --- On Wed, 11/19/08, Bernard Desruisseaux > > wrote: > > > > > From: Bernard Desruisseaux > > > > > Subject: Re: [ietf-calsify] EXRULE Question > > > To: adrian.crum@yahoo.com > > > Cc: ietf-calsify@osafoundation.org > > > Date: Wednesday, November 19, 2008, 5:34 PM > > > Adrian Crum wrote: > > > > While browsing the internet I ran across the > > notes > > > from 2006 > > > > regarding deprecating or removing EXRULE and > > EXDATE > > > from RFC 2445. > > > > The comments made at the time indicated that no > > one > > > was using it. > > > > > > Only EXRULE was deprecated. EXDATE can still be used. > > > > > > > > > > > I'm curious - without those properties, how > > would > > > one express a > > > > Monday through Friday at 8:00 AM event, except on > > US > > > federal > > > > holidays? > > > > > > Now, you are forced to specify EXDATE one by one. And > > of > > > course the number of EXDATE needs to be finite... > > > > > > Which is what you'll end up with if you create > > your > > > event with pretty much any calendar client in use > > today... > > > > > > Cheers, > > > Bernard > > > > > > > > > > > I created an example iCalendar based on the > > original > > > RFC: > > > > > BEGIN:VCALENDAR > > > > PRODID:-//Apache Open For Business//Work Effort > > > Calendar//EN > > > > VERSION:2.0 > > > > CALSCALE:GREGORIAN > > > > DESCRIPTION:Adrian's Calendar > > > > BEGIN:VEVENT > > > > DTSTAMP:20081112T180905Z > > > > CREATED:20081111T231419Z > > > > LAST-MODIFIED:20081111T232507Z > > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020 > > > > SUMMARY:Work Schedule > > > > DESCRIPTION:Work Schedule > > > > ORGANIZER;CN=THE ADMINISTRATOR: > > > > DTSTART:20080101T000043 > > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 > > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 > > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 > > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH > > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 > > > > END:VEVENT > > > > END:VCALENDAR > > > > > > > > I can't find any mention of an alternative to > > > using the EXRULE property, so where would one go from > > here? > > > > > > > > -Adrian > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > ietf-calsify mailing list > > > > ietf-calsify@osafoundation.org > > > > > > > > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > > > > > > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > -- Less Talk More Gossip http://elbento.com Dan Quayle - "This President is going to lead us out of this recovery." ------=_Part_2456_5317785.1227158658574 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Adrian,

I think you'll find it was removed as it is hard to implement, meaning that many CUAs either didn't support it or had a broken implementation.

It should be possible to write some code that converts a recurrence rule to a list of  dates in a specified period (see iCal4j), so from there it shouldn't be hard to convert an EXRULE to a list of EXDATES, and if you choose a large enough period of time it should achieve the same effect (albeit a bit more verbose).

Once the new RFC is approved I might investigate supporting automatic conversion of deprecated properties, so things like this should ultimately be transparent.

regards,
ben


On Thu, Nov 20, 2008 at 3:33 PM, Adrian Crum <adrian.crum@yahoo.com> wrote:
Oops, I meant for this to go to the mailing list.


--- On Wed, 11/19/08, Adrian Crum <adrian.crum@yahoo.com> wrote:

> From: Adrian Crum <adrian.crum@yahoo.com>
> Subject: Re: [ietf-calsify] EXRULE Question
> To: "Bernard Desruisseaux" <bernard.desruisseaux@oracle.com>
> Date: Wednesday, November 19, 2008, 8:26 PM
> Thank you for the reply!
>
> That is very disappointing. Now I'm forced to define a
> finite amount of discreet dates for exclusions instead of
> specifying a few rules.
>
> I was better off with the original specification.
>
> Other than "no one is using EXRULE" - what is the
> compelling reason to remove it from the RFC? Is everyone in
> calcify that sure that it will never be used?
>
> I thought the objective was to simplify and clarify the
> RFC, not cripple it.
>
> -Adrian
>
>
> --- On Wed, 11/19/08, Bernard Desruisseaux
> <bernard.desruisseaux@oracle.com> wrote:
>
> > From: Bernard Desruisseaux
> <bernard.desruisseaux@oracle.com>
> > Subject: Re: [ietf-calsify] EXRULE Question
> > To: adrian.crum@yahoo.com
> > Cc: ietf-calsify@osafoundation.org
> > Date: Wednesday, November 19, 2008, 5:34 PM
> > Adrian Crum wrote:
> > > While browsing the internet I ran across the
> notes
> > from 2006
> > > regarding deprecating or removing EXRULE and
> EXDATE
> > from RFC 2445.
> > > The comments made at the time indicated that no
> one
> > was using it.
> >
> > Only EXRULE was deprecated.  EXDATE can still be used.
> >
> > >
> > > I'm curious - without those properties, how
> would
> > one express a
> > > Monday through Friday at 8:00 AM event, except on
> US
> > federal
> > > holidays?
> >
> > Now, you are forced to specify EXDATE one by one. And
> of
> > course the number of EXDATE needs to be finite...
> >
> > Which is what you'll end up with if you create
> your
> > event with pretty much any calendar client in use
> today...
> >
> > Cheers,
> > Bernard
> >
> > >
> > > I created an example iCalendar based on the
> original
> > RFC: >
> > > BEGIN:VCALENDAR
> > > PRODID:-//Apache Open For Business//Work Effort
> > Calendar//EN
> > > VERSION:2.0
> > > CALSCALE:GREGORIAN
> > > DESCRIPTION:Adrian's Calendar
> > > BEGIN:VEVENT
> > > DTSTAMP:20081112T180905Z
> > > CREATED:20081111T231419Z
> > > LAST-MODIFIED:20081111T232507Z
> > > X-ORG-OFBIZ-WORKEFFORT-ID:10020
> > > SUMMARY:Work Schedule
> > > DESCRIPTION:Work Schedule
> > > ORGANIZER;CN=THE ADMINISTRATOR:
> > > DTSTART:20080101T000043
> > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8
> > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1
> > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4
> > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO
> > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11
> > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH
> > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25
> > > END:VEVENT
> > > END:VCALENDAR
> > >
> > > I can't find any mention of an alternative to
> > using the EXRULE property, so where would one go from
> here?
> > >
> > > -Adrian
> > >
> > >
> > >
> > >
> > >
> > >
> _______________________________________________
> > > ietf-calsify mailing list
> > > ietf-calsify@osafoundation.org
> > >
> >
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> > >



_______________________________________________
ietf-calsify mailing list
ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



--
Less Talk More Gossip
http://elbento.com

Dan Quayle  - "This President is going to lead us out of this recovery." ------=_Part_2456_5317785.1227158658574-- 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 66D967841F0 for ; Wed, 19 Nov 2008 20:33:19 -0800 (PST) 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=[BAYES_00=-2.599] 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 GKrm6BwFe+Du for ; Wed, 19 Nov 2008 20:33:08 -0800 (PST) Received: from web63105.mail.re1.yahoo.com (web63105.mail.re1.yahoo.com [69.147.96.247]) by leka.osafoundation.org (Postfix) with SMTP id EC2DF7841EF for ; Wed, 19 Nov 2008 20:33:07 -0800 (PST) Received: (qmail 63264 invoked by uid 60001); 20 Nov 2008 04:33:07 -0000 X-YMail-OSG: 9B9CYLoVM1mzjpMg8Rt5Y0IDNednnWYPINqJg6YacNqrv6vPD1wWyu.e Received: from [76.167.216.213] by web63105.mail.re1.yahoo.com via HTTP; Wed, 19 Nov 2008 20:33:06 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 19 Nov 2008 20:33:06 -0800 (PST) From: Adrian Crum To: ietf-calsify@osafoundation.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <406748.62999.qm@web63105.mail.re1.yahoo.com> Subject: [ietf-calsify] Fw: Re: EXRULE Question X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian.crum@yahoo.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2008 04:33:19 -0000 Oops, I meant for this to go to the mailing list. --- On Wed, 11/19/08, Adrian Crum wrote: > From: Adrian Crum > Subject: Re: [ietf-calsify] EXRULE Question > To: "Bernard Desruisseaux" > Date: Wednesday, November 19, 2008, 8:26 PM > Thank you for the reply! > > That is very disappointing. Now I'm forced to define a > finite amount of discreet dates for exclusions instead of > specifying a few rules. > > I was better off with the original specification. > > Other than "no one is using EXRULE" - what is the > compelling reason to remove it from the RFC? Is everyone in > calcify that sure that it will never be used? > > I thought the objective was to simplify and clarify the > RFC, not cripple it. > > -Adrian > > > --- On Wed, 11/19/08, Bernard Desruisseaux > wrote: > > > From: Bernard Desruisseaux > > > Subject: Re: [ietf-calsify] EXRULE Question > > To: adrian.crum@yahoo.com > > Cc: ietf-calsify@osafoundation.org > > Date: Wednesday, November 19, 2008, 5:34 PM > > Adrian Crum wrote: > > > While browsing the internet I ran across the > notes > > from 2006 > > > regarding deprecating or removing EXRULE and > EXDATE > > from RFC 2445. > > > The comments made at the time indicated that no > one > > was using it. > > > > Only EXRULE was deprecated. EXDATE can still be used. > > > > > > > > I'm curious - without those properties, how > would > > one express a > > > Monday through Friday at 8:00 AM event, except on > US > > federal > > > holidays? > > > > Now, you are forced to specify EXDATE one by one. And > of > > course the number of EXDATE needs to be finite... > > > > Which is what you'll end up with if you create > your > > event with pretty much any calendar client in use > today... > > > > Cheers, > > Bernard > > > > > > > > I created an example iCalendar based on the > original > > RFC: > > > > BEGIN:VCALENDAR > > > PRODID:-//Apache Open For Business//Work Effort > > Calendar//EN > > > VERSION:2.0 > > > CALSCALE:GREGORIAN > > > DESCRIPTION:Adrian's Calendar > > > BEGIN:VEVENT > > > DTSTAMP:20081112T180905Z > > > CREATED:20081111T231419Z > > > LAST-MODIFIED:20081111T232507Z > > > X-ORG-OFBIZ-WORKEFFORT-ID:10020 > > > SUMMARY:Work Schedule > > > DESCRIPTION:Work Schedule > > > ORGANIZER;CN=THE ADMINISTRATOR: > > > DTSTART:20080101T000043 > > > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO > > > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 > > > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO > > > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO > > > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 > > > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO > > > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 > > > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH > > > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 > > > END:VEVENT > > > END:VCALENDAR > > > > > > I can't find any mention of an alternative to > > using the EXRULE property, so where would one go from > here? > > > > > > -Adrian > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 2182F7841F1 for ; Wed, 19 Nov 2008 17:34:23 -0800 (PST) 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.000, BAYES_00=-2.599] 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 Mi3tkaplNbgN for ; Wed, 19 Nov 2008 17:34:12 -0800 (PST) Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 579917841EF for ; Wed, 19 Nov 2008 17:34:12 -0800 (PST) Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAK1YQwI027375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Nov 2008 01:34:27 GMT Received: from acsmt703.oracle.com (acsmt703.oracle.com [141.146.40.81]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAK1YM5I001730; Thu, 20 Nov 2008 01:34:23 GMT Received: from [141.144.96.142] (/141.144.96.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Nov 2008 01:34:06 +0000 Message-ID: <4924BE8C.2030106@oracle.com> Date: Wed, 19 Nov 2008 20:34:04 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: adrian.crum@yahoo.com References: <694410.9213.qm@web63103.mail.re1.yahoo.com> In-Reply-To: <694410.9213.qm@web63103.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt703.oracle.com [141.146.40.81] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010201.4924BE90.0016:SCFSTAT928724,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] EXRULE Question 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: Thu, 20 Nov 2008 01:34:23 -0000 Adrian Crum wrote: > While browsing the internet I ran across the notes from 2006 > regarding deprecating or removing EXRULE and EXDATE from RFC 2445. > The comments made at the time indicated that no one was using it. Only EXRULE was deprecated. EXDATE can still be used. > > I'm curious - without those properties, how would one express a > Monday through Friday at 8:00 AM event, except on US federal > holidays? Now, you are forced to specify EXDATE one by one. And of course the number of EXDATE needs to be finite... Which is what you'll end up with if you create your event with pretty much any calendar client in use today... Cheers, Bernard > > I created an example iCalendar based on the original RFC: > > BEGIN:VCALENDAR > PRODID:-//Apache Open For Business//Work Effort Calendar//EN > VERSION:2.0 > CALSCALE:GREGORIAN > DESCRIPTION:Adrian's Calendar > BEGIN:VEVENT > DTSTAMP:20081112T180905Z > CREATED:20081111T231419Z > LAST-MODIFIED:20081111T232507Z > X-ORG-OFBIZ-WORKEFFORT-ID:10020 > SUMMARY:Work Schedule > DESCRIPTION:Work Schedule > ORGANIZER;CN=THE ADMINISTRATOR: > DTSTART:20080101T000043 > RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO > EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 > EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO > EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO > EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 > EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO > EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 > EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH > EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 > END:VEVENT > END:VCALENDAR > > I can't find any mention of an alternative to using the EXRULE property, so where would one go from here? > > -Adrian > > > > > > > _______________________________________________ > 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 C9C157841F0 for ; Wed, 19 Nov 2008 17:15:24 -0800 (PST) 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] 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 L8st0u0TXoVT for ; Wed, 19 Nov 2008 17:15:23 -0800 (PST) Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 4E4D37841EF for ; Wed, 19 Nov 2008 17:15:23 -0800 (PST) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAK1FaAw012407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Nov 2008 01:15:37 GMT Received: from acsmt700.oracle.com (acsmt700.oracle.com [141.146.40.70]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAK1FL86002012; Thu, 20 Nov 2008 01:15:22 GMT Received: from [141.144.96.142] (/141.144.96.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Nov 2008 01:15:15 +0000 Message-ID: <4924BA21.1000302@oracle.com> Date: Wed, 19 Nov 2008 20:15:13 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ken Shoemake References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> <491E8942.9030205@gmail.com> In-Reply-To: <491E8942.9030205@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt700.oracle.com [141.146.40.70] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A09020A.4924BA25.017B:SCFSTAT928724,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 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: Thu, 20 Nov 2008 01:15:24 -0000 Hi Ken, I finally submitted the XML version of the draft to the IETF. It is now available here: http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-09.xml It is also accessible from the "Calsify Status Pages" here: http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/ Cheers, Bernard Ken Shoemake wrote: > Trying this reply again also. > > Bernard Desruisseaux wrote: > > I've been using Julian Reschke's "extract-artwork.xslt" > transformation against the XML version of the draft to extract ABNF from > the draft. See: > > > > > http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork > > > Will the XML version be available when the standard is approved? If so, > then extraction from that would indeed seem easier and more reliable > than using a text-based tool like aex. Unfortunately, I cannot seem to > find a copy of the draft in XML format in the obvious place, > > Where should I be looking? > > -- Ken > > _______________________________________________ > 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 D22D5794024 for ; Wed, 19 Nov 2008 12:41:45 -0800 (PST) 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, UPPERCASE_50_75=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 Yu4YXyh64K2i for ; Wed, 19 Nov 2008 12:41:45 -0800 (PST) Received: from web63103.mail.re1.yahoo.com (web63103.mail.re1.yahoo.com [69.147.96.245]) by leka.osafoundation.org (Postfix) with SMTP id 4E97779401D for ; Wed, 19 Nov 2008 12:41:45 -0800 (PST) Received: (qmail 9561 invoked by uid 60001); 19 Nov 2008 20:41:44 -0000 X-YMail-OSG: a7YSzbcVM1mJagbDIGxMMSfemm90oH9gyoXUAe.ZF_jkinjv2ykbvIYt590LUAnDw.GKYi9Z_byy4xgHaLxGYsni455UR7ybErU_HgUCkhon1rhsyV6uy5cKSKZwHJ0pe1fK45LiwbNbNXKrww_sn5gMt1Y- Received: from [71.119.123.156] by web63103.mail.re1.yahoo.com via HTTP; Wed, 19 Nov 2008 12:41:44 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 19 Nov 2008 12:41:44 -0800 (PST) From: Adrian Crum To: ietf-calsify@osafoundation.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <694410.9213.qm@web63103.mail.re1.yahoo.com> Subject: [ietf-calsify] EXRULE Question X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian.crum@yahoo.com List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2008 20:41:46 -0000 While browsing the internet I ran across the notes from 2006 regarding deprecating or removing EXRULE and EXDATE from RFC 2445. The comments made at the time indicated that no one was using it. I'm curious - without those properties, how would one express a Monday through Friday at 8:00 AM event, except on US federal holidays? I created an example iCalendar based on the original RFC: BEGIN:VCALENDAR PRODID:-//Apache Open For Business//Work Effort Calendar//EN VERSION:2.0 CALSCALE:GREGORIAN DESCRIPTION:Adrian's Calendar BEGIN:VEVENT DTSTAMP:20081112T180905Z CREATED:20081111T231419Z LAST-MODIFIED:20081111T232507Z X-ORG-OFBIZ-WORKEFFORT-ID:10020 SUMMARY:Work Schedule DESCRIPTION:Work Schedule ORGANIZER;CN=THE ADMINISTRATOR: DTSTART:20080101T000043 RRULE:FREQ=DAILY;BYDAY=MO,TU,WE,TH,FR;BYHOUR=8 EXRULE:FREQ=MONTHLY;BYMONTH=1;BYDAY=3MO EXRULE:FREQ=MONTHLY;BYMONTH=1;BYMONTHDAY=1 EXRULE:FREQ=MONTHLY;BYMONTH=2;BYDAY=3MO EXRULE:FREQ=MONTHLY;BYMONTH=5;BYDAY=-1MO EXRULE:FREQ=MONTHLY;BYMONTH=7;BYMONTHDAY=4 EXRULE:FREQ=MONTHLY;BYMONTH=9;BYDAY=1MO EXRULE:FREQ=MONTHLY;BYMONTH=10;BYDAY=2MO EXRULE:FREQ=MONTHLY;BYMONTH=11;BYMONTHDAY=11 EXRULE:FREQ=MONTHLY;BYMONTH=11;BYDAY=4TH EXRULE:FREQ=MONTHLY;BYMONTH=12;BYMONTHDAY=25 END:VEVENT END:VCALENDAR I can't find any mention of an alternative to using the EXRULE property, so where would one go from here? -Adrian 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 C86AD7841F6 for ; Tue, 18 Nov 2008 02:38:55 -0800 (PST) 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.000, BAYES_00=-2.599] 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 i8XeUoV9h3NR for ; Tue, 18 Nov 2008 02:38:54 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by leka.osafoundation.org (Postfix) with ESMTP id 3800C7841EF for ; Tue, 18 Nov 2008 02:38:54 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 31so1110176yxl.81 for ; Tue, 18 Nov 2008 02:38:53 -0800 (PST) Received: by 10.90.73.17 with SMTP id v17mr3375336aga.25.1227004733443; Tue, 18 Nov 2008 02:38:53 -0800 (PST) Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id 6sm4030897agd.37.2008.11.18.02.38.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Nov 2008 02:38:52 -0800 (PST) Message-ID: <49229B2F.7070105@gmail.com> Date: Tue, 18 Nov 2008 05:38:39 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> <491DE939.2090306@gmail.com> <1EC65F4E98D14B5D807BC9A5AF381767@NIGEL08> In-Reply-To: <1EC65F4E98D14B5D807BC9A5AF381767@NIGEL08> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 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, 18 Nov 2008 10:38:55 -0000 Nigel Swinson wrote: > But then immediately proceeding that you've included two 20+ line > sections supposedly where one is different to the other. Sifting > through what you have changed is extremely difficult. Before I gave the change I stated that it consisted of moving the note on notes and including a new note. Perhaps it was confusing because I gave the new text first, and did not label which was old and which new. Still, I assumed that Bernard, who had asked "[W]hat change or clarifying text would you like to see added in the draft?", would have little difficulty with my reply. An ancient but still useful standard for changes is much as you suggest, however in this case it would obscure the fact that a paragraph (the note on notes) was moved. Moving that paragraph makes logical sense for two reasons: 1. It should precede the use of the indented note convention for my new remark. 2. It seems natural in the flow of exposition for it to follow the paragraph on formal and informal notation. Again, the only substantive change proposed is to add one new sentence. I am satisfied that such a note will suffice, and there is precedent. Among the ABNF given in rfc2445bis-09 is this: eventc = "BEGIN" ":" "VEVENT" CRLF eventprop *alarmc "END" ":" "VEVENT" CRLF Section 2.3 of [RFC5234] says that "ABNF strings are case insensitive", so implicitly we know that "begin:vevent" or "Begin:vEvent" are to be accepted along with "BEGIN:VEVENT". Yet rfc2445bis-09 finds it prudent to explicitly say "All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive." Adding the comment about white space is also prudent, as I hope we agree. -- Ken Shoemake 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 65C9B77D6FF for ; Mon, 17 Nov 2008 07:55:28 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -3.757 X-Spam-Level: X-Spam-Status: No, score=-3.757 tagged_above=-50 required=4 tests=[AWL=-1.158, BAYES_00=-2.599] 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 YWxcviN3XG4N for ; Mon, 17 Nov 2008 07:55:26 -0800 (PST) Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 664933E3F45 for ; Mon, 17 Nov 2008 07:55:26 -0800 (PST) Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAHFtcKI005722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Nov 2008 15:55:39 GMT Received: from acsmt704.oracle.com (acsmt704.oracle.com [141.146.40.82]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAHFtQ8k023725; Mon, 17 Nov 2008 15:55:33 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Nov 2008 15:55:11 +0000 Message-ID: <492193DD.6080502@oracle.com> Date: Mon, 17 Nov 2008 10:55:09 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ken Shoemake References: <491DF9B2.2080603@gmail.com> In-Reply-To: <491DF9B2.2080603@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt704.oracle.com [141.146.40.82] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.492193E8.01CB:SCFSTAT928724,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] rfc2445bis-09 nit 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: Mon, 17 Nov 2008 15:55:28 -0000 Hi Ken, The General Area Review Team (Gen-ART) also spotted this typo during their review. It's fixed now. Thanks, Bernard Ken Shoemake wrote: > In section 3.7.3, Product Identifier, the Description says "This > property SHOULD not"; its capitalization needs to be changed to "This > property SHOULD NOT", according to the nit finder. > > Also there is some complaint about boilerplate which may deserve attention. > > -- Ken > _______________________________________________ > 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 1EFF77841F2 for ; Sat, 15 Nov 2008 00:33:21 -0800 (PST) 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=[BAYES_00=-2.599] 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 SMo2ukUfsHQD for ; Sat, 15 Nov 2008 00:33:10 -0800 (PST) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.241]) by leka.osafoundation.org (Postfix) with ESMTP id 7753E7841EF for ; Sat, 15 Nov 2008 00:33:10 -0800 (PST) Received: by ag-out-0708.google.com with SMTP id 23so1597011agd.11 for ; Sat, 15 Nov 2008 00:33:10 -0800 (PST) Received: by 10.90.91.9 with SMTP id o9mr1334580agb.94.1226737989909; Sat, 15 Nov 2008 00:33:09 -0800 (PST) Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id y56sm1859392hsb.19.2008.11.15.00.33.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 15 Nov 2008 00:33:09 -0800 (PST) Message-ID: <491E8942.9030205@gmail.com> Date: Sat, 15 Nov 2008 03:33:06 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> In-Reply-To: <491D8D86.4090905@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 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: Sat, 15 Nov 2008 08:33:21 -0000 Trying this reply again also. Bernard Desruisseaux wrote: > I've been using Julian Reschke's "extract-artwork.xslt" transformation against the XML version of the draft to extract ABNF from the draft. See: > > http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork Will the XML version be available when the standard is approved? If so, then extraction from that would indeed seem easier and more reliable than using a text-based tool like aex. Unfortunately, I cannot seem to find a copy of the draft in XML format in the obvious place, Where should I be looking? -- Ken 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 55ADA7841EF for ; Sat, 15 Nov 2008 00:32:20 -0800 (PST) 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=[BAYES_00=-2.599] 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 BboMMjMy1Scl for ; Sat, 15 Nov 2008 00:32:09 -0800 (PST) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.249]) by leka.osafoundation.org (Postfix) with ESMTP id 5C2A87841ED for ; Sat, 15 Nov 2008 00:32:09 -0800 (PST) Received: by ag-out-0708.google.com with SMTP id 23so1596898agd.11 for ; Sat, 15 Nov 2008 00:32:08 -0800 (PST) Received: by 10.90.51.13 with SMTP id y13mr1374317agy.10.1226737928733; Sat, 15 Nov 2008 00:32:08 -0800 (PST) Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id o61sm1858687hsc.7.2008.11.15.00.32.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 15 Nov 2008 00:32:08 -0800 (PST) Message-ID: <491E8901.2010201@gmail.com> Date: Sat, 15 Nov 2008 03:32:01 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> In-Reply-To: <491D8D86.4090905@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 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: Sat, 15 Nov 2008 08:32:20 -0000 Trying reply again. Bernard Desruisseaux wrote: > Given that we are already making reference to RFC5234, and that our intent is NOT to permit linear white space around delimiters or string segments, what change or clarifying text would you like to see added in the draft? In section 2, Basic Grammar and Conventions, I would revise the text to include a new note, and move the note on notes, as follows. ---------- This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo. The notation used in this memo is the ABNF notation of [RFC5234]. Readers intending on implementing the format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. Note: Spaces and horizontal tabs (formally, linear white space) are only allowed where explicitly stated in the notation, never implicitly; see section 3.1 of [RFC5234]. All numeric values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. ---------- This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. The notation used in this memo is the ABNF notation of [RFC5234]. Readers intending on implementing the format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. All numeric values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo. ---------- The single new sentence provides two benefits. 1. It states the intent here, rather than forcing the reader to sift through and interpret a large secondary document. 2. It shields this document from historical interpretations of ABNF so there can be no question of accidental intent. Although files will be read by programs more than humans, text formats frequently admit flexible use of linear white space. When going against convention it is best to alert readers explicitly. -- Ken Shoemake 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 764BF794019 for ; Fri, 14 Nov 2008 23:48:31 -0800 (PST) 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.000, BAYES_00=-2.599] 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 l7NY3g+qPHf7 for ; Fri, 14 Nov 2008 23:48:20 -0800 (PST) Received: from mail-gx0-f28.google.com (mail-gx0-f28.google.com [209.85.217.28]) by leka.osafoundation.org (Postfix) with ESMTP id 729847841F3 for ; Fri, 14 Nov 2008 23:48:20 -0800 (PST) Received: by mail-gx0-f28.google.com with SMTP id 9so765858gxk.3 for ; Fri, 14 Nov 2008 23:48:20 -0800 (PST) Received: by 10.100.3.4 with SMTP id 4mr879125anc.27.1226735300266; Fri, 14 Nov 2008 23:48:20 -0800 (PST) Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id b37sm999283ana.10.2008.11.14.23.48.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 23:48:19 -0800 (PST) Message-ID: <491E7EC1.9000106@gmail.com> Date: Sat, 15 Nov 2008 02:48:17 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: multipart/mixed; boundary="------------090601050806040306020607" Subject: [ietf-calsify] [Fwd: Re: ABNF intent in rfc2445bis-09] 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: Sat, 15 Nov 2008 07:48:31 -0000 This is a multi-part message in MIME format. --------------090601050806040306020607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------090601050806040306020607 Content-Type: message/rfc822; name="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml" Return-Path: Received: from ?192.168.0.132? (pool-64-222-236-186.port.east.verizon.net [64.222.236.186]) by mx.google.com with ESMTPS id 38sm946771aga.4.2008.11.14.14.26.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 14:26:36 -0800 (PST) Message-ID: <491DFB1A.40409@gmail.com> Date: Fri, 14 Nov 2008 17:26:34 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> In-Reply-To: <491D8D86.4090905@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > I've been using Julian Reschke's "extract-artwork.xslt" transformation > against the XML version of the draft to extract ABNF from the draft. See: > > http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork Will the XML version be available when the standard is approved? If so, then extraction from that would indeed seem easier and more reliable than using a text-based tool like aex. Unfortunately, I cannot seem to find a copy of the draft in XML format in the obvious place, Where should I be looking? -- Ken --------------090601050806040306020607-- 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 5D07F77D709 for ; Fri, 14 Nov 2008 23:47:55 -0800 (PST) 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.000, BAYES_00=-2.599] 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 hq8whFVUvjP5 for ; Fri, 14 Nov 2008 23:47:52 -0800 (PST) Received: from mail-gx0-f28.google.com (mail-gx0-f28.google.com [209.85.217.28]) by leka.osafoundation.org (Postfix) with ESMTP id AE0FF77D6F9 for ; Fri, 14 Nov 2008 23:47:52 -0800 (PST) Received: by gxk9 with SMTP id 9so765858gxk.3 for ; Fri, 14 Nov 2008 23:47:52 -0800 (PST) Received: by 10.100.190.14 with SMTP id n14mr880633anf.19.1226735271997; Fri, 14 Nov 2008 23:47:51 -0800 (PST) Received: from ?192.168.0.132? (pool-64-222-236-186.port.east.verizon.net [64.222.236.186]) by mx.google.com with ESMTPS id c14sm2458070ana.58.2008.11.14.23.47.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 23:47:51 -0800 (PST) Message-ID: <491E7EA0.4000808@gmail.com> Date: Sat, 15 Nov 2008 02:47:44 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: multipart/mixed; boundary="------------020208010108070901030609" Subject: [ietf-calsify] [Fwd: Re: ABNF intent in rfc2445bis-09] 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: Sat, 15 Nov 2008 07:47:55 -0000 This is a multi-part message in MIME format. --------------020208010108070901030609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------020208010108070901030609 Content-Type: message/rfc822; name="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [ietf-calsify] ABNF intent in rfc2445bis-09.eml" Return-Path: Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id m71sm791938rnd.3.2008.11.14.13.10.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 13:10:24 -0800 (PST) Message-ID: <491DE939.2090306@gmail.com> Date: Fri, 14 Nov 2008 16:10:17 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Bernard Desruisseaux Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 References: <491D371B.2060507@gmail.com> <491D8D86.4090905@oracle.com> In-Reply-To: <491D8D86.4090905@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Desruisseaux wrote: > Given that we are already making reference to RFC5234, and that our > intent is NOT to permit linear white space around delimiters or string > segments, what change or clarifying text would you like to see added in > the draft? In section 2, Basic Grammar and Conventions, I would revise the text to include a new note, and move the note on notes, as follows. ---------- This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo. The notation used in this memo is the ABNF notation of [RFC5234]. Readers intending on implementing the format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. Note: Spaces and horizontal tabs (formally, linear white space) are only allowed where explicitly stated in the notation, never implicitly; see section 3.1 of [RFC5234]. All numeric values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. ---------- This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. The notation used in this memo is the ABNF notation of [RFC5234]. Readers intending on implementing the format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. All numeric values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo. ---------- The single new sentence provides two benefits. 1. It states the intent here, rather than forcing the reader to sift through and interpret a large secondary document. 2. It shields this document from historical interpretations of ABNF so there can be no question of accidental intent. Although files will be read by programs more than humans, text formats frequently admit flexible use of linear white space. When going against convention it is best to alert readers explicitly. -- Ken Shoemake --------------020208010108070901030609-- 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 5A0D577D70B for ; Fri, 14 Nov 2008 14:20:54 -0800 (PST) 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=[BAYES_00=-2.599] 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 tjHfb9amTEKo for ; Fri, 14 Nov 2008 14:20:39 -0800 (PST) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.249]) by leka.osafoundation.org (Postfix) with ESMTP id E9A5A77D709 for ; Fri, 14 Nov 2008 14:20:38 -0800 (PST) Received: by ag-out-0708.google.com with SMTP id 23so1512323agd.11 for ; Fri, 14 Nov 2008 14:20:38 -0800 (PST) Received: by 10.90.84.2 with SMTP id h2mr1115687agb.42.1226701238022; Fri, 14 Nov 2008 14:20:38 -0800 (PST) Received: from ?192.168.0.132? (pool-64-222-236-186.port.east.verizon.net [64.222.236.186]) by mx.google.com with ESMTPS id 38sm942671aga.4.2008.11.14.14.20.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 14:20:37 -0800 (PST) Message-ID: <491DF9B2.2080603@gmail.com> Date: Fri, 14 Nov 2008 17:20:34 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ietf-calsify] rfc2445bis-09 nit 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: Fri, 14 Nov 2008 22:20:54 -0000 In section 3.7.3, Product Identifier, the Description says "This property SHOULD not"; its capitalization needs to be changed to "This property SHOULD NOT", according to the nit finder. Also there is some complaint about boilerplate which may deserve attention. -- Ken 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 6198477D718 for ; Fri, 14 Nov 2008 06:39:28 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.353 X-Spam-Level: X-Spam-Status: No, score=-4.353 tagged_above=-50 required=4 tests=[AWL=-1.754, BAYES_00=-2.599] 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 ILgXMy0+elsc for ; Fri, 14 Nov 2008 06:39:26 -0800 (PST) Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id E165777D717 for ; Fri, 14 Nov 2008 06:39:25 -0800 (PST) Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAEEd1lu001108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 Nov 2008 14:39:03 GMT Received: from acsmt705.oracle.com (acsmt705.oracle.com [141.146.40.83]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mAEEdJRq015114; Fri, 14 Nov 2008 14:39:20 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 Nov 2008 14:39:05 +0000 Message-ID: <491D8D86.4090905@oracle.com> Date: Fri, 14 Nov 2008 09:39:02 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Ken Shoemake References: <491D371B.2060507@gmail.com> In-Reply-To: <491D371B.2060507@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt705.oracle.com [141.146.40.83] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.491D8D8B.00A2:SCFSTAT928724,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] ABNF intent in rfc2445bis-09 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: Fri, 14 Nov 2008 14:39:28 -0000 Hi Ken, See answer inline. Ken Shoemake wrote: > With regard to syntax, first some context: > > Note that rfc4234 on ABNF says (section 3.1) > ---------- > LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing > model. A string of contiguous characters (values) is parsed > according to the rules defined in ABNF. For Internet specifications, > there is some history of permitting linear white space (space and > horizontal tab) to be freely and implicitly interspersed around major > constructs, such as delimiting special characters or atomic strings. > > NOTE: > > This specification for ABNF does not provide for implicit > specification of linear white space. > > Any grammar that wishes to permit linear white space around > delimiters or string segments must specify it explicitly. > ---------- > One way to convey that implicit white space is not allowed is to state > that the ABNF uses this newer rfc4234 instead of rfc2234; that's obscure > and error prone compared to explicitly stating the intent. The draft already makes reference to RFC5234 (which obsoleted RFC4234): http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-09#section-1 > The memo also includes a formal grammar for the content type based on > the Internet ABNF defined in [RFC5234]. http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-09#section-2 > The notation used in this memo is the ABNF notation of [RFC5234]. > > > So now the question: > > In rfc2445, line folding is specified, but beyond that the explicit ABNF > syntax apparently does not permit white space between tokens. For example, > BEGIN:VEVENT > would be correct but > BEGIN: VEVENT > would not. A robust parser will accept the latter anyway, but the spec > might best spell out the intent: is such white space definitely allowed > or definitely disallowed? > > Also: > The IETF-Tools page () provides two tools for > automatically combing through the ABNF in a specification (here, > 'draft-ietf-calsify-rfc2445bis-09'). The first extracts lines of syntax; > it is Bill Fenner's 'aex' (). > Unfortunately, the current draft causes it to stumble in a few places. > The second tool parses ABNF for errors; it is Bill's ABNF Parser, 'bap' > (). It finds issues with the > ABNF in the spec even after the obvious problems left by aex are cleaned > up. Please clarify which issues are reported. Bill's ABNF Parser currently reports "No errors during parsing". That being said, it is reporting multiple differences between the original and Bill's "canonical" form. For instance, the draft currently specifies: "BEGIN" ":" "VCALENDAR" instead of: "BEGIN:VCALENDAR" Is this what you're making reference to? > Nevertheless, its strict read of the grammar seems to imply that > white space between tokens is not formally allowed at present. > > Is there intent to make automatic extraction and parsing of the ABNF > work? I've been using Julian Reschke's "extract-artwork.xslt" transformation against the XML version of the draft to extract ABNF from the draft. See: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork I was not aware of the existence of the 'aex' tool. How do you recommend to modify the draft such that 'aex' won't pick up the following lines by mistake: > c=US???(cn=Jim%20Dolittle)":mailto:jimdo@example.com > > TZID=America/New_York:19980119T020000 > > FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 > > BYMINUTE=30 > > FREQ=DAILY;COUNT=10;INTERVAL=2 > > TZID=America/New_York:083000 > > decimal = degrees + minutes/60 + seconds/3600. > > c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\, > > BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA > BYDAY=MO,WE,FR > > BYMONTHDAY=2,3,4,5,6,7,8 > Is there intent to clarify the permissibility of white space > between tokens? Given that we are already making reference to RFC5234, and that our intent is NOT to permit linear white space around delimiters or string segments, what change or clarifying text would you like to see added in the draft? Thanks, Bernard > > -- Ken Shoemake > _______________________________________________ > 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 5F9B877D708 for ; Fri, 14 Nov 2008 00:30:34 -0800 (PST) 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=[BAYES_00=-2.599] 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 tCsB4n+ZA3YH for ; Fri, 14 Nov 2008 00:30:23 -0800 (PST) Received: from mail-gx0-f28.google.com (mail-gx0-f28.google.com [209.85.217.28]) by leka.osafoundation.org (Postfix) with ESMTP id 7989377D6FE for ; Fri, 14 Nov 2008 00:30:23 -0800 (PST) Received: by gxk9 with SMTP id 9so518537gxk.3 for ; Fri, 14 Nov 2008 00:30:22 -0800 (PST) Received: by 10.100.143.14 with SMTP id q14mr380806and.47.1226651422782; Fri, 14 Nov 2008 00:30:22 -0800 (PST) Received: from ?192.168.0.132? (pool-64-222-236-186.port.east.verizon.net [64.222.236.186]) by mx.google.com with ESMTPS id b32sm674384ana.54.2008.11.14.00.30.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Nov 2008 00:30:22 -0800 (PST) Message-ID: <491D371B.2060507@gmail.com> Date: Fri, 14 Nov 2008 03:30:19 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ietf-calsify] ABNF intent in rfc2445bis-09 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: Fri, 14 Nov 2008 08:30:34 -0000 With regard to syntax, first some context: Note that rfc4234 on ABNF says (section 3.1) ---------- LINEAR WHITE SPACE: Concatenation is at the core of the ABNF parsing model. A string of contiguous characters (values) is parsed according to the rules defined in ABNF. For Internet specifications, there is some history of permitting linear white space (space and horizontal tab) to be freely and implicitly interspersed around major constructs, such as delimiting special characters or atomic strings. NOTE: This specification for ABNF does not provide for implicit specification of linear white space. Any grammar that wishes to permit linear white space around delimiters or string segments must specify it explicitly. ---------- One way to convey that implicit white space is not allowed is to state that the ABNF uses this newer rfc4234 instead of rfc2234; that's obscure and error prone compared to explicitly stating the intent. So now the question: In rfc2445, line folding is specified, but beyond that the explicit ABNF syntax apparently does not permit white space between tokens. For example, BEGIN:VEVENT would be correct but BEGIN: VEVENT would not. A robust parser will accept the latter anyway, but the spec might best spell out the intent: is such white space definitely allowed or definitely disallowed? Also: The IETF-Tools page () provides two tools for automatically combing through the ABNF in a specification (here, 'draft-ietf-calsify-rfc2445bis-09'). The first extracts lines of syntax; it is Bill Fenner's 'aex' (). Unfortunately, the current draft causes it to stumble in a few places. The second tool parses ABNF for errors; it is Bill's ABNF Parser, 'bap' (). It finds issues with the ABNF in the spec even after the obvious problems left by aex are cleaned up. Nevertheless, its strict read of the grammar seems to imply that white space between tokens is not formally allowed at present. Is there intent to make automatic extraction and parsing of the ABNF work? Is there intent to clarify the permissibility of white space between tokens? -- Ken Shoemake 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 AFF3E3E3EBE for ; Thu, 13 Nov 2008 12:52:46 -0800 (PST) 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=[BAYES_00=-2.599] 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 WEf7rlf1-5Yd for ; Thu, 13 Nov 2008 12:52:46 -0800 (PST) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.251]) by leka.osafoundation.org (Postfix) with ESMTP id C787C3E3EC3 for ; Thu, 13 Nov 2008 12:52:45 -0800 (PST) Received: by ag-out-0708.google.com with SMTP id 23so1053203agd.11 for ; Thu, 13 Nov 2008 12:52:45 -0800 (PST) Received: by 10.90.120.14 with SMTP id s14mr8925188agc.20.1226555865261; Wed, 12 Nov 2008 21:57:45 -0800 (PST) Received: from ?192.168.0.132? ([64.222.236.186]) by mx.google.com with ESMTPS id 8sm12370863agd.21.2008.11.12.21.57.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Nov 2008 21:57:44 -0800 (PST) Message-ID: <491BC1CE.1070609@gmail.com> Date: Thu, 13 Nov 2008 00:57:34 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: iCalendar group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ietf-calsify] Test post 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: Thu, 13 Nov 2008 20:52:46 -0000 My first two posts to this list have not appeared. This is a test. -- Ken Shoemake 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 C770D3E3EBE for ; Thu, 13 Nov 2008 12:42:52 -0800 (PST) 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=[BAYES_00=-2.599] 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 KD8Zu5yNr7DR for ; Thu, 13 Nov 2008 12:42:42 -0800 (PST) Received: from mail-gx0-f26.google.com (mail-gx0-f26.google.com [209.85.217.26]) by leka.osafoundation.org (Postfix) with ESMTP id 7286B3E3EAB for ; Thu, 13 Nov 2008 12:42:42 -0800 (PST) Received: by gxk7 with SMTP id 7so364871gxk.17 for ; Thu, 13 Nov 2008 12:42:41 -0800 (PST) Received: by 10.100.168.18 with SMTP id q18mr4799499ane.7.1226593279240; Thu, 13 Nov 2008 08:21:19 -0800 (PST) Received: from ?192.168.0.132? (pool-64-222-236-186.port.east.verizon.net [64.222.236.186]) by mx.google.com with ESMTPS id c29sm19254033anc.49.2008.11.13.08.21.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Nov 2008 08:21:18 -0800 (PST) Message-ID: <491C53F7.2040402@gmail.com> Date: Thu, 13 Nov 2008 11:21:11 -0500 From: Ken Shoemake User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ietf-calsify] Pulling hair 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: Thu, 13 Nov 2008 20:42:52 -0000 Three prior posts have failed to reach the list. Fourth time the charm? -- Ken Shoemake 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 AAFD877D70F; Sun, 9 Nov 2008 09:44:08 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001, HTML_MESSAGE=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 3930P3coiIPB; Sun, 9 Nov 2008 09:44:08 -0800 (PST) Received: from arista.notesdev.ibm.com (arista.notesdev.ibm.com [205.159.212.203]) by leka.osafoundation.org (Postfix) with ESMTP id D485477D709; Sun, 9 Nov 2008 09:44:07 -0800 (PST) In-Reply-To: <49150142.9050706@everyone.net> To: Caleb Richardson Message-ID: Date: Sun, 9 Nov 2008 13:43:47 -0500 From: "Robert Ransdell" Content-Type: multipart/alternative; boundary="=_alternative 00616BDD852574FC_=" References: <49150142.9050706@everyone.net> MIME-Version: 1.0 X-KeepSent: FE5E1E17:0EE08146-852574FC:0066329E; name=$KeepSent; type=4 X-Mailer: Lotus Notes Build V85_11052008 November 05, 2008 X-Disclaimed: 59383 Cc: ietf-calsify@osafoundation.org, ietf-calsify-bounces@osafoundation.org Subject: Re: [ietf-calsify] Issue 9 of Reinhold Kainhofer's iTIP Review 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: Sun, 09 Nov 2008 17:44:08 -0000 --=_alternative 00616BDD852574FC_= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable It does not work for bumping sequence number only on entire recurrence=20 set. When individual occurrences are rescheduled, the chair needs to check for = next sequence number over entire set and set that sequence just for that=20 occurrence one past the last sequence number used . The invitees will=20 accept that occurrence reschedule and return an accept/decline using that=20 sequence number. The chair matches response on sequence number for=20 occurrence and marks status updated/decline for that occurrence.=20 From: Caleb Richardson To: ietf-calsify@osafoundation.org Date: 11/07/2008 10:39 PM Subject: [ietf-calsify] Issue 9 of Reinhold Kainhofer's iTIP Review Sent by: ietf-calsify-bounces@osafoundation.org Issue 9 of Reinhold Kainhofer's iTIP Review Hello, I have an issue with the changes recently made in rfc2445bis-09 and=20 2446bis-08 as a result of Issue 9 of Reinhold Kainhofer's iTIP Review. In =20 the following statement was added: "Recurrence instances of a recurring component MAY have different=20 sequence numbers." There were also some changes made to , although I am still trying to=20 determine the implications of those changes. As discussed in this thread started by Cyrus Daboo (it occurred on this=20 mailing list in October 2007):=20 http://osdir.com/ml/ietf.calsify/2007-10/msg00004.html, there are severe=20 consequences if two CUAs differ on their opinion of how to increment=20 SEQUENCE. There is a good example of potential problems in that thread,=20 and I believe the conclusion was that keeping one SEQUENCE per=20 recurrence set was the superior approach. --=20 Caleb Richardson Everyone.net =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --=_alternative 00616BDD852574FC_= Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable It does not work for bumping sequence nu= mber only on entire recurrenceset.
= When individual occurrences are rescheduled,  the chair needs to check for next sequence number over entire set and set that sequence just for that occurrence one past the last sequence number used .  The invitees will accept that occurrence reschedule and return an accept/decline using that sequence number.  The chair matches response on sequence number for occurrence and marks status updated= /decline for that occurrence.


From:Caleb Richardson <caleb@everyone.net>= ;
To:ietf-calsify@osafound= ation.org
Date:11/07/2008 = 10:39 PM
Subject:[ietf-cal= sify] Issue 9 of Reinhold Kainhofer's iTIP Review
Sent by:ietf-= calsify-bounces@osafoundation.org



Issue 9 of Reinhold Kainhofer's iTIP Review

Hell= o,

I have an issue with the changes recently made in rfc2445bis-09 a= nd
2446bis-08 as a result of Issue 9 of Reinhold Kainhofer's iTIP Revie= w.

In <draft-ietf-calsify-rfc2445bis-09 section 3.8.7.4. Sequence= Number>
the following statement was added:

"Recurrence instances of= a recurring component MAY have different
sequence numbers."

There were also some changes made to <= ;draft-ietf-calsify-2446bis-08
section 2.1.5. Message Sequencing>, although I am still trying to determine the implications of those changes.

As discussed in this = thread started by Cyrus Daboo (it occurred on this
mailing list in October 2007):
http://osdir.= com/ml/ietf.calsify/2007-10/msg00004.html, there are severe
consequences if two CUAs differ on their opinion of ho= w to increment
SEQUENCE. There is a good example of potential problems = in that thread,
and I believe the conclusion was that keeping one SEQUENCE per
recu= rrence set was the superior approach.

--
Caleb Richardson
Eve= ryone.net
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
ietf-calsify mailing list
ietf-calsify@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/= ietf-calsify


--=_alternative 00616BDD852574FC_=-- 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 4293977D703 for ; Fri, 7 Nov 2008 19:05:43 -0800 (PST) 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=[BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001, 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 gBLh1N7c26LK for ; Fri, 7 Nov 2008 19:05:41 -0800 (PST) Received: from omta0101.mta.everyone.net (imta-38.everyone.net [216.200.145.38]) by leka.osafoundation.org (Postfix) with ESMTP id D67EC77D6FB for ; Fri, 7 Nov 2008 19:05:40 -0800 (PST) Received: from sj1-dm05.mta.everyone.net (sj1-slb03-gw2 [172.16.1.96]) by omta0101.mta.everyone.net (Postfix) with ESMTP id AF47A7C36CE for ; Fri, 7 Nov 2008 19:05:40 -0800 (PST) X-Eon-Dm: sj1-dm05 Received: by sj1-dm05.mta.everyone.net (EON-AUTHRELAY2 - 4a5503fa) id sj1-dm05.49120860.41491 for ; Fri, 7 Nov 2008 19:05:40 -0800 X-Eon-Sig: AQH1/7xJFQIEgWZggwIAAAAB,3cc550a9f811f8f4cef667e49292d3c9 Message-ID: <49150142.9050706@everyone.net> Date: Fri, 07 Nov 2008 19:02:26 -0800 From: Caleb Richardson User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ietf-calsify] Issue 9 of Reinhold Kainhofer's iTIP Review 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: Sat, 08 Nov 2008 03:05:43 -0000 Issue 9 of Reinhold Kainhofer's iTIP Review Hello, I have an issue with the changes recently made in rfc2445bis-09 and 2446bis-08 as a result of Issue 9 of Reinhold Kainhofer's iTIP Review. In the following statement was added: "Recurrence instances of a recurring component MAY have different sequence numbers." There were also some changes made to , although I am still trying to determine the implications of those changes. As discussed in this thread started by Cyrus Daboo (it occurred on this mailing list in October 2007): http://osdir.com/ml/ietf.calsify/2007-10/msg00004.html, there are severe consequences if two CUAs differ on their opinion of how to increment SEQUENCE. There is a good example of potential problems in that thread, and I believe the conclusion was that keeping one SEQUENCE per recurrence set was the superior approach. -- Caleb Richardson Everyone.net 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 67C09794039 for ; Tue, 4 Nov 2008 11:59:57 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-50 required=4 tests=[AWL=-0.000, BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=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 v0QWGLSNsVRN for ; Tue, 4 Nov 2008 11:59:56 -0800 (PST) Received: from daboo.name (daboo.name [151.201.22.177]) by leka.osafoundation.org (Postfix) with ESMTP id AD90E794018 for ; Tue, 4 Nov 2008 11:59:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id BE023EA6227 for ; Tue, 4 Nov 2008 14:59:51 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nRF87tFckbf for ; Tue, 4 Nov 2008 14:59:51 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.101.32.44]) by daboo.name (Postfix) with ESMTP id 8E2E3EA6220 for ; Tue, 4 Nov 2008 14:59:50 -0500 (EST) Date: Tue, 04 Nov 2008 14:59:47 -0400 From: Cyrus Daboo To: ietf-calsify@osafoundation.org Message-ID: <7870308886F25747791418D6@caldav.corp.apple.com> In-Reply-To: <20081104190039.170183A6C78@core3.amsl.com> References: <20081104190039.170183A6C78@core3.amsl.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [ietf-calsify] Last Call: draft-ietf-calsify-2446bis (iCalendar Transport-Independent Interoperability Protocol (iTIP)) to Proposed Standard 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, 04 Nov 2008 19:59:57 -0000 Hi, --On November 4, 2008 11:00:39 AM -0800 The IESG wrote: > The IESG has received a request from the Calendaring and Scheduling > Standards Simplification WG (calsify) to consider the following document: FYI last call of 2446bis was inadvertently asked for and has now been cancelled, so please ignore the above. To clarify, the -08 draft I posted yesterday contains many changes in response to Lisa's and Reinhold's reviews. Still outstanding are a bunch of "complex" issues from Reinhold's review. These will need more discussion. I will start posting these to the list soon so that we can work through them to resolution. The files on the wiki show the current status of dealing with Reinhold's issues: . -- Cyrus Daboo 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 7AF28794041 for ; Tue, 4 Nov 2008 11:02:24 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-50 required=4 tests=[AWL=-0.000, BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 u6F2Il--S2b5 for ; Tue, 4 Nov 2008 11:02:23 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by leka.osafoundation.org (Postfix) with ESMTP id 038DD794039 for ; Tue, 4 Nov 2008 11:02:22 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 65DD03A6CB3; Tue, 4 Nov 2008 11:01:24 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081104190125.65DD03A6CB3@core3.amsl.com> Date: Tue, 4 Nov 2008 11:01:25 -0800 (PST) Cc: ietf-calsify@osafoundation.org Subject: [ietf-calsify] Last Call: draft-ietf-calsify-rfc2445bis (Internet Calendaring and Scheduling Core Object Specification (iCalendar)) to Proposed Standard X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 19:02:24 -0000 The IESG has received a request from the Calendaring and Scheduling Standards Simplification WG (calsify) to consider the following document: - 'Internet Calendaring and Scheduling Core Object Specification (iCalendar) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13988&rfc_flag=0 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 723AC79403D for ; Tue, 4 Nov 2008 11:02:06 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-50 required=4 tests=[AWL=-0.000, BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Xzx0XqTea0tq for ; Tue, 4 Nov 2008 11:02:05 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by leka.osafoundation.org (Postfix) with ESMTP id 2D095794039 for ; Tue, 4 Nov 2008 11:02:04 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 30) id 170183A6C78; Tue, 4 Nov 2008 11:00:38 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20081104190039.170183A6C78@core3.amsl.com> Date: Tue, 4 Nov 2008 11:00:39 -0800 (PST) Cc: ietf-calsify@osafoundation.org Subject: [ietf-calsify] Last Call: draft-ietf-calsify-2446bis (iCalendar Transport-Independent Interoperability Protocol (iTIP)) to Proposed Standard X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 19:02:06 -0000 The IESG has received a request from the Calendaring and Scheduling Standards Simplification WG (calsify) to consider the following document: - 'iCalendar Transport-Independent Interoperability Protocol (iTIP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-11-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13952&rfc_flag=0 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 2B3E179402D for ; Mon, 3 Nov 2008 13:15:09 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-50 required=4 tests=[AWL=-0.000, BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Qt4SzR1nTO6x for ; Mon, 3 Nov 2008 13:15:06 -0800 (PST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by leka.osafoundation.org (Postfix) with ESMTP id 505FC794035 for ; Mon, 3 Nov 2008 13:15:00 -0800 (PST) Received: by core3.amsl.com (Postfix, from userid 0) id 2295C3A6A86; Mon, 3 Nov 2008 13:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103211502.2295C3A6A86@core3.amsl.com> Date: Mon, 3 Nov 2008 13:15:02 -0800 (PST) Cc: ietf-calsify@osafoundation.org Subject: [ietf-calsify] I-D Action:draft-ietf-calsify-2446bis-08.txt 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: Mon, 03 Nov 2008 21:15:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF. Title : iCalendar Transport-Independent Interoperability Protocol (iTIP) Author(s) : C. Daboo Filename : draft-ietf-calsify-2446bis-08.txt Pages : 130 Date : 2008-11-03 This document specifies a protocol using the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol using specific interoperable methods of communications between systems. iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-calsify-2446bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03130817.I-D@ietf.org> --NextPart-- 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 B43C8794018; Mon, 3 Nov 2008 11:14:29 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-50 required=4 tests=[AWL=0.207, BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 8Y0nAVhK3AD4; Mon, 3 Nov 2008 11:14:25 -0800 (PST) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id D1B6677D70E; Mon, 3 Nov 2008 11:14:25 -0800 (PST) Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id mA3HtECF025482; Mon, 3 Nov 2008 12:14:15 -0700 Received: from acsmt700.oracle.com (acsmt700.oracle.com [141.146.40.70]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id mA3G3VIQ013486; Mon, 3 Nov 2008 09:03:31 -0700 Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Nov 2008 16:03:30 +0000 Message-ID: <490F20D1.2060006@oracle.com> Date: Mon, 03 Nov 2008 11:03:29 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Daniel Gomez Brito References: <98357389BF0844489B5D6FD186C720489F160C@GMVMAIL1.gmv.es> <490F1CCC.9040605@oracle.com> In-Reply-To: <490F1CCC.9040605@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Cc: IETF Calsify , ietf-caldav@osafoundation.org Subject: Re: [ietf-calsify] [ietf-caldav] Question about recurring tasks. 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: Mon, 03 Nov 2008 19:14:29 -0000 BTW, I just found the following info in the Calsify Working Group Minutes for July 12, 2006: http://www.ietf.org/proceedings/06jul/minutes/calsify.txt > 7 Is DTSTART required in VTODO and VJOURNAL components when the RRULE > or EXRULE properties are defined in those components? > > Cyrus floated another idea that in the case of VTODO, perhaps the > recurrence could use the DUE property. Bernard suggested that perhaps > in the absence of DTSTART, it could default to DUE. > > Lisa pointed out that this needs more discussion beyond the room, > because different apps behave differently. > > In the end, some agreement that it's enough to clarify that for > recurring VTODOs, VJOURNALs, etc., they MUST specify DTSTART even > if it's otherwise optional. > > AI: Go forward with above clarification The clarification (issue 24) was made in the section that covers "DTSTART", see: http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-09.changes.html#rfc.issue.#issue29+dtstart_in_recur_vtodo_and_vjournal I believe similar text should appear in the "RRULE" section as well... Cheers, Bernard Bernard Desruisseaux wrote: > Hi Daniel, > > In section 4.8.5.4 Recurrence Rule of RFC 2445 it says: > > > The recurrence set is generated by considering the initial "DTSTART" > > property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" > > properties contained within the iCalendar object. > > As such, the "DTSTART" should always be specified in a calendar > component that also specify the "RRULE" property. > > That being said, this should probably be stated more clearly in rfc2445bis. > > To be very clear, in iCalendar recurrence instances of a recurring > "VTODO" are not computed based on the "DUE" property of the master > component. > > So to answer your question, a strict implementation should handle a > recurring task with no "DTSTART" as an invalid "VTODO" component, and a > relax implementation could probably fix the invalid "VTODO" component by > adding the missing "DTSTART" property with the same value as "DUE". > > Cheers, > Bernard > > Daniel Gomez Brito wrote: >> Hello: >> >> >> >> What’s the proper way to treat a recurring task with no dtstart property? >> >> It doesn’t make sense to me but it seems there’s a bunch of portable >> devices that let you build something like this: >> >> >> >> BEGIN:VCALENDAR >> >> VERSION:2.0 >> >> PRODID:-//Test//Ver 1.0.0 //ES >> >> BEGIN:VTODO >> >> SUMMARY:cxcx >> >> DESCRIPTION:xcx >> >> CATEGORIES: >> >> CLASS:PUBLIC >> >> DUE;VALUE=DATE:20081030 >> >> PRIORITY:5 >> >> ORGANIZER: >> >> PERCENT-COMPLETE:0 >> >> STATUS:NEEDS-ACTION >> >> RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TH >> >> X-FUNAMBOL-FOLDER:DEFAULT_FOLDER >> >> X-FUNAMBOL-ALLDAY:1 >> >> UID:20081028T082036Z-2 >> >> DTSTAMP:20081028T082035Z >> >> END:VTODO >> >> END:VCALENDAR >> >> >> >> Regards. >> >> >> >> ------------------------------------------------------------------------ >> Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede >> contener información clasificada por su emisor como confidencial en el >> marco de su Sistema de Gestión de Seguridad de la Información siendo >> para uso exclusivo del destinatario, quedando prohibida su divulgación >> copia o distribución a terceros sin la autorización expresa del >> remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo >> notifique al remitente y proceda a su borrado. Gracias por su >> colaboración. >> ------------------------------------------------------------------------ >> This message including any attachments may contain confidential >> information, according to our Information Security Management System, >> and intended solely for a specific individual to whom they are >> addressed. Any unauthorised copy, disclosure or distribution of this >> message is strictly forbidden. If you have received this transmission >> in error, please notify the sender immediately and delete it. >> >> ------------------------------------------------------------------------ >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> ietf-caldav mailing list -- ietf-caldav@osafoundation.org >> See http://ietf.webdav.org/caldav/ for more CalDAV resources >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > 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 AEE0F794020; Mon, 3 Nov 2008 08:08:16 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-50 required=4 tests=[AWL=-2.000, BAYES_00=-2.599, DNS_FROM_SECURITYSAGE=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 X4+I-TLMjySi; Mon, 3 Nov 2008 08:08:14 -0800 (PST) Received: from rgminet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 12DDC794018; Mon, 3 Nov 2008 08:08:13 -0800 (PST) Received: from rgminet15.oracle.com (mail-router.oracle.com [148.87.113.117]) by rgminet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mA3G8AbM008975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Nov 2008 16:08:12 GMT Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mA3G7q8V025180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 16:08:00 GMT Received: from acsmt700.oracle.com (acsmt700.oracle.com [141.146.40.70]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id mA3FkMWc008688; Mon, 3 Nov 2008 08:46:22 -0700 Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Nov 2008 15:46:21 +0000 Message-ID: <490F1CCC.9040605@oracle.com> Date: Mon, 03 Nov 2008 10:46:20 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Daniel Gomez Brito References: <98357389BF0844489B5D6FD186C720489F160C@GMVMAIL1.gmv.es> In-Reply-To: <98357389BF0844489B5D6FD186C720489F160C@GMVMAIL1.gmv.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Source-IP: rgmgw1.us.oracle.com [138.1.186.110] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010203.490F21E0.009D:SCFSTAT928724,ss=1,fgs=0 Cc: IETF Calsify , ietf-caldav@osafoundation.org Subject: Re: [ietf-calsify] [ietf-caldav] Question about recurring tasks. 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: Mon, 03 Nov 2008 16:08:16 -0000 Hi Daniel, In section 4.8.5.4 Recurrence Rule of RFC 2445 it says: > The recurrence set is generated by considering the initial "DTSTART" > property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" > properties contained within the iCalendar object. As such, the "DTSTART" should always be specified in a calendar component that also specify the "RRULE" property. That being said, this should probably be stated more clearly in rfc2445bis. To be very clear, in iCalendar recurrence instances of a recurring "VTODO" are not computed based on the "DUE" property of the master component. So to answer your question, a strict implementation should handle a recurring task with no "DTSTART" as an invalid "VTODO" component, and a relax implementation could probably fix the invalid "VTODO" component by adding the missing "DTSTART" property with the same value as "DUE". Cheers, Bernard Daniel Gomez Brito wrote: > Hello: > > > > What’s the proper way to treat a recurring task with no dtstart property? > > It doesn’t make sense to me but it seems there’s a bunch of portable > devices that let you build something like this: > > > > BEGIN:VCALENDAR > > VERSION:2.0 > > PRODID:-//Test//Ver 1.0.0 //ES > > BEGIN:VTODO > > SUMMARY:cxcx > > DESCRIPTION:xcx > > CATEGORIES: > > CLASS:PUBLIC > > DUE;VALUE=DATE:20081030 > > PRIORITY:5 > > ORGANIZER: > > PERCENT-COMPLETE:0 > > STATUS:NEEDS-ACTION > > RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TH > > X-FUNAMBOL-FOLDER:DEFAULT_FOLDER > > X-FUNAMBOL-ALLDAY:1 > > UID:20081028T082036Z-2 > > DTSTAMP:20081028T082035Z > > END:VTODO > > END:VCALENDAR > > > > Regards. > > > > ------------------------------------------------------------------------ > Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede > contener información clasificada por su emisor como confidencial en el > marco de su Sistema de Gestión de Seguridad de la Información siendo > para uso exclusivo del destinatario, quedando prohibida su divulgación > copia o distribución a terceros sin la autorización expresa del > remitente. Si Vd. ha recibido este mensaje erróneamente, se ruega lo > notifique al remitente y proceda a su borrado. Gracias por su colaboración. > ------------------------------------------------------------------------ > This message including any attachments may contain confidential > information, according to our Information Security Management System, > and intended solely for a specific individual to whom they are > addressed. Any unauthorised copy, disclosure or distribution of this > message is strictly forbidden. If you have received this transmission in > error, please notify the sender immediately and delete it. > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > ietf-caldav mailing list -- ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav