[Ietf-calsify] General Notification -- June Interop Tests and Roundtable III -- Calconnect: The Calendaring and Scheduling Consortium
Dave.Thewlis at calconnect.org (Dave Thewlis) Mon, 18 April 2005 09:34 UTC
From: "Dave.Thewlis at calconnect.org"
Date: Mon, 18 Apr 2005 09:34:09 +0000
Subject: [Ietf-calsify] General Notification -- June Interop Tests and Roundtable III -- Calconnect: The Calendaring and Scheduling Consortium
Message-ID: <4263E176.1010607@calconnect.org>
X-Date: Mon Apr 18 09:34:09 2005
An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050418/99c2e3a7/attachment.htm From Dave.Thewlis at calconnect.org Mon Apr 25 10:31:05 2005 From: Dave.Thewlis at calconnect.org (Dave Thewlis) Date: Mon Apr 25 10:33:24 2005 Subject: [Ietf-calsify] Further about the Calconnect Recurrence Questionnaire - status, thanks, and future developments Message-ID: <426D2959.90507@calconnect.org> An HTML attachment was scrubbed... URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050425/480609ec/attachment.htm X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j3PHXKaZ029786 for <ietf-calsify@osafoundation.org>; Mon, 25 Apr 2005 10:33:20 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.134.168 with plain) by smtp811.mail.sc5.yahoo.com with SMTP; 25 Apr 2005 17:31:09 -0000 Message-ID: <426D2959.90507@calconnect.org> Date: Mon, 25 Apr 2005 10:31:05 -0700 From: Dave Thewlis <Dave.Thewlis@calconnect.org> Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify list <ietf-calsify@osafoundation.org> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.499 (*) HTML_10_20, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Further about the Calconnect Recurrence Questionnaire - status, thanks, and future developments X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 25 Apr 2005 17:33:21 -0000 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <i>This message is going to all of the lists where I posted our original request for responses to the Consortium Recurrence Questionnaire, so many of you will see it more than once. My apologies for the duplications.<br> <br> </i><br> Recently I posted a request on several of the calendaring discussion lists for organizations with calendaring products/implementations to please respond to our Recurrence Questionnaire. We've had sixteen formal responses so far, and are delighted at both the number of responses and the thought and care put into them.<br> <br> Our RECURR technical committee is beginning an analysis of the responses, and may be contacting responders if we have additional questions. We hope to have our analysis done and a report issued in the next few weeks. The report will be posted on the Calconnect web site and will be announced publicly to these discussion lists. As noted in <br> my original posting, the report will maintain the confidentiality of the individual responses and will report results in an aggregate and narrative fashion.<br> <br> We also wanted to let everyone know that there will be some more questionnaires in the future. Several responders suggested a slightly different questionnaire tackling recurrence issues at a higher and more qualitative level, and we have begun work on that questionnare. We hope to announce it within the next two-three weeks. <br> <br> Additionally, other Calconnect technical committes are considering questionnaires in other areas of the RFCs of particular interest to the Calsify effort as it develops, so there is a good chance we'll be announcing these as they become ready for public consumption. We hope that you will be as supportive of these future questionnaires and help us with them as well.<br> <br> Several responders have remarked that they found the exercise of filling out the questionnaire to be of help in understanding better their own implementations, and we hope our future questionnaires, focusing on other parts of the RFCs, will be as useful to you as we hope they will be to us.<br> <br> Best regards,<br> <br> Dave Thewlis, Executive Director<br> Calconnect - The Calendaring and Scheduling Consortium<br> <br> </body> </html> X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from smtp812.mail.sc5.yahoo.com (smtp812.mail.sc5.yahoo.com [66.163.170.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j3IGY3aZ018898 for <ietf-calsify@osafoundation.org>; Mon, 18 Apr 2005 09:34:04 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.154.104 with plain) by smtp812.mail.sc5.yahoo.com with SMTP; 18 Apr 2005 16:34:01 -0000 Message-ID: <4263E176.1010607@calconnect.org> Date: Mon, 18 Apr 2005 09:33:58 -0700 From: Dave Thewlis <Dave.Thewlis@calconnect.org> Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify list <ietf-calsify@osafoundation.org> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.659 (**) HTML_40_50, HTML_FONT_FACE_CAPS, HTML_MESSAGE, HTML_TAG_EXIST_TBODY, MIME_HTML_ONLY, SARE_HTML_TD_BR X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] General Notification -- June Interop Tests and Roundtable III -- Calconnect: The Calendaring and Scheduling Consortium X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 18 Apr 2005 16:34:07 -0000 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <!-- Inserted by Calypso --> <table id="_CalyPrintHeader_" style="display: none; color: black;" border="0" cellpadding="0" cellspacing="2" rules="none" width="100%"> <tbody> <tr> <td colspan="3"> <hr color="black" noshade="noshade" size="1"><br> <br> <br> <br> <br> <br> <br> </td> </tr> <tr align="left" valign="top"> <td nowrap="nowrap" width="1"><b> Date:</b><br> <br> <br> <br> <br> <br> <br> </td> <td width="1"><br> <br> <br> <br> <br> <br> <br> </td> <td> 12/2/2004 07:52<br> <br> <br> <br> <br> <br> <br> </td> </tr> <tr align="left" valign="top"> <td nowrap="nowrap" width="1"><b> From:</b><br> <br> <br> <br> <br> <br> <br> </td> <td width="1"><br> <br> <br> <br> <br> <br> <br> </td> <td> David C. Thewlis<br> <br> <br> <br> <br> <br> <br> </td> </tr> <tr align="left" valign="top"> <td nowrap="nowrap" width="1"><b> To:</b><br> <br> <br> <br> <br> <br> <br> </td> <td width="1"><br> <br> <br> <br> <br> <br> <br> </td> <td> "calconnect-l reflector" <a class="moz-txt-link-rfc2396E" href="mailto:calconnect-l@calconnect.org"><calconnect-l@calconnect.org></a>, "ietf-caldav reflector" <a class="moz-txt-link-rfc2396E" href="mailto:ietf-caldav@osafoundation.org"><ietf-caldav@osafoundation.org></a>, "IETF CALSCH" <a class="moz-txt-link-rfc2396E" href="mailto:ietf-calendar@imc.org"><ietf-calendar@imc.org></a>, "ietf-calsify reflector" <a class="moz-txt-link-rfc2396E" href="mailto:ietf-calsify@osafoundation.org"><ietf-calsify@osafoundation.org></a>, "www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E" href="mailto:www-rdf-calendar@w3.org"><www-rdf-calendar@w3.org></a><br> <br> <br> <br> <br> <br> <br> </td> </tr> <tr align="left" valign="top"> <td nowrap="nowrap" width="1"><b> Copy:</b><br> <br> <br> <br> <br> <br> <br> </td> <td width="1"><br> <br> <br> <br> <br> <br> <br> </td> <td> "Robert Tolmach - WellGood Group" <a class="moz-txt-link-rfc2396E" href="mailto:rtolmach@WellGoodGroup.com"><rtolmach@WellGoodGroup.com></a>, "Brian Dear" <a class="moz-txt-link-rfc2396E" href="mailto:brian@evdb.com"><brian@evdb.com></a>, "John Carbone" <a class="moz-txt-link-rfc2396E" href="mailto:john-carbone@quantum-logic.net"><john-carbone@quantum-logic.net></a>, <a class="moz-txt-link-abbreviated" href="mailto:cherot@convoq.com">cherot@convoq.com</a>, <a class="moz-txt-link-abbreviated" href="mailto:georges@google.com">georges@google.com</a><br> <br> <br> <br> <br> <br> <br> </td> </tr> <tr align="left" valign="top"> <td nowrap="nowrap" width="1"><b> Subject:</b><br> <br> <br> <br> <br> <br> <br> </td> <td width="1"><br> <br> <br> <br> <br> <br> <br> </td> <td> Call for Participantion -- Second Calconnect Interop - 11-12 January 2005 - Seattle, Washington<br> <br> <br> <br> <br> <br> <br> </td> </tr> <tr> <td colspan="3"> <hr color="black" noshade="noshade" size="1"><br> <br> <br> <br> <br> <br> <br> </td> </tr> </tbody> </table> <!-- End Calypso --><!-- Inserted by Calypso --> <table id="_CalyMsgHeader_" style="display: none; color: rgb(0, 0, 0);" bgcolor="#c0c0c0" border="1" cellpadding="2" cellspacing="2" rules="none" width="100%"> <tbody> <tr bgcolor="#c0c0c0"> <td><font color="#000000" face="VERDANA,ARIAL,HELVETICA" size="-2">Received: from psmtp.com (exprod6mx6.postini.com [64.18.1.146]) by home.humboldt1.com (8.12.10/8.12.10) with SMTP id iB2Fq3mR014814 for <a class="moz-txt-link-rfc2396E" href="mailto:dthewlis@dcta.com"><dthewlis@dcta.com></a> Thu, 2 Dec 2004 07:52:03 -0800 (PST)<br> Received: from source ([208.31.106.91]) by exprod6mx6.postini.com ([64.18.5.10]) with SMTP; Thu, 02 Dec 2004 07:52:02 PST<br> Received: from aix2.egenconsulting.com (localhost [127.0.0.1]) by aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP id iB2FlvWi018040 for <a class="moz-txt-link-rfc2396E" href="mailto:calconnect-l-list@aix2.egenconsulting.com"><calconnect-l-list@aix2.egenconsulting.com></a> Thu, 2 Dec 2004 10:47:57 -0500<br> Received: (from majordom@localhost) by aix2.egenconsulting.com (8.13.1/8.13.1/Submit) id iB2FlvFI018426 for calconnect-l-list; Thu, 2 Dec 2004 10:47:57 -0500<br> X-Authentication-Warning: aix2.egenconsulting.com: majordom set sender to <a class="moz-txt-link-abbreviated" href="mailto:owner-calconnect-l@calconnect.org">owner-calconnect-l@calconnect.org</a> using -f<br> Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net [68.230.241.35]) by aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP id iB2FlcTM019480; Thu, 2 Dec 2004 10:47:38 -0500<br> Received: from davet23 ([24.254.88.112]) by fed1rmmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20041202154833.YTO5357.fed1rmmtao04.cox.net@davet23> Thu, 2 Dec 2004 10:48:33 -0500<br> Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:200412020748000071.082E3FF1@smtp.west.cox.net"><200412020748000071.082E3FF1@smtp.west.cox.net></a><br> References: <a class="moz-txt-link-rfc2396E" href="mailto:200411181732510014.00FA5091@smtp.west.cox.net"><200411181732510014.00FA5091@smtp.west.cox.net></a><br> X-Mailer: Calypso Version 3.30.00.00 (4)<br> Date: Thu, 02 Dec 2004 07:48:00 -0800<br> Reply-To: <a class="moz-txt-link-abbreviated" href="mailto:Dave.Thewlis@calconnect.org">Dave.Thewlis@calconnect.org</a><br> From: "David C. Thewlis" <a class="moz-txt-link-rfc2396E" href="mailto:Dave.Thewlis@calconnect.org"><Dave.Thewlis@calconnect.org></a><br> To: "calconnect-l reflector" <a class="moz-txt-link-rfc2396E" href="mailto:calconnect-l@calconnect.org"><calconnect-l@calconnect.org></a>, "ietf-caldav reflector" <a class="moz-txt-link-rfc2396E" href="mailto:ietf-caldav@osafoundation.org"><ietf-caldav@osafoundation.org></a>, "IETF CALSCH" <a class="moz-txt-link-rfc2396E" href="mailto:ietf-calendar@imc.org"><ietf-calendar@imc.org></a>, "ietf-calsify reflector" <a class="moz-txt-link-rfc2396E" href="mailto:ietf-calsify@osafoundation.org"><ietf-calsify@osafoundation.org></a>, "www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E" href="mailto:www-rdf-calendar@w3.org"><www-rdf-calendar@w3.org></a><br> Cc: "Robert Tolmach - WellGood Group" <a class="moz-txt-link-rfc2396E" href="mailto:rtolmach@WellGoodGroup.com"><rtolmach@WellGoodGroup.com></a>, "Brian Dear" <a class="moz-txt-link-rfc2396E" href="mailto:brian@evdb.com"><brian@evdb.com></a>, "John Carbone" <a class="moz-txt-link-rfc2396E" href="mailto:john-carbone@quantum-logic.net"><john-carbone@quantum-logic.net></a>, <a class="moz-txt-link-abbreviated" href="mailto:cherot@convoq.com">cherot@convoq.com</a>, <a class="moz-txt-link-abbreviated" href="mailto:georges@google.com">georges@google.com</a><br> Subject: Call for Participantion -- Second Calconnect Interop - 11-12 January 2005 - Seattle, Washington<br> Mime-Version: 1.0<br> Content-Type: multipart/alternative; boundary="=====_11020024806334=_"<br> Sender: <a class="moz-txt-link-abbreviated" href="mailto:owner-calconnect-l@calconnect.org">owner-calconnect-l@calconnect.org</a><br> Precedence: bulk<br> X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624 C:98.9754 )<br> X-pstn-settings: 5 (2.0000:2.0000) s gt3 gt2 gt1 r p m c <br> X-pstn-addresses: from <a class="moz-txt-link-rfc2396E" href="mailto:Dave.Thewlis@calconnect.org"><Dave.Thewlis@calconnect.org></a> forward (user good) [2395/93] <br> </font><br> <br> <br> <br> <br> <br> <br> </td> </tr> </tbody> </table> <!-- End Calypso --> <div><em>Please note that this announcement is being posted on multiple calendaring-related reflectors and to the Calconnect mailing lists to ensure as wide a distribution as possible. Our apologies if you receive multiple copies.</em></div> <div><em></em> </div> <div> </div> <div><strong>CALL FOR PARTICIPATION -- THIRD INTEROP TESTING EVENT - 1-2 June 2005<br> <br> CONSORTIUM ROUNDTABLE III MEMBER MEETINGS 1-3 June 2005<br> </strong></div> <div> </div> <div>The third Interop of The Calendaring and Scheduling Consortium (CALCONNECT.ORG) will take place Wednesday and Thursday, June 1-2, 2005. It will be hosted by Duke University in Durham, North Carolina.</div> <div> </div> <div>This event will feature multiple Interop testing scenarios. Participating organizations are welcome to test against multiple scenarios. These scenarios will be going on simultaneously so you will probably need a person for each scenario you participate in.</div> <div> <br> A Consortium Roundtable will be colocated from 1-3 June 2005 featuring Technical Committee sessions and a full Plenary of the Consortium.<br> <br> </div> <div>Space will be limited to 40 paticipants in both the Roundtable and Interop so early notification and registration is advised.</div> <div> </div> <div><strong>INTEROP SCENARIOS<br> <br> </strong></div> <br> The exact scenarios are still being worked on and can certainly change to meet participants' needs. Current plans include:<br> <ul> <li>Extended CalDAV tests between CalDAV servers and any clients supporting CalDAV</li> <li>iMIP testing</li> <li>iCalendar - General tests; clients importing/exporting each other's data with formal scripts</li> <li>Testing to support CalsifySIFY work</li> <ul> <li>Handling of Timezones</li> <li>Recurrence exceptions and Recurrence Rules</li> <li>Other specific areas as identified prior to June<br> </li> </ul> <li>Min-IOP (Minimum Interoperable Subset) validation</li> <li>Other interop scenarios can be added if there is a specific need, for example iCalendar<-->RDF<br> </li> </ul> <div><strong>WHO MAY PARTICIPATE IN THE INTEROPS</strong></div> <div> </div> <div>Any vendors or organizations wishing to test a calendaring and scheduling implementation are welcome to attend whether or not they are Consortium members. Consortium members receive a substantial discount on their Interop participation fee (see below).</div> <div> </div> <div> </div> <div><strong>CONSORTIUM ROUNDTABLE III</strong></div> <div> </div> <div>Technical committee meetings of the Calendaring and Scheduling Consortium are planned for 1-2 June at the same location, followed by an all-hands Consortium Roundtable on Friday 3 June. Interop participants who are not Consortium members may not particpate in the other Consortium activities unless their organization indicates that it wishes to do so as an observer for this Roundtable (a non-member can participate in a single Roundtable as an observer to determine its interest in joining the Consortium). A non-member Interop Participant can also join the Consortium at the event and become a member immediately and be able to participate in the technical committee and roundtable meetings.<br> <br> Please note that it will probably be impossible for a single individual to both participate in the Interop and still be able to participate at all in the TC meetings of hte Roundtable simply due to the simultaneous nature of the events.<br> </div> <div> </div> <div> </div> <div><strong>REGISTRATION FEE</strong></div> <div> </div> <div><b>Interop:</b> $1500 for Consortium members and $2500 for non-members. The registration fee covers two individuals; additional individuals are $275 each for members or non-members. (If you are planning to participate in more than one Interop scenario, or participate in all the TC meetings, you will need more than one person and possibley more than two.)</div> <div> </div> <div><strong></strong>The Interop Registration Fee also covers participation in the Consortium Roundtable for members or declared observers.</div> <div> <br> <b>Roundtable:</b> $275 per individual until 15 May and $325 thereafter. Registration for the Roundtable does <b>not</b> include Interop participation.<br> </div> <div> </div> <div> </div> <div><strong>HOW TO REGISTER AND FURTHER INFORMATION</strong></div> <div> </div> <div>Logistics, registration and other information may be found on the Consortium Website: see <a class="moz-txt-link-freetext" href="http://www.calconnect.org">http://www.calconnect.org</a> and go to the Coming Events area; see "Roundtable III" and "Jun 2005 Interop".<br> </div> <div> </div> <div>For questions or more information, or to inform us of your plan to participate in the Interop, please contact me at the Consortium. Plan to register as soon as possible to ensure we will have room.<br> <br> </div> <div> </div> <div>Best Regards,</div> <div> </div> <div>Dave Thewlis</div> <div>Executive Director</div> <div>The Calendaring and Scheduling Consortium</div> <div> <div>1550 Dena Drive</div> <div>McKinleyville CA 95519-4146</div> <div>+1 707 840 9391 (voice)</div> <div>+1 415 946 3454 (fax)</div> <div>+1 707 498 2238 (mobile)</div> <div><a href="mailto:Dave.Thewlis@calconnect.org">Dave.Thewlis@calconnect.org</a></div> <div><a href="http://www.calconnect.org">www.calconnect.org</a></div> </div> . </body> </html> X-Envelope-From: tantek@technorati.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from mail.technorati.com (mail.technorati.com [209.237.227.245]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3H95Naa003880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 17 Apr 2005 02:05:23 -0700 Received: from [10.0.1.35] (pool-71-104-124-145.lsanca.dsl-w.verizon.net [71.104.124.145]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.technorati.com (Postfix) with ESMTP id D3BCD21282A for <ietf-calsify@osafoundation.org>; Sun, 17 Apr 2005 02:06:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <08a57bbe4b5f961dbac758b300dbe47f@technorati.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed To: Calsify <ietf-calsify@osafoundation.org> From: =?ISO-8859-1?Q?Tantek_=C7elik?= <tantek@technorati.com> Date: Sun, 17 Apr 2005 02:05:17 -0700 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j3H95Naa003880 Subject: [Ietf-calsify] Lawmakers pass bill switching Indiana to DST X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 17 Apr 2005 09:05:24 -0000 With all this discussion of the problems that DST presents to calendaring apps and formats, I figured this article was of relevance to the group. I wonder how many CUAs will now break in Indiana. And I had no idea how bad it was either: "77 counties in the Eastern time zone do not change clocks while five others do. The state also has 10 counties in the Central time zone that do observe daylight savings time." Yikes. Tantek -- Tantek Çelik Senior Technologist, Technorati, Inc. tantek@technorati.com -------------------------------------------------------------- Begin forwarded message (emailed using Yahoo's email article service). Lawmakers Pass Bill Over Indiana Time http://story.news.yahoo.com/news?tmpl=story&u=/ap/indiana_time_warp Sat Apr 16, 2:56 PM ET By MIKE SMITH, Associated Press Writer INDIANAPOLIS - Indiana, one of the nation's last holdouts for observing daylight-saving time, may be on the brink of changing its clocks. For the first time in more than two decades, the Indiana House has passed a bill that would require the entire state to move its clocks forward an hour in April and back an hour in October just as 47 other states do. Knowing just what time it is on a trip through Indiana is no easy task: 77 counties in the Eastern time zone do not change clocks while five others do. The state also has 10 counties in the Central time zone that do observe daylight savings time. Gov. Mitch Daniels has made mending the split a top priority saying the time warp costs the state money and jobs. Businesses say it causes mix-ups over airline flights, delivery times and conference calls. "If it were just a matter of the rest of the world laughing at us, I'd say let 'em laugh," Daniels said in his first State of the State speech in January. "But the loss of Hoosier jobs and incomes is no laughing matter, and any step that might help is worth trying." Bill Blomquist, a political science professor at Indiana University-Purdue University at Indianapolis, said Indiana's resistance to changing its clocks is rooted in states' rights issues, beliefs that humans should not alter time, and a sense of pride in doing things differently. "There is sort of this Hoosier exceptionalism that shows up in daylight-saving time," he said. A House-Senate committee will take up the bill Monday, but there are still some roadblocks. Some residents still adamantly oppose the proposed change, and lawmakers have to pick a time zone and determine when to make the change later this year or next April. Darrell Bowden, of Westfield, a suburb north of Indianapolis, thinks things are fine the way they are. "I don't like changing my clocks twice a year," he said. "The way I look at it, why doesn't the rest of the country get in step with us?" Bowden is in the minority, according to a recent statewide poll by The Indianapolis Star/WTHR. The poll found 56 percent favored daylight-saving time, while 37 percent opposed it. Mark Plank of Syracuse, in northeastern Indiana, used to work for an office furniture supplier and said confusion over Indiana's time cost the company customers. But he has personal reasons for backing the change, too. Observing daylight savings would give his kids an extra hour of sunlight to play "and give me more time to do yard work in the evenings." X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3GJhuaa028367 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sat, 16 Apr 2005 12:43:57 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3GJhlfh026938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 16 Apr 2005 12:43:51 -0700 Message-ID: <42616AF2.2000102@Royer.com> Date: Sat, 16 Apr 2005 13:43:46 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calsify <ietf-calsify@osafoundation.org> Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal References: <425EF690.8020304@Royer.com> <200504152129.12700.reinhold@kainhofer.com> <426026D3.7020906@Royer.com> <200504152332.37311.reinhold@kainhofer.com> <426043B5.6060307@Royer.com> <16993.25585.208298.744989@cnr.cs.columbia.edu> In-Reply-To: <16993.25585.208298.744989@cnr.cs.columbia.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090109010108080207020501" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify <ietf-calsify@osafoundation.org> List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sat, 16 Apr 2005 19:43:59 -0000 This is a cryptographically signed message in MIME format. --------------ms090109010108080207020501 Content-Type: multipart/mixed; boundary="------------020106070500060201070403" This is a multi-part message in MIME format. --------------020106070500060201070403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > On Friday, April 15 2005, "Doug Royer" wrote to "Calsify" saying: > >>Editing the relevant part of my proposal it would become: >> >>To find the end time for an appointment, (DTSTART/DURATION >>or RDATE/PERIOD-start): >> >> For 'wW' - add 'w*7' days to the 'date' part in its original TZ >> 'dD' - add 'd' days to the 'date' part in its original TZ >> 'hH' - add 'h' hours to the 'time' part in its original TZ >> 'mM' - add 'm minutes to the 'time' part in its original TZ >> 'sS' - add 's' seconds to the 'time' part in its original TZ >> >> Normalize the date (wrap seconds, minutes, hours, date, month, >> when needed). > > > I think this isn't what people are saying, or at least it needs to be > explained better -- 'in its original TZ' is ambiguous. It's correct for h, > m, and s, but w and d should add to the 'date' part, *leaving the time part > untouched*. > > Many time packages, if you start with (e.g.) 2005-04-01 00:00:00 EST, and > add 7 to the date field (generating 2005-04-08 00:00:00 EST), and normalize, > will give 2005-04-08 01:00:00 EDT. Yes, this is exactly where all of the problems come from. We need to nail down exactly what and how to say how to do that time math. These should work in any TZ. Given 2005-04-01 23:59:59 with 1D 1S Add 1D gives: 2005-04-02 23:59:59 Then add 1S should result in. 2005-04-03 00:00:00 - correct ? That is what I meant when I said 'normalize' - adjust up as you add the lower elements of time. I did not mean readjust for TZID. Given: 2005-04-01 23:59:59 with 1W Add 1W gives: 2004-04-08 23:59:59 If we agree - I'll make it clear in the doc. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020106070500060201070403 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020106070500060201070403-- --------------ms090109010108080207020501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE2MTk0MzQ2WjAjBgkqhkiG9w0BCQQxFgQU+O2WOV9/w2HhE/F2xonM /7o1+aUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAafmGjPRucUYTqSQVOSaKH7jO2KhZFPz5tiE3Ow5mPP1sjHIbnBx57dsfXkt0T5VF t1W2R+uZ/NYMRGvCdsgEEsrxXd5npuGEWKWHl2i/UcmFMrLJUJDN70E/O7Szvt6EOwOZqjxP ibMfolu+IrthM5y/sUYt3BkVlRTe8dFVn2QVdSIFv+8O4ckMiwh64zjAOYeybKGAmGZzyKNW SnvMwYhNZ2UC6zLeU5Foawe0yRtYnnbj6/iT/EM61K8z/Y57vVg0Xw7yZ5xx/+oSG7/8LgTd wEFirWIUn/Yv0r6H0V+x8YNVjLiZmo3NbZvRW92qKvgWceA3AAp913ZeX8Y2/QAAAAAAAA== --------------ms090109010108080207020501-- X-Envelope-From: lennox@cnr.cs.columbia.edu X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3GJDsaa023077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 16 Apr 2005 12:13:55 -0700 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j3GJDrA5010609 for <ietf-calsify@osafoundation.org>; Sat, 16 Apr 2005 15:13:53 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j3GJDrED010606; Sat, 16 Apr 2005 15:13:53 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16993.25585.208298.744989@cnr.cs.columbia.edu> Date: Sat, 16 Apr 2005 15:13:53 -0400 To: Calsify <ietf-calsify@osafoundation.org> Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal In-Reply-To: <426043B5.6060307@Royer.com> References: <425EF690.8020304@Royer.com> <200504152129.12700.reinhold@kainhofer.com> <426026D3.7020906@Royer.com> <200504152332.37311.reinhold@kainhofer.com> <426043B5.6060307@Royer.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sat, 16 Apr 2005 19:13:56 -0000 On Friday, April 15 2005, "Doug Royer" wrote to "Calsify" saying: > Editing the relevant part of my proposal it would become: > > To find the end time for an appointment, (DTSTART/DURATION > or RDATE/PERIOD-start): > > For 'wW' - add 'w*7' days to the 'date' part in its original TZ > 'dD' - add 'd' days to the 'date' part in its original TZ > 'hH' - add 'h' hours to the 'time' part in its original TZ > 'mM' - add 'm minutes to the 'time' part in its original TZ > 'sS' - add 's' seconds to the 'time' part in its original TZ > > Normalize the date (wrap seconds, minutes, hours, date, month, > when needed). I think this isn't what people are saying, or at least it needs to be explained better -- 'in its original TZ' is ambiguous. It's correct for h, m, and s, but w and d should add to the 'date' part, *leaving the time part untouched*. Many time packages, if you start with (e.g.) 2005-04-01 00:00:00 EST, and add 7 to the date field (generating 2005-04-08 00:00:00 EST), and normalize, will give 2005-04-08 01:00:00 EDT. The important difference here is that when you add W and D, you add to the date field and then calculate the appropriate TZ offset; when you add H, M, or S you add to the time field and then *adjust the time part* for the appropriate offset. This means that PT8H always means 8 actual hours, not "add 8 to the hour field." This needs word-smithing for the standard; I don't feel like I've explained this very well. > Does order of addition matter ? I don't think so, I have to think about > that. Or do they need to be normalized as added? Start with 'S', then > 'M', 'H', 'D' ? I agree with Reinhold that it should be largest-component-first, i.e. start with 'W'. I believe this is equivalent to (W and D), (H and M), and (S), with (S) only needing to be separated if you're handling leap seconds, since weeks are always a constant number of days and hours are always a constant number of minutes. -- Jonathan Lennox lennox at cs dot columbia dot edu X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FNqCaa028782 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 16:52:14 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3FNq7u5015598 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 16:52:09 -0700 Message-ID: <426053A7.3090206@Royer.com> Date: Fri, 15 Apr 2005 17:52:07 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calsify <ietf-calsify@osafoundation.org> Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal References: <425EF690.8020304@Royer.com> <200504152332.37311.reinhold@kainhofer.com> <426043B5.6060307@Royer.com> <200504160111.09358.reinhold@kainhofer.com> In-Reply-To: <200504160111.09358.reinhold@kainhofer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050607000107040207010204" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify <ietf-calsify@osafoundation.org> List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 23:52:16 -0000 This is a cryptographically signed message in MIME format. --------------ms050607000107040207010204 Content-Type: multipart/mixed; boundary="------------020109060900050005080700" This is a multi-part message in MIME format. --------------020109060900050005080700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ok, I can live with that definition. And we will just have to learn which PRODID's use the 'D' fixed to 24 hours when we read a pre-CALSIFY objects. Reinhold Kainhofer wrote: > Am Samstag, 16. April 2005 00:44 schrieb Doug Royer: > >>So: +PT1DT2H would be add 1 to the 'date' part, plus 2 hours ? >> >>Editing the relevant part of my proposal it would become: >> >>To find the end time for an appointment, (DTSTART/DURATION >>or RDATE/PERIOD-start): >> >> For 'wW' - add 'w*7' days to the 'date' part in its original TZ >> 'dD' - add 'd' days to the 'date' part in its original TZ >> 'hH' - add 'h' hours to the 'time' part in its original TZ >> 'mM' - add 'm minutes to the 'time' part in its original TZ >> 'sS' - add 's' seconds to the 'time' part in its original TZ >> >> Normalize the date (wrap seconds, minutes, hours, date, month, >> when needed). >> >>Does order of addition matter ? I don't think so, I have to think about >>that. > > > Order does matter. In particular, there's a difference if a time zone shift > happens during the D part (in which case it's basically ignored) or during > the H part. > > E.g. take a DTSTART at 01:00 CET (00:00 UTC) on March 27, 2005 (DST begins on > March 27), and a DURATION of P1DT6H. > -) If you first add the one day, you have 01:00 CEST on March 28, plus 6H > gives 07:00 CEST on March 28. > -) If you first add the six hours, you'll have 08:00 CEST (since the hour from > 02:00 to 03:00 is skipped). If you then add one day, you'll end up with 08:00 > CEST on March 28. > > Intuitively, I'd first add the larger interval. I.e. first add the W, then the > D, then the H, M and S parts of the duration. > > >>Or do they need to be normalized as added? Start with 'S', then >>'M', 'H', 'D' ? > > > I'd say the other order. > > Reinhold > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020109060900050005080700 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020109060900050005080700-- --------------ms050607000107040207010204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE1MjM1MjA3WjAjBgkqhkiG9w0BCQQxFgQULKzR7CmipH+o9RXTCrci QlpLHqYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAfhfoiJNiyfwJCOTMIi7aMH4/2z0dLWN/STdNqU5Hr8KgKwpV/kPHTuU81lIHT0S4 bOjSrQOCcq04Iaiu3F+z0wG4a1+AVoQUmWzNkF5oMHSeyBGUnYCiqk9jnGL7/CD6eRdZiEKS 6zdbV8/O+TRtAUlaVADiUZbVAIIpaljFVFYsHWPqXLfINGDal9Fgb4f52wNztXjYvc2HyYnG K7yIahRakN4hhZ1eIhtTaO2PdV2Fr+wbqUwAefNbSBqIX9+H+de6wJCG2+LnLSLMf0NQuRyR kLT2MN7XTG9MhhQf8nWubRGh9ssmygP1XxP1oE2yeM3gnsjVs0G1hdIh1pXZDAAAAAAAAA== --------------ms050607000107040207010204-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FNBCaa024374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 16:11:14 -0700 Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3FNBBap010505 for <ietf-calsify@osafoundation.org>; Sat, 16 Apr 2005 01:11:12 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: Calsify <ietf-calsify@osafoundation.org> Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal Date: Sat, 16 Apr 2005 01:11:06 +0200 User-Agent: KMail/1.8 References: <425EF690.8020304@Royer.com> <200504152332.37311.reinhold@kainhofer.com> <426043B5.6060307@Royer.com> In-Reply-To: <426043B5.6060307@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3848868.K4LTYAAvLg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504160111.09358.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 23:11:15 -0000 --nextPart3848868.K4LTYAAvLg Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Samstag, 16. April 2005 00:44 schrieb Doug Royer: > So: +PT1DT2H would be add 1 to the 'date' part, plus 2 hours ? > > Editing the relevant part of my proposal it would become: > > To find the end time for an appointment, (DTSTART/DURATION > or RDATE/PERIOD-start): > > For 'wW' - add 'w*7' days to the 'date' part in its original TZ > 'dD' - add 'd' days to the 'date' part in its original TZ > 'hH' - add 'h' hours to the 'time' part in its original TZ > 'mM' - add 'm minutes to the 'time' part in its original TZ > 'sS' - add 's' seconds to the 'time' part in its original TZ > > Normalize the date (wrap seconds, minutes, hours, date, month, > when needed). > > Does order of addition matter ? I don't think so, I have to think about > that. Order does matter. In particular, there's a difference if a time zone shift= =20 happens during the D part (in which case it's basically ignored) or during= =20 the H part.=20 E.g. take a DTSTART at 01:00 CET (00:00 UTC) on March 27, 2005 (DST begins = on=20 March 27), and a DURATION of P1DT6H.=20 =2D) If you first add the one day, you have 01:00 CEST on March 28, plus 6H= =20 gives 07:00 CEST on March 28. =2D) If you first add the six hours, you'll have 08:00 CEST (since the hour= from=20 02:00 to 03:00 is skipped). If you then add one day, you'll end up with 08:= 00=20 CEST on March 28. Intuitively, I'd first add the larger interval. I.e. first add the W, then = the=20 D, then the H, M and S parts of the duration. > Or do they need to be normalized as added? Start with 'S', then=20 > 'M', 'H', 'D' ? I'd say the other order. Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart3848868.K4LTYAAvLg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCYEoNTqjEwhXvPN0RAtcJAJ48DEC7gSFlj03RzkJBZSsVV+gkHQCfeduD SToA+ha6pVjD4Ja/FXHEBT8= =5kr2 -----END PGP SIGNATURE----- --nextPart3848868.K4LTYAAvLg-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FMiGaa022677 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 15:44:19 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3FMi6Pd014854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 15:44:08 -0700 Message-ID: <426043B5.6060307@Royer.com> Date: Fri, 15 Apr 2005 16:44:05 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calsify <ietf-calsify@osafoundation.org> Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal References: <425EF690.8020304@Royer.com> <200504152129.12700.reinhold@kainhofer.com> <426026D3.7020906@Royer.com> <200504152332.37311.reinhold@kainhofer.com> In-Reply-To: <200504152332.37311.reinhold@kainhofer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020504060809040707030604" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify <ietf-calsify@osafoundation.org> List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 22:44:25 -0000 This is a cryptographically signed message in MIME format. --------------ms020504060809040707030604 Content-Type: multipart/mixed; boundary="------------020105020104020606050704" This is a multi-part message in MIME format. --------------020105020104020606050704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reinhold Kainhofer wrote: > Am Freitag, 15. April 2005 22:40 schrieb Doug Royer: > >>With 2445 rules, 2:30 or 1:30 could be the correct answer. >> >>So, again, lets deprecate 'D' and the Organizer can set >>the explicit real duration of when the Attendee should >>think that it is over. The Organizer is free to remember >>in its own cal-store that it means 'day' and not '##S', >>'##M', or '##H'. > > > I think 1D is exactly the solution to the two different meanings of "one day", > which I elaborated in my previous mail. If you want to ensure that the event > always lasts 24 hours (and possibly has a different end time), use PT24H. If > you want the event to end exactly at the same time on the next day (and > possibly has a different duration), use P1DT. In the latter case the TZ of > the event is also relevant. Okay, I think I missed that point. thanks for your patience :-) So: +PT1DT2H would be add 1 to the 'date' part, plus 2 hours ? Editing the relevant part of my proposal it would become: To find the end time for an appointment, (DTSTART/DURATION or RDATE/PERIOD-start): For 'wW' - add 'w*7' days to the 'date' part in its original TZ 'dD' - add 'd' days to the 'date' part in its original TZ 'hH' - add 'h' hours to the 'time' part in its original TZ 'mM' - add 'm minutes to the 'time' part in its original TZ 'sS' - add 's' seconds to the 'time' part in its original TZ Normalize the date (wrap seconds, minutes, hours, date, month, when needed). Does order of addition matter ? I don't think so, I have to think about that. Or do they need to be normalized as added? Start with 'S', then 'M', 'H', 'D' ? As an attendee I want to know when that is on my local wall clock. So convert (for each of start and end time), the time to UTC then to my TZ. Is this what your are saying? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020105020104020606050704 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020105020104020606050704-- --------------ms020504060809040707030604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE1MjI0NDA1WjAjBgkqhkiG9w0BCQQxFgQUIyjbXkKgiLwZzwXtSK+Q 0ItSxJcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAfAEVfpd2IjhMonmTZileKPB46f6JQHtNnFjC4tI8f7INYurep0ZClRbD29VpX7G8 IyRY0BzuJ+rele9P+83fSOOD/i9clcv0eZ6b3ZIfjvvvCw5owon3zCAxecMTQM44OO4bJfvI /1jEi1mDqRbFVJ7nsy2MzjQoYPHcVxC8wvxUxn3YAxn+tt4OWobcmHuesHWt9/yRFUPz2vbO V8lNhxyTGa3HWXzYEFQB1kdeEj7hp9lU75ZsBnrNbKeMB6FIji8Nd7ukyh9dwJqtaxu4BOIO rxUfeI7EsbBYXOtIxs1cau1sUVHIldNyDs7yxPz9RdEXbK45J2CyFXAX8xFwIAAAAAAAAA== --------------ms020504060809040707030604-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FLWfaa017954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 14:32:42 -0700 Received: from ip6-localhost (doob.fam.tuwien.ac.at [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3FLWegT006168 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 23:32:40 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: Calsify <ietf-calsify@osafoundation.org> Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal Date: Fri, 15 Apr 2005 23:32:35 +0200 User-Agent: KMail/1.8 References: <425EF690.8020304@Royer.com> <200504152129.12700.reinhold@kainhofer.com> <426026D3.7020906@Royer.com> In-Reply-To: <426026D3.7020906@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1933131.6x2V84qrrv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504152332.37311.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 21:32:44 -0000 --nextPart1933131.6x2V84qrrv Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 15. April 2005 22:40 schrieb Doug Royer: > With 2445 rules, 2:30 or 1:30 could be the correct answer. > > So, again, lets deprecate 'D' and the Organizer can set > the explicit real duration of when the Attendee should > think that it is over. The Organizer is free to remember > in its own cal-store that it means 'day' and not '##S', > '##M', or '##H'. It's also the attendee that needs this meta-information, e.g. for=20 counter-proposals. Take a hospital where the 24h-shifts (they're called "24h", although they a= re=20 really 1D events, which last until the same time on the next day, typically= =20 from 8am until 8am on the next day, even across DST switches) are organized= =20 with iCal and iTIP.=20 The manager plans one doctor's shift on March 26, 2005, 8am CET until March= =20 27, 8am CEST (duration is 23 hours). He sends out the object, but the docto= r=20 can't take that shift, moves it one day (March 27, 8am CEST until March 28,= =20 7am CEST) and sends back that shift. Since the duration of the original eve= nt=20 was 23 hours (as opposed to 1D, which you want to remove), the=20 counter-proposal also has only 23 hours, although the shift would really ha= ve=20 23 hours. Thus, there will be one hour in the hospital's timetable without = a=20 doctor. I think 1D is exactly the solution to the two different meanings of "one da= y",=20 which I elaborated in my previous mail. If you want to ensure that the even= t=20 always lasts 24 hours (and possibly has a different end time), use PT24H. I= f=20 you want the event to end exactly at the same time on the next day (and=20 possibly has a different duration), use P1DT. In the latter case the TZ of= =20 the event is also relevant.=20 To me PT24H means: Use time arithmetic to calculate the end, and P1DT means= :=20 Use date arithmetic and leave the time untouched (if possible). We just need to make sure to clearly mention that in the standard (and solv= e=20 the border-line cases when an invalid/non-existent or duplicate end time=20 would result. Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart1933131.6x2V84qrrv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCYDL1TqjEwhXvPN0RAsbwAKCa4fK1HxZMf1V43lJ4V91e0y7KpwCeJwAs iebMue3sW+Dt+7bB4OMkumg= =RqQf -----END PGP SIGNATURE----- --nextPart1933131.6x2V84qrrv-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FKewaa014251 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 13:41:00 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3FKeq6r013493 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 13:40:55 -0700 Message-ID: <426026D3.7020906@Royer.com> Date: Fri, 15 Apr 2005 14:40:51 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calsify <ietf-calsify@osafoundation.org> Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal References: <425EF690.8020304@Royer.com> <200504152047.21396.reinhold@kainhofer.com> <42600E1C.8070909@Royer.com> <200504152129.12700.reinhold@kainhofer.com> In-Reply-To: <200504152129.12700.reinhold@kainhofer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050800060408060104050001" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify <ietf-calsify@osafoundation.org> List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 20:41:02 -0000 This is a cryptographically signed message in MIME format. --------------ms050800060408060104050001 Content-Type: multipart/mixed; boundary="------------030905030701080408020107" This is a multi-part message in MIME format. --------------030905030701080408020107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reinhold Kainhofer wrote: > Am Freitag, 15. April 2005 20:55 schrieb Doug Royer: > >>Which is why I showed converting it back to the users local time zone. >> >>And it matches what the user expected. >> >>Show an example that fails when you do the conversion to UTC, then >>the duration math, then the conversion back to the TZID. > > > Take an event in CET (DST starts on March 27, 2005) that starts at 01:30 CET > on March 27 and lasts one day. The user expects this to end at 01:30 CEST on > March 28. > > Now do the math in UTC. The event starts at 00:30 UTC on March 27 and so ends > at 00:30 UTC on March 28. That time, however, is 02:30 in the user's new time > zone. So in this option, the event ends at 02:30 CEST on March 28, while the > user expects it to end at 01:30. With 2445 rules, 2:30 or 1:30 could be the correct answer. So, again, lets deprecate 'D' and the Organizer can set the explicit real duration of when the Attendee should think that it is over. The Organizer is free to remember in its own cal-store that it means 'day' and not '##S', '##M', or '##H'. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------030905030701080408020107 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------030905030701080408020107-- --------------ms050800060408060104050001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE1MjA0MDUxWjAjBgkqhkiG9w0BCQQxFgQUuyhvM0vaulMvN1tSYGG4 YDkUmHowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAlV22Vauq1lZhsY03KpxeMhuIxfzB8Fd8ZuNEwrFfbDtU0pWOeO+8n8gX41BQapT/ vO2PAcWqNu5CsaSI6F1UzYjfmoWCk8r+eP87B8jpIRmM4P36jBKG4Hge4HqFs6fMyR0FVuxU SZQAItlmYKOVb/rnQXe6Qu1MSU1BDeN8OI6r/F32zRGMnzjn8xyDB3joB5GwiuBn3BD9XRfP i/kOCjvFIMo/LYoXG+OhIvbPFOaUoEh6uRHF9qpnQAPixpRsaWZQBG4yTC3GNjNHZ80OFdGZ i4agFN6dfVWTZT6UsuB7yDStoBYXXPXHeT8kDQ8UGZkItFUHierz0aRRs3+hVwAAAAAAAA== --------------ms050800060408060104050001-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FKXYaa013772 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 13:33:35 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3FKXQ9x013384 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 13:33:30 -0700 Message-ID: <42602516.1060601@Royer.com> Date: Fri, 15 Apr 2005 14:33:26 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal References: <425EF690.8020304@Royer.com> <200504152025.09567.reinhold@kainhofer.com> <4260085D.5050508@Royer.com> <200504152047.21396.reinhold@kainhofer.com> <42600E1C.8070909@Royer.com> <d3p3q2$obt$1@sea.gmane.org> In-Reply-To: <d3p3q2$obt$1@sea.gmane.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090606000704060607060902" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 20:33:38 -0000 This is a cryptographically signed message in MIME format. --------------ms090606000704060607060902 Content-Type: multipart/mixed; boundary="------------080606050507010507000303" This is a multi-part message in MIME format. --------------080606050507010507000303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michiel van Leeuwen wrote: > Doug Royer wrote: > >> Show an example that fails when you do the conversion to UTC, then >> the duration math, then the conversion back to the TZID. > > > in javascript: > > js> d=new Date("March 27, 2005 0:0:0"); > Sun Mar 27 2005 00:00:00 GMT+0100 (CET) > js> d.setUTCDate(d.getUTCDate()+1); > 1111964400000 > js> d > Mon Mar 28 2005 01:00:00 GMT+0200 (CEST) > > In other words, the end date is not 00:00 anymore, like the user would > expect. How about an iCal example? I do very littls javascript programming.\ -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------080606050507010507000303 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------080606050507010507000303-- --------------ms090606000704060607060902 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE1MjAzMzI2WjAjBgkqhkiG9w0BCQQxFgQUQ0UW/CiAcg7wmK0apVsE +fSfnVEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAJZv0VWBajB27vTDicrrqGLtonp1gL3F9G3eaMWEI8lf06R3oAA2wGm1GtsVghMPJ tvsk/3qzbrWppSiJISAkb9HCq+Xo4V/sxv72smyxzau0s0mgarXXGYKC8Y2dHbMO0Nw1XDy9 DK89yPJBr24KOcDGmvhmqfCcAVaq8bYKd3EaMQpcclsRrynbOc+hGLTCsyVq5uAoRdKS+9NB bMKcGMqTeVWHAjcKzq6K7qFMtWVQa0QJjrEYUEJgKc03zjzBGsOIs5HdwIpxLnA7gA2mgu0b BF0J4qxwfjtL99x+sAxbgXzDr8zRNiNHJ3Zq+saYp1S5xkK9hS7vA/VzrM4Z2AAAAAAAAA== --------------ms090606000704060607060902-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FJTGaa008369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 12:29:18 -0700 Received: from ip6-localhost (doob.fam.tuwien.ac.at [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3FJTFkL030357 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 21:29:15 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: Calsify <ietf-calsify@osafoundation.org> Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal Date: Fri, 15 Apr 2005 21:29:10 +0200 User-Agent: KMail/1.8 References: <425EF690.8020304@Royer.com> <200504152047.21396.reinhold@kainhofer.com> <42600E1C.8070909@Royer.com> In-Reply-To: <42600E1C.8070909@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1323657.Ar5Lr5Gax4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504152129.12700.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 19:29:21 -0000 --nextPart1323657.Ar5Lr5Gax4 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 15. April 2005 20:55 schrieb Doug Royer: > Which is why I showed converting it back to the users local time zone. > > And it matches what the user expected. > > Show an example that fails when you do the conversion to UTC, then > the duration math, then the conversion back to the TZID. Take an event in CET (DST starts on March 27, 2005) that starts at 01:30 CE= T=20 on March 27 and lasts one day. The user expects this to end at 01:30 CEST o= n=20 March 28. Now do the math in UTC. The event starts at 00:30 UTC on March 27 and so en= ds=20 at 00:30 UTC on March 28. That time, however, is 02:30 in the user's new ti= me=20 zone. So in this option, the event ends at 02:30 CEST on March 28, while th= e=20 user expects it to end at 01:30. Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart1323657.Ar5Lr5Gax4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCYBYITqjEwhXvPN0RAsTzAJ4gRRpPgZTUOY1LoSXt7BmcTzH9rACgoXzn l+PEQKWsGzjmctSMqlMsJ4Q= =AKtK -----END PGP SIGNATURE----- --nextPart1323657.Ar5Lr5Gax4-- X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FJKAaa007585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 12:20:12 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DMWHX-0002uE-JO for ietf-calsify@osafoundation.org; Fri, 15 Apr 2005 21:15:11 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 21:15:11 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 21:15:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Fri, 15 Apr 2005 21:17:47 +0200 Lines: 24 Message-ID: <d3p3q2$obt$1@sea.gmane.org> References: <425EF690.8020304@Royer.com> <200504152025.09567.reinhold@kainhofer.com> <4260085D.5050508@Royer.com> <200504152047.21396.reinhold@kainhofer.com> <42600E1C.8070909@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050414 In-Reply-To: <42600E1C.8070909@Royer.com> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: DURATION and PERIOD - proposal X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 19:20:13 -0000 Doug Royer wrote: > Show an example that fails when you do the conversion to UTC, then > the duration math, then the conversion back to the TZID. in javascript: js> d=new Date("March 27, 2005 0:0:0"); Sun Mar 27 2005 00:00:00 GMT+0100 (CET) js> d.setUTCDate(d.getUTCDate()+1); 1111964400000 js> d Mon Mar 28 2005 01:00:00 GMT+0200 (CEST) In other words, the end date is not 00:00 anymore, like the user would expect. > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: Doug@Royer.com Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FIxWaa006011 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Fri, 15 Apr 2005 11:59:38 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3FIxKpc012087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 15 Apr 2005 11:59:22 -0700 Message-ID: <42600F08.3090603@Royer.com> Date: Fri, 15 Apr 2005 12:59:20 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-calendar@imc.org" <ietf-calendar@imc.org>, Calsify <ietf-calsify@osafoundation.org>, CalDAV DevList <ietf-caldav@osafoundation.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050803010100090309050007" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Subject: [Ietf-calsify] Document Action: 'Calendar Access Protocol (CAP)' to Experimental RFC X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: "ietf-calendar@imc.org" <ietf-calendar@imc.org> List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 18:59:40 -0000 This is a cryptographically signed message in MIME format. --------------ms050803010100090309050007 Content-Type: multipart/mixed; boundary="------------090107000606060801060006" This is a multi-part message in MIME format. --------------090107000606060801060006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit It has taken forever - it is on it way!! From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Date: Fri, 15 Apr 2005 13:15:42 -0400 Subject: Document Action: 'Calendar Access Protocol (CAP)' to Experimental RFC The IESG has approved the following document: - 'Calendar Access Protocol (CAP) ' <draft-royer-calsch-cap-02.txt> as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ted Hardie. IANA Note: This draft includes registrations under RFC 2445, section 7.1; these are the first registrations of that type, and a registry will be needed for them. The author of this specification, as well as the original authors of RFC 2445 should be consulted as to its form. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------090107000606060801060006 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------090107000606060801060006-- --------------ms050803010100090309050007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE1MTg1OTIwWjAjBgkqhkiG9w0BCQQxFgQU9sGhz3WE9M3eMlqIsCLG MKgtj6wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAL1d1aAhHOPMeQhT50+E45knuJgWaf7iQa/bkVzsTTQ7wNi1xAljKYHrGg9wwpXSd UTb6aNM2XwdlEakACddicL6iUE0HS3dYc2iQGW9gANj1qd8s8o6RVRmpuJoIkiOgJl4t2ReB eoVSW6BwYpG3Az0yWNYjM5cbP4+8yRGenJO7QOh//4tqAlDTVSStfWG6IjYLXh7Jwk8w4AMq yp7oJFD6/BayslM3/qcP5kcc/RWvIokgvgGz3ACemNjmWuRR1DYcfLMyt0pStTJg0vuCEJmp FoSBCkpDmV5TXVBzcXCREVHiZt3GU1kE9veJcXHdHKz4CCPiSirZXSg65Wf7twAAAAAAAA== --------------ms050803010100090309050007-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FItVaa005683 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 11:55:33 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3FItOPe012054 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 11:55:28 -0700 Message-ID: <42600E1C.8070909@Royer.com> Date: Fri, 15 Apr 2005 12:55:24 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calsify <ietf-calsify@osafoundation.org> Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal References: <425EF690.8020304@Royer.com> <200504152025.09567.reinhold@kainhofer.com> <4260085D.5050508@Royer.com> <200504152047.21396.reinhold@kainhofer.com> In-Reply-To: <200504152047.21396.reinhold@kainhofer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040305080007040508040008" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify <ietf-calsify@osafoundation.org> List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 18:55:35 -0000 This is a cryptographically signed message in MIME format. --------------ms040305080007040508040008 Content-Type: multipart/mixed; boundary="------------010507040005090205010201" This is a multi-part message in MIME format. --------------010507040005090205010201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reinhold Kainhofer wrote: > Am Freitag, 15. April 2005 20:30 schrieb Doug Royer: > >>Reinhold Kainhofer wrote: >> >>>>Finish reading that email. It addressed that issue. >>> >>>No, you basically say that 1D should always mean 24H. And you also say >>>that if the user expects the event to end at the same time on the next >>>day in his timezone, the user's expectations are wrong... >> >>I said no such thing and I have no clue why you think I did. > > > Implicitly, see below. > > >>I said when you do the math in UTC - everything works. A day >>is never 25 or 23 hours, > > > Huh? Sure, for me (as a user) March 27, 2004, is only 23 hours long (in Europe > where DST starts at that date). I did NOT say that a DST day is always 24 hours. I said a UTC day is always 24 hours. > You say that by definition a day is 24 hours, and from this, of course the end > time is not always the same. > The user, however, thinks differently (see below). For a typical user 1D means > same time on the next day. Now you say, that the result with the 24 hours > duration is always correct, and although the user understands a duration of 1 > day differently and expects a different result. Which is why I showed converting it back to the users local time zone. And it matches what the user expected. Show an example that fails when you do the conversion to UTC, then the duration math, then the conversion back to the TZID. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------010507040005090205010201 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------010507040005090205010201-- --------------ms040305080007040508040008 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE1MTg1NTI0WjAjBgkqhkiG9w0BCQQxFgQUy5uta6ygUkyJpatvKhFP 7q3DEqowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAXENeO5Tbti1UK11BvX+j1qgccsVzo+Yy6i1Awg/YmJdidvuNxGuzh8LKlc2dBm25 XwpJAEfXiP7DLeyStKiGEoAUVRomcyCN2iYn4x/dUU8J8GPvnj6asoQnVJnvQJSIaBAV1O7d xhFoUEtORZOAoHb9tRQNaMCEQH0NMZKJOv+y5KkVKE1RIOEkxLiagaU2MIGXfUUFqtrnqnM2 uNbB31G0RATH22oCeJNEKPnLgSyP3YlSfIKbIkZi5Mlccv7at8eu5zZo9tsC2cLgFtAITsOz eWQlkKyM8jXyPUhxLPSb4CY4zUUeF+US/dKDlYdXXoK1qYqLaUJu/RMFhJhIJAAAAAAAAA== --------------ms040305080007040508040008-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FIlPaa005116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 11:47:27 -0700 Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3FIlNA9026585 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 20:47:24 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal Date: Fri, 15 Apr 2005 20:47:19 +0200 User-Agent: KMail/1.8 References: <425EF690.8020304@Royer.com> <200504152025.09567.reinhold@kainhofer.com> <4260085D.5050508@Royer.com> In-Reply-To: <4260085D.5050508@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2665327.SZcoyjWxIq"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504152047.21396.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 18:47:28 -0000 --nextPart2665327.SZcoyjWxIq Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 15. April 2005 20:30 schrieb Doug Royer: > Reinhold Kainhofer wrote: > >>Finish reading that email. It addressed that issue. > > > > No, you basically say that 1D should always mean 24H. And you also say > > that if the user expects the event to end at the same time on the next > > day in his timezone, the user's expectations are wrong... > > I said no such thing and I have no clue why you think I did. Implicitly, see below. > I said when you do the math in UTC - everything works. A day > is never 25 or 23 hours,=20 Huh? Sure, for me (as a user) March 27, 2004, is only 23 hours long (in Eur= ope=20 where DST starts at that date). You say that by definition a day is 24 hours, and from this, of course the = end=20 time is not always the same.=20 The user, however, thinks differently (see below). For a typical user 1D me= ans=20 same time on the next day. Now you say, that the result with the 24 hours=20 duration is always correct, and although the user understands a duration of= 1=20 day differently and expects a different result. Basically, it boils down to two different definitions of one day. Does a=20 duration of 1 day mean: =2D) one day (same time, different date) in absolute time coordinates, but = not=20 necessarily in the time zone of the event? This definition is equivalent to= a=20 duration of 24 hours. The end time in the user's local time is not always t= he=20 same. =2D) one day (same time, different date) in the user's local time? The dura= tion=20 is not constant, but the end time is the same for all occurences. You think using the first definition, the user (intuitively) thinks in term= s=20 of the second definition. > it just appears that way when you=20 > look at a clock that was changed. Yes, but=20 1) the users think in time and date separated, so one day duration means:=20 Increase the date by one, leave the time untouched. 2) the user doesn't think in absolute time coordinates. Almost all users th= ink=20 relative to that clock, which was changed.=20 Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart2665327.SZcoyjWxIq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCYAw5TqjEwhXvPN0RAkUSAJoDG756hhpx1K3cgqOmFUcHZ9rW7QCgkDOz ea394MJjSAzPUcAGUvEBDto= =TEvb -----END PGP SIGNATURE----- --nextPart2665327.SZcoyjWxIq-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FIUwaa003836 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 11:30:59 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3FIUr5m011745 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 11:30:55 -0700 Message-ID: <4260085D.5050508@Royer.com> Date: Fri, 15 Apr 2005 12:30:53 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal References: <425EF690.8020304@Royer.com> <d3oufs$7gf$1@sea.gmane.org> <4260017B.80108@Royer.com> <200504152025.09567.reinhold@kainhofer.com> In-Reply-To: <200504152025.09567.reinhold@kainhofer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040502040509080308070409" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 18:31:01 -0000 This is a cryptographically signed message in MIME format. --------------ms040502040509080308070409 Content-Type: multipart/mixed; boundary="------------030306030009000906020407" This is a multi-part message in MIME format. --------------030306030009000906020407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reinhold Kainhofer wrote: >> >>Finish reading that email. It addressed that issue. > > > No, you basically say that 1D should always mean 24H. And you also say that if > the user expects the event to end at the same time on the next day in his > timezone, the user's expectations are wrong... I said no such thing and I have no clue why you think I did. I said when you do the math in UTC - everything works. A day is never 25 or 23 hours, it just appears that way when you look at a clock that was changed. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------030306030009000906020407 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------030306030009000906020407-- --------------ms040502040509080308070409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE1MTgzMDUzWjAjBgkqhkiG9w0BCQQxFgQUNYog/qM6CVguain09lrS DHfdbD8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEASESdVuurenAr8yjOEa7l4MaF0QsYgr73rdcXENadfMTQvvo0eAjkSZrXCp82nEKs smrTcAe0kHz22l9KjjFe1er+dkHRKLDdK0gXEVaoiNZTxRZ5ipeifUC1pxNsxEdGCbbYUuE0 Lne29VJQ+h7wxgy2uuV/XE039/RKmOcoCpm0vXsiEAJ7Gv8XPKrkYjAXh4QkBX7cMGhwAERS fl+UdijaLB7IgOmcEybL6e/WLzdIUXj0YR/OAjrSrXrz23YHbhiE8K7RIxAM/4OCg4SGwOG/ 42aiiTeo61uLZJCtT3JNCucWnxJP0zhF8VUxCgwfHNHahoNr55G9AKdgVlSLrwAAAAAAAA== --------------ms040502040509080308070409-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FIPIaa003411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 11:25:19 -0700 Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3FIPDWi025536 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 20:25:15 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal Date: Fri, 15 Apr 2005 20:25:09 +0200 User-Agent: KMail/1.8 References: <425EF690.8020304@Royer.com> <d3oufs$7gf$1@sea.gmane.org> <4260017B.80108@Royer.com> In-Reply-To: <4260017B.80108@Royer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504152025.09567.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 18:25:22 -0000 Am Freitag, 15. April 2005 20:01 schrieb Doug Royer: > Michiel van Leeuwen wrote: > > Doug Royer wrote: > >>> But as a user, i would expect that 1D means just that, one day. > >> > >> And it still means 1D. It just looks as if it does not when in > >> non-UTC TZ's. > > > > Given that almost everybody lives in a non-utc timezone, wouldn't that > > be the target you need to aim at? Make it usable in any timezone, not > > only in utc... > > Finish reading that email. It addressed that issue. No, you basically say that 1D should always mean 24H. And you also say that if the user expects the event to end at the same time on the next day in his timezone, the user's expectations are wrong... Reinhold -- ------------------------------------------------------------------ Reinhold Kainhofer, Vienna, 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 / KPilot maintainer X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FI1Zaa001870 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 11:01:39 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3FI1VKk011385 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 11:01:33 -0700 Message-ID: <4260017B.80108@Royer.com> Date: Fri, 15 Apr 2005 12:01:31 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal References: <425EF690.8020304@Royer.com> <d3nq3c$a82$1@sea.gmane.org> <425FFD48.5090908@Royer.com> <d3oufs$7gf$1@sea.gmane.org> In-Reply-To: <d3oufs$7gf$1@sea.gmane.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040800010000090906020705" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 18:01:42 -0000 This is a cryptographically signed message in MIME format. --------------ms040800010000090906020705 Content-Type: multipart/mixed; boundary="------------040904030802050709010005" This is a multi-part message in MIME format. --------------040904030802050709010005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michiel van Leeuwen wrote: > Doug Royer wrote: > >>> But as a user, i would expect that 1D means just that, one day. >> >> >> And it still means 1D. It just looks as if it does not when in >> non-UTC TZ's. > > > > Given that almost everybody lives in a non-utc timezone, wouldn't that > be the target you need to aim at? Make it usable in any timezone, not > only in utc... Finish reading that email. It addressed that issue. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040904030802050709010005 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------040904030802050709010005-- --------------ms040800010000090906020705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE1MTgwMTMxWjAjBgkqhkiG9w0BCQQxFgQUwcMEGU3FXaNdb5Q6iTX/ XBtW7/YwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAaSzGw9jowkMpHoZWu6pJYGhL3fCFO3c79L+bBL/a5LxFbt9dL0JVN2SfkAk2jKDX siRXsAdTCb/0P9tuh7YFaBo/QdggDmWOSCgpAOnJJOtDatD7kF+ro0veGBPHgpwPG3Ksm02x 9yiBd2u9zok4wUHcNTE+i+Uyo6JudPyjp1JgnzL0SJOJSqcJ3K06waH+W1JS2Vq/HFsH/PXf wLbUv8ZKLy4mPn4vBXrdg8M99O8dAdJByWjfpqRu5tzAs3ygd/L05Nb7nO9ASOSXZvnC/D7x SZ4xV7YAPytrfWF7FkEJiB4GQ1KyPGnPldWx5pcZVumH2OC9zV/DsLrtn8ERoQAAAAAAAA== --------------ms040800010000090906020705-- X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FHmPaa000969 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 10:48:27 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DMUrN-0008Kx-9Y for ietf-calsify@osafoundation.org; Fri, 15 Apr 2005 19:44:05 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 19:44:05 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 19:44:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Fri, 15 Apr 2005 19:47:01 +0200 Lines: 12 Message-ID: <d3oufs$7gf$1@sea.gmane.org> References: <425EF690.8020304@Royer.com> <d3nq3c$a82$1@sea.gmane.org> <425FFD48.5090908@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050414 In-Reply-To: <425FFD48.5090908@Royer.com> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: DURATION and PERIOD - proposal X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 17:48:28 -0000 Doug Royer wrote: >> But as a user, i would expect that 1D means just that, one day. > > And it still means 1D. It just looks as if it does not when in > non-UTC TZ's. Given that almost everybody lives in a non-utc timezone, wouldn't that be the target you need to aim at? Make it usable in any timezone, not only in utc... Michiel X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FHhkaa000602 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 10:43:48 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3FHhbk8011029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 10:43:41 -0700 Message-ID: <425FFD48.5090908@Royer.com> Date: Fri, 15 Apr 2005 11:43:36 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal References: <425EF690.8020304@Royer.com> <d3nq3c$a82$1@sea.gmane.org> In-Reply-To: <d3nq3c$a82$1@sea.gmane.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060906000405080108060501" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 17:43:52 -0000 This is a cryptographically signed message in MIME format. --------------ms060906000405080108060501 Content-Type: multipart/mixed; boundary="------------090804040200070705040805" This is a multi-part message in MIME format. --------------090804040200070705040805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michiel van Leeuwen wrote: > Doug Royer wrote: > >> 1M = 60S = we ignore leap second? I say yes. >> 1H = 60M >> 1D = 24H >> 1W = 7D > > > How does 1D=24H work daylight savings time? A day might not be 24H then. > And from what I understand, also not in UTC. There is no daylight saving time in UTC. > But as a user, i would > expect that 1D means just that, one day. And it still means 1D. It just looks as if it does not when in non-UTC TZ's. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------090804040200070705040805 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------090804040200070705040805-- --------------ms060906000405080108060501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE1MTc0MzM2WjAjBgkqhkiG9w0BCQQxFgQUyiv7zctg4mMHhtUmFzh2 b4jzS/EwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAit4vyKRu2aaZD/8CarD8yTsF9TX7odOGTbaK5q2rNw943GJpgzXOTzEDjKImEy3o oFDzokoyt8StrsYIwgA3Sbjb1/hwA7q0b+a0QU4hvjaFvgnzrHhnzhvqNJq14eC5gFxdtodB vkIZFv4pl+eNLTqXtRlM9N1lyVUHBSCQaddO3Fw/gq6eIgzd3tfQtRBWdKeZPolcUXOeA6e/ 6C5BRgTpR2V7Z8dWJZCPzVDBlreBfsTip12VpS6sXbjwfDVF5qr7Ordkwd5dxces7jO+RBuJ tyfryQc+utV310HLyJ+3JGEcTEX0DfzWPra7DvUMAFfuB5D4DyMSAeDVGsPDbwAAAAAAAA== --------------ms060906000405080108060501-- X-Envelope-From: bruce@callenish.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3FFT7aZ023061 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 08:29:07 -0700 Received: from pd3mr1so.prod.shaw.ca (pd3mr1so-qfe3.prod.shaw.ca [10.0.141.177]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IEZ008I6UZ9BHE0@l-daemon> for ietf-calsify@osafoundation.org; Fri, 15 Apr 2005 09:28:21 -0600 (MDT) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd3mr1so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IEZ009UOUZ9SS10@pd3mr1so.prod.shaw.ca> for ietf-calsify@osafoundation.org; Fri, 15 Apr 2005 09:28:21 -0600 (MDT) Received: from [192.168.168.98] (h24-68-208-230.sbm.shawcable.net [24.68.208.230]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IEZ00KALUZ9TZ@l-daemon> for ietf-calsify@osafoundation.org; Fri, 15 Apr 2005 09:28:21 -0600 (MDT) Date: Fri, 15 Apr 2005 08:28:20 -0700 From: Bruce Atherton <bruce@callenish.com> Subject: Re: [Ietf-calsify] PERIOD types In-reply-to: <200504151032.09355.reinhold@kainhofer.com> To: ietf-calsify@osafoundation.org Message-id: <425FDD94.7090909@callenish.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <16984.39451.946598.669379@cnr.cs.columbia.edu> <200504141014.53292.reinhold@kainhofer.com> <425EB68B.1020901@callenish.com> <200504151032.09355.reinhold@kainhofer.com> User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 15:29:10 -0000 Reinhold Kainhofer wrote: >Yes, but how do you calculate that occurence? You can only do that correctly >in the original time zone of the RRULE. > > But we agree that you have to have the time zone of the RRULE for a couple of reasons. So what is the problem in calculating the occurrence using that? X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3F8WCaa021210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 01:32:14 -0700 Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3F8WANe011870 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 10:32:11 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Date: Fri, 15 Apr 2005 10:32:06 +0200 User-Agent: KMail/1.8 References: <16984.39451.946598.669379@cnr.cs.columbia.edu> <200504141014.53292.reinhold@kainhofer.com> <425EB68B.1020901@callenish.com> In-Reply-To: <425EB68B.1020901@callenish.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3097795.HoQvly9dmg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504151032.09355.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 08:32:15 -0000 --nextPart3097795.HoQvly9dmg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 14 April 2005 20:29, Bruce Atherton wrote: > In your example, your RRULE would have a timezone of CET, a frequency of > monthly, and a ByDay of +1MO. The DTSTART would have a time of 233000 on > the previous day. If you look at it with the CET timezone, the CUA would > adjust the time to 013000 of the next day, check that the date equates > to Monday in the CET timezone, and you are good to go. If you look at > the same occurrence in the PST8PDT timezone, it becomes 153000 and stays > on the previous day (Sunday). This gets checked to see if the same date > and time equates to Monday in the CET timezone. It is, and again > everything works out. Yes, but how do you calculate that occurence? You can only do that correctl= y=20 in the original time zone of the RRULE.=20 Reinhold =2D-=20 =2D----------------------------------------------------------------- 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.a= t/ * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer --nextPart3097795.HoQvly9dmg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCX3wJTqjEwhXvPN0RAqwBAJ4xOBd+3hHKphnUz9C7UOAW2qG+4ACeK5mB QZL5fLEUWUPXWR6rF3aRyj8= =Y3KR -----END PGP SIGNATURE----- --nextPart3097795.HoQvly9dmg-- X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3F7S4aa018048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 00:28:06 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DMLB7-0005gU-Iw for ietf-calsify@osafoundation.org; Fri, 15 Apr 2005 09:23:49 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 09:23:49 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Fri, 15 Apr 2005 09:23:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Fri, 15 Apr 2005 09:25:53 +0200 Lines: 11 Message-ID: <d3nq3c$a82$1@sea.gmane.org> References: <425EF690.8020304@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050414 In-Reply-To: <425EF690.8020304@Royer.com> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: DURATION and PERIOD - proposal X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 15 Apr 2005 07:28:09 -0000 Doug Royer wrote: > 1M = 60S = we ignore leap second? I say yes. > 1H = 60M > 1D = 24H > 1W = 7D How does 1D=24H work daylight savings time? A day might not be 24H then. And from what I understand, also not in UTC. But as a user, i would expect that 1D means just that, one day. Michiel X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3EN2oaa014539 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Thu, 14 Apr 2005 16:02:52 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3EN2fuq031035 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Thu, 14 Apr 2005 16:02:43 -0700 Message-ID: <425EF690.8020304@Royer.com> Date: Thu, 14 Apr 2005 17:02:40 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calsify <ietf-calsify@osafoundation.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010608050500070406040203" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] DURATION and PERIOD - proposal X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify <ietf-calsify@osafoundation.org> List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Thu, 14 Apr 2005 23:02:56 -0000 This is a cryptographically signed message in MIME format. --------------ms010608050500070406040203 Content-Type: multipart/mixed; boundary="------------010807050400090006030607" This is a multi-part message in MIME format. --------------010807050400090006030607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ok, after digesting this for a while, something came out, hope my idea looks better :-) 1) This is how I propose we solve the floating time RDATE / PERIOD problem in CALSIFY: 1.1) DURATION and PERIOD proposal: In UTC - not an issue, 'duration' is: 1M = 60S = we ignore leap second? I say yes. 1H = 60M 1D = 24H 1W = 7D In any TZID: You must convert the DTSTART to UTC. Add 'duration' using the rules above. Add DTSTART + duration to find the non-inclusive 'end-time' in UTC. Convert 'end-time' back to the TZID. If TZID = America/New_York time: Assume the move ahead time is '2 am' If on a date-time when the clock moves forward: For: DTSTART: ... 01:59:00 DURATION: 15M Convert 2am to UTC (add 5 hours) and as that falls into America/New_York STANDARD time and get DTSTART:... 06:59:00 'Z' I add DURATION and get end-time: ... 07:14:00 am 'Z'. I convert back to America/New_York (noting out of interest that it is now DAYLIGHT time) and this would result in: DTSTART:... 01:59:00 DURATION: 15M end-time: ... 03:14:00 am A meeting that starts at 1:59 AM in America/New_York STANDARD time, lasts 15 minutes and ends at 3:14am America/New_York DAYLIGHT end. So DTEND - DTSTART == DURATION (in UTC) And the reverse works also: DTSTART: ... 1:59am in America/New_York DAYLIGHT DURATION: 15M (Time goes back 1H at 2am) end-time: ... 1:14 am in America/New_York STANDARD A meeting that starts at 1:59 AM in America/New_York DAYLIGHT time, lasts 15 minutes and ends at 1:14am America/New_York STANDARD time. It just at first glance looks as if it ends before it starts, it does not as it really is in two unique time zones. So DTEND - DTSTART == DURATION (in UTC) How does the GUI display this ? Not a iCal/CALSIFY 'data' problem :-) 1.2) If RDATE does not contain a TZID parameter, then the TZID of the RDATE is that of the DTSTART. This stops the RDATE from looking like a 'floating' date/time when the DTSTART is not floating. To convert from a 2445 object to a CALSIFY object, if DTSTART has a TZID and RDATE does not, then the conversion process must add a TZID to the RDATE property that is the same value as the DTSTART TZID value. If the DTSTART is of type date-time and the RDATE is of type 'date', then the time part from DTSTART is used as the 'time' part for RDATE when converting from 2445 objects. We deprecate allowing RDATE and DTSTART from having different 'value types'. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------010807050400090006030607 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------010807050400090006030607-- --------------ms010608050500070406040203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDE0MjMwMjQwWjAjBgkqhkiG9w0BCQQxFgQUfcokfVosInYGZrdzBgRb zt/KMqswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAxOcvlgi1LloTdzS0fTTIDgcF5RiPrt7hXHHSFpYBbggOIhGCai7Ot6GHPX1MHua6 g4xLKMMAncqG6OEDpKPz89nLYiwegB4seu3Scw/j9hbLekYkaD/ynZ943+eRECHLJpaGQ04z Y99QWQzfyKICJdMGNlZgcZTDycQZXiue9tHOZoRRtQ4AzS1eIubZ4tdDPhldsCb8FpU5vqQs yr4ClL/7quhuiNdxuOBiA+61DRdhp8qYjdyNF4gQCX7QLNLIfl2n3F7WbjVHa2hDoft+3OZ6 9GDWsW5mwrb1RE5JLu2yGxkpPPkmGpZ6snb61jhgWaEt6g0Q4i0ZPH2dfgt77wAAAAAAAA== --------------ms010608050500070406040203-- X-Envelope-From: bruce@callenish.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3EIU2aZ025666 for <ietf-calsify@osafoundation.org>; Thu, 14 Apr 2005 11:30:03 -0700 Received: from pd2mr5so.prod.shaw.ca (pd2mr5so-qfe3.prod.shaw.ca [10.0.141.8]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IEY00CR88PBMEC0@l-daemon> for ietf-calsify@osafoundation.org; Thu, 14 Apr 2005 12:29:35 -0600 (MDT) Received: from pn2ml9so.prod.shaw.ca ([10.0.121.7]) by pd2mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IEY002988PB1VD0@pd2mr5so.prod.shaw.ca> for ietf-calsify@osafoundation.org; Thu, 14 Apr 2005 12:29:35 -0600 (MDT) Received: from [192.168.168.98] (h24-68-208-230.sbm.shawcable.net [24.68.208.230]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IEY0030H8PAVN@l-daemon> for ietf-calsify@osafoundation.org; Thu, 14 Apr 2005 12:29:35 -0600 (MDT) Date: Thu, 14 Apr 2005 11:29:31 -0700 From: Bruce Atherton <bruce@callenish.com> Subject: Re: [Ietf-calsify] PERIOD types In-reply-to: <200504141014.53292.reinhold@kainhofer.com> To: ietf-calsify@osafoundation.org Message-id: <425EB68B.1020901@callenish.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050412030051.GA1143@ensemble.local> <425D6A44.9070805@callenish.com> <200504141014.53292.reinhold@kainhofer.com> User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Thu, 14 Apr 2005 18:30:03 -0000 Reinhold Kainhofer wrote: >On Wednesday 13 April 2005 20:51, Bruce Atherton wrote: > > >>This is something I've never understood about the iCalendar standard. >>Why isn't timezone primarily a presentation issue? If every date in >>iCalendar were stored in UTC, many problems go away. Then the CUA can >>render the event according to whatever the CU wants to see. >> >>There are two exceptions I can think of to this. RRULEs/EXRULES need a >>timezone attached, but only to indicate when the UTC rendering should >>shift due to DST issues. >> >> > >No, not only for DST shifts. You need it e.g. for events that recur at 00:30 >every sunday (in central european time). In UTC this would be 23:30 on >saturday, so the weekday of the recurrence rule heavily depends on the time >zone. > >Similarily, an event at 00:30 at every first of each month in CET (or CEST). >In UTC this is 23:30 at every last of each month. > >In these two examples the RRULE can theoretically be adjusted to UTC. > >But take e.g. 0:30 on ever first monday of each month. In UTC ths would be >23:30 on sunday, but not necessarily on each first sunday. If the 1st falls >on a monday the event would recur on the last day of the previous month. This >RRULE cannot be transferred to UTC at all. > > You make a good point that the definition of when an event is on a particular weekday defined in an RRULE depends on the timezone, but that just reemphasizes that RRULE needs a timezone. We are in agreement there. But I don't see why you think the first Monday of the month can't be done with UTC. It may be due to my ignorance, but I don't understand your point. In your example, your RRULE would have a timezone of CET, a frequency of monthly, and a ByDay of +1MO. The DTSTART would have a time of 233000 on the previous day. If you look at it with the CET timezone, the CUA would adjust the time to 013000 of the next day, check that the date equates to Monday in the CET timezone, and you are good to go. If you look at the same occurrence in the PST8PDT timezone, it becomes 153000 and stays on the previous day (Sunday). This gets checked to see if the same date and time equates to Monday in the CET timezone. It is, and again everything works out. What am I missing? X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3E8Ewaa014941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Thu, 14 Apr 2005 01:15:00 -0700 Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3E8Esfl003558 for <ietf-calsify@osafoundation.org>; Thu, 14 Apr 2005 10:14:55 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Date: Thu, 14 Apr 2005 10:14:50 +0200 User-Agent: KMail/1.8 References: <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050412030051.GA1143@ensemble.local> <425D6A44.9070805@callenish.com> In-Reply-To: <425D6A44.9070805@callenish.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3543096.UUetT17n2Y"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504141014.53292.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Thu, 14 Apr 2005 08:15:02 -0000 --nextPart3543096.UUetT17n2Y Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 13 April 2005 20:51, Bruce Atherton wrote: > This is something I've never understood about the iCalendar standard. > Why isn't timezone primarily a presentation issue? If every date in > iCalendar were stored in UTC, many problems go away. Then the CUA can > render the event according to whatever the CU wants to see. > > There are two exceptions I can think of to this. RRULEs/EXRULES need a > timezone attached, but only to indicate when the UTC rendering should > shift due to DST issues.=20 No, not only for DST shifts. You need it e.g. for events that recur at 00:3= 0=20 every sunday (in central european time). In UTC this would be 23:30 on=20 saturday, so the weekday of the recurrence rule heavily depends on the time= =20 zone. Similarily, an event at 00:30 at every first of each month in CET (or CEST)= =2E=20 In UTC this is 23:30 at every last of each month. In these two examples the RRULE can theoretically be adjusted to UTC.=20 But take e.g. 0:30 on ever first monday of each month. In UTC ths would be= =20 23:30 on sunday, but not necessarily on each first sunday. If the 1st falls= =20 on a monday the event would recur on the last day of the previous month. Th= is=20 RRULE cannot be transferred to UTC at all. Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- 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.a= t/ * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer --nextPart3543096.UUetT17n2Y Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCXiZ9TqjEwhXvPN0RAlLCAKDFiew/jJs9r7yfOjVHiGMwlT2WUQCdGeuL YJuUhc8ikRYsYXVU7JRCoQY= =NlYz -----END PGP SIGNATURE----- --nextPart3543096.UUetT17n2Y-- X-Envelope-From: bruce@callenish.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from pd4mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3DIpqaZ011634 for <ietf-calsify@osafoundation.org>; Wed, 13 Apr 2005 11:51:52 -0700 Received: from pd5mr3so.prod.shaw.ca (pd5mr3so-qfe3.prod.shaw.ca [10.0.141.144]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IEW00HGSF2FGQ7I@l-daemon> for ietf-calsify@osafoundation.org; Wed, 13 Apr 2005 12:51:51 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd5mr3so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IEW00847F2FRI50@pd5mr3so.prod.shaw.ca> for ietf-calsify@osafoundation.org; Wed, 13 Apr 2005 12:51:51 -0600 (MDT) Received: from [192.168.168.98] (h24-68-208-230.sbm.shawcable.net [24.68.208.230]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IEW0071JF2FAI@l-daemon> for ietf-calsify@osafoundation.org; Wed, 13 Apr 2005 12:51:51 -0600 (MDT) Date: Wed, 13 Apr 2005 11:51:48 -0700 From: Bruce Atherton <bruce@callenish.com> Subject: Re: [Ietf-calsify] PERIOD types In-reply-to: <20050412030051.GA1143@ensemble.local> To: Sam Roberts <sroberts@uniserve.com> Message-id: <425D6A44.9070805@callenish.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> <20050412022155.GC1048@ensemble.local> <425B3346.8010701@Royer.com> <20050412030051.GA1143@ensemble.local> User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Wed, 13 Apr 2005 18:51:53 -0000 Sam Roberts wrote: >Quoting Doug@royer.com, on Mon, Apr 11, 2005 at 08:32:38PM -0600: > > >>>Ruby's Time class is >>>a pretty thing wrapper around the C APIs, so vPim deals with this just >>>fine. >>> >>> Another data point is the Java Calendar class and the more specific GregorianCalendar class, used by almost all Java applications concerned with dates and times, including the ical4j library. Times are broken down into their component elements and arithmetic performed on that. This means that adding is done primarily as your intuition would suspect. Adding 1 month to January 31 results in February 28th or 29th, while adding 3 months results in April 30th. Add a day and it is the next day at the same time, even over a time shift. If the resulting field is invalid, it is adjusted. Adding a day to 20050402T0230 with timezone "America/Vancouver" results in 20050403T0130. Whereas adding a day to 20050402T0330 results in 20050402T0330. >Has anybody implemented date-time arithmetic in timezones other than >localtime and UTC well? I'd like to hear how they did it. > > > This is something I've never understood about the iCalendar standard. Why isn't timezone primarily a presentation issue? If every date in iCalendar were stored in UTC, many problems go away. Then the CUA can render the event according to whatever the CU wants to see. There are two exceptions I can think of to this. RRULEs/EXRULES need a timezone attached, but only to indicate when the UTC rendering should shift due to DST issues. And, to handle the "floating" type, there should be allowance in the standard for a hint to the CUA not to resolve the time according to a timezone, whether coming in or going out of iCalendar. Otherwise, I don't see what business timezones ever had in the standard. I've only recently joined the list, so apologies if this point of view has been previously hammered upon. X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3D8r2aa029066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Wed, 13 Apr 2005 01:53:04 -0700 Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3D8r1g7032122 for <ietf-calsify@osafoundation.org>; Wed, 13 Apr 2005 10:53:02 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Date: Wed, 13 Apr 2005 10:52:59 +0200 User-Agent: KMail/1.8 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <20050412022935.GD1048@ensemble.local> <B0688AA12F9AA14198DB4179@ninevah.local> In-Reply-To: <B0688AA12F9AA14198DB4179@ninevah.local> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart17958621.B25AvhtcKJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504131053.00956.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Wed, 13 Apr 2005 08:53:05 -0000 --nextPart17958621.B25AvhtcKJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 13 April 2005 06:00, Cyrus Daboo wrote: > OK, what about 2:30 am on the Sunday of a DST shift that adds one hour? > That time does not literally exist as the clocks jump from 2 am to 3 am. = So > if you have 2.30 am on Saturday the day before, you can't simply add one > day and expect to get a valid date-time. i.e. DST shifts do have to be > taken into account for at least this edge case. As I wrote in a previous mail, I think it would be consistent and logical t= o=20 define that the event ends on the last valid time before that invalid (i.e.= =20 not-happening) time. Reinhold =2D-=20 =2D----------------------------------------------------------------- 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.a= t/ * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer --nextPart17958621.B25AvhtcKJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCXN3sTqjEwhXvPN0RAiRlAKC3UJqoMVhy7tuqGTJhXMdJsIEWpACfYH0r Qn8MnmkgC8kc+M/nnHyeHCo= =WtXf -----END PGP SIGNATURE----- --nextPart17958621.B25AvhtcKJ-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3D8p8aa028875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Wed, 13 Apr 2005 01:51:10 -0700 Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3D8p4qT032044 for <ietf-calsify@osafoundation.org>; Wed, 13 Apr 2005 10:51:05 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types Date: Wed, 13 Apr 2005 10:51:01 +0200 User-Agent: KMail/1.8 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504121124.21258.reinhold@kainhofer.com> <425C8824.90709@Royer.com> In-Reply-To: <425C8824.90709@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4820677.hT3GqovNy6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504131051.03125.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Wed, 13 Apr 2005 08:51:11 -0000 --nextPart4820677.hT3GqovNy6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 13 April 2005 04:47, Doug Royer wrote: > Seems to me that as only the Organizer can move it back or change > the dates. This is Organizer CUA-specific data - correct ? > > I mean if an Attendee changes the date / length, then we are not > talking iCal or iTIP. Ahm, I thought calsify was not only about sending out invitations, but also= =20 about general data exchange. E.g. drag'n'dropping an event from KOrganizer = to=20 evolution (or outlook to lotus).=20 Also, what about counter-proposals? There you have exactly that situation=20 where the attendee modifies/moves the event and sends back his new event.=20 Reinhold =2D-=20 =2D----------------------------------------------------------------- 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.a= t/ * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer --nextPart4820677.hT3GqovNy6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCXN13TqjEwhXvPN0RAhHKAKCgwrQMabThNY4bx9Qz0RPEmi33FwCeKAkm iAPtdfOV9bbO/VD/H1ZhF6U= =PJyn -----END PGP SIGNATURE----- --nextPart4820677.hT3GqovNy6-- X-Envelope-From: daboo@isamet.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3D40maa005022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 21:00:49 -0700 Received: from [10.0.1.4] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j3D3h46g030741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2005 23:43:06 -0400 Date: Wed, 13 Apr 2005 00:00:44 -0400 From: Cyrus Daboo <daboo@isamet.com> To: Sam Roberts <sroberts@uniserve.com>, ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Message-ID: <B0688AA12F9AA14198DB4179@ninevah.local> In-Reply-To: <20050412022935.GD1048@ensemble.local> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> <200504120028.20445.reinhold@kainhofer.com> <20050412022935.GD1048@ensemble.local> X-Mailer: Mulberry/4.0.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Wed, 13 Apr 2005 04:00:50 -0000 Hi Sam, --On April 11, 2005 10:29:35 PM -0400 Sam Roberts <sroberts@uniserve.com> wrote: > When you add a day, you get the same time, one day later, irrespective > of DST shifts. > OK, what about 2:30 am on the Sunday of a DST shift that adds one hour? That time does not literally exist as the clocks jump from 2 am to 3 am. So if you have 2.30 am on Saturday the day before, you can't simply add one day and expect to get a valid date-time. i.e. DST shifts do have to be taken into account for at least this edge case. -- Cyrus Daboo X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3D2l7aa000344 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 19:47:09 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3D2l05Z029713 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 19:47:03 -0700 Message-ID: <425C8824.90709@Royer.com> Date: Tue, 12 Apr 2005 20:47:00 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org, ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <425B03A2.8050206@Royer.com> <6.2.1.2.0.20050411213334.01c74d10@mail.comcast.net> <200504121124.21258.reinhold@kainhofer.com> In-Reply-To: <200504121124.21258.reinhold@kainhofer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040702040102030409090701" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Wed, 13 Apr 2005 02:47:12 -0000 This is a cryptographically signed message in MIME format. --------------ms040702040102030409090701 Content-Type: multipart/mixed; boundary="------------020400030008030402030008" This is a multi-part message in MIME format. --------------020400030008030402030008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Seems to me that as only the Organizer can move it back or change the dates. This is Organizer CUA-specific data - correct ? I mean if an Attendee changes the date / length, then we are not talking iCal or iTIP. The Organizer and the Organizer CUA needs to know that it is a 'day' as seen by the Organizer. The Attendee needs to know 'when' and 'how long'. When I went to Australia a few years ago my appointments were all 12 hours off and some that I had not attended yet were in the past and some events were across 2 'dates' in that Australia time zone. I just cared when it started and how long, and when I had to get up. > Thinking of it, the duration (with intervals >S) is yet another case where the > TZ information is actually needed, since depending on the TZ a day might have > 23, 24 or 25 hours. On the other hand, if you give the duration in S, you'll > need the time zone to determine if a duration of 82800S meant really 23 > hours, or actually a day which due to the time zone shift has only 23 hours. > > This may not sound important, but if you try to move the event a day back, you > need exactly this information to determine the end date/time. E.g. take an > event at 14:00 on March 26 (in the EU summer time started on March 27, 2005) > lasting 82800S. It will end on March 27, 14:00. Now move it to March 25. Will > it end on March 26, 14:00 (i.e. duration is one day), or shall it end at > 13:00 (duration is 23 hours)? > Usually, the first is what people would expect, but to recover the information > that the duration is really one day you need to know that the event was > planned in a time zone where the shift happens while the event takes place. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020400030008030402030008 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020400030008030402030008-- --------------ms040702040102030409090701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDEzMDI0NzAwWjAjBgkqhkiG9w0BCQQxFgQUT3cZkOCxNiDZALFdoMDN Q/20uuMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAU9o/4kOafWWdurwj8kI2lDXRrR5BMJEjQwh5+BAE4pCoUoLHiEGw3zGwBbeU9roB lhOSVnVD5nqecNswfYHqGVkG+GUbbCCmK2WoC6fcGer+8kJa9IVIFk1gvW73VPUuQ8s0amLa lECp6/JWLVfIDVqjVtwPzzulS7Ke+usVlZMy33vWdjcsFFOuUJoDHyIploWV1FZaHMXPZls7 faIzanzkI9qLyQ+CxPyhcUriITrt8LinDDjXA9Ty78WdkOHeCWKSu0AcLnrIJiSszmcQ+kAQ LJlKxeCLcGvQzPHwX3h8LeL6AbJTyKP9NVcNYCZbdW/bATQERc7HMR7LyKYyFwAAAAAAAA== --------------ms040702040102030409090701-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts13-srv.bellnexxia.net (tomts13-srv.bellnexxia.net [209.226.175.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3CMO5aZ008402 for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 15:24:05 -0700 Received: from ensemble.local ([70.50.63.29]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050412222404.HYCH25800.tomts13-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 18:24:04 -0400 Received: by ensemble.local (Postfix, from userid 501) id 73B9F4317D5; Tue, 12 Apr 2005 18:23:33 -0400 (EDT) Date: Tue, 12 Apr 2005 18:23:33 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Message-ID: <20050412222333.GC555@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> <200504120028.20445.reinhold@kainhofer.com> <425B0504.6060509@Royer.com> <20050412025024.GE1048@ensemble.local> <425B44A6.3040808@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425B44A6.3040808@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 22:24:07 -0000 Quoting Doug@royer.com, on Mon, Apr 11, 2005 at 09:46:46PM -0600: > > > Sam Roberts wrote: > >Quoting Doug@royer.com, on Mon, Apr 11, 2005 at 05:15:16PM -0600: > > > > >And that doesn't include things that are widely implemented fairly well, > >like RRULE. > > RRULE is one of the most busted features of iCal. I know > of several valid iCal files I can send to various vendors > that will cause them to crash, display totally bogus information, > or completely ignore many of the instances. > > I do not own the files or I would send them out. dates and times are still in the public domain, you should be able to send the DTSTART and RRULE values, theres no personally identifying information in them. They'd make nice test cases of the more extreme RRULEs. Cheers, Sam X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts40-srv.bellnexxia.net (tomts40.bellnexxia.net [209.226.175.97]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3CMKqaZ008221 for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 15:20:54 -0700 Received: from ensemble.local ([70.50.63.29]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050412222052.ILAA27737.tomts40-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 18:20:52 -0400 Received: by ensemble.local (Postfix, from userid 501) id 20010431794; Tue, 12 Apr 2005 18:20:21 -0400 (EDT) Date: Tue, 12 Apr 2005 18:20:20 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types Message-ID: <20050412222020.GB555@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504120008.05795.reinhold@kainhofer.com> <20050412021650.GB1048@ensemble.local> <200504121114.39217.reinhold@kainhofer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504121114.39217.reinhold@kainhofer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 2.429 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 22:20:56 -0000 Quoting reinhold@kainhofer.com, on Tue, Apr 12, 2005 at 11:14:37AM +0200: > On Tuesday 12 April 2005 04:16, Sam Roberts wrote: > > Quoting reinhold@kainhofer.com, on Tue, Apr 12, 2005 at 12:08:00AM +0200: > > What do you do with a DTSTART of January 31st, set to recur > > FREQ=monthly? > > > > My interpretation of RFC2445 was that if running the RRULE results in a > > non-existent time, the event doesn't happen. So, that particular rule > > would only give occurences in months that have a 31st > > Yes, but these are different problems. With RRULE the problem is that the > event might not happen at all. With duration the problem is that the start > date/time exists, so the event does happen. The problem is when it ends. I know, my mind was wandering onto other subjects, sorry! Sam X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3CIv1aa009688 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 11:57:03 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3CIuq2X017331 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 11:56:56 -0700 Message-ID: <425C19F3.2040303@Royer.com> Date: Tue, 12 Apr 2005 12:56:51 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504120028.20445.reinhold@kainhofer.com> <425B0504.6060509@Royer.com> <200504121124.56130.reinhold@kainhofer.com> In-Reply-To: <200504121124.56130.reinhold@kainhofer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020105000901080401030605" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 18:57:07 -0000 This is a cryptographically signed message in MIME format. --------------ms020105000901080401030605 Content-Type: multipart/mixed; boundary="------------020304030100070405050107" This is a multi-part message in MIME format. --------------020304030100070405050107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reinhold Kainhofer wrote: > On Tuesday 12 April 2005 01:15, Doug Royer wrote: > >>Reinhold Kainhofer wrote: >> >>>But that's usually not what users would exists [expect?]. If I have an >>>event >>> >> >> > at 13:00 and it lasts 1 day, I expect it to end on 13:00 on the next >> >>day, >> >> > no matter if the night is one hour shorter or longer as usual. >> >>Then the Organizer CUA is free to do the math that way, as long as what >>it sends out is not open to interpretation at least two different ways. > > > But in that case you loose the meta-information that the event is supposed to > last one day. No, now the Attendee knows what the Organizer meant when they said "Do you want to attend this meeting that starts at noon and ends at 1pm, or 2pm or 3pm depending on how your CUA interpreted 2445. But only if one or the two of us just happened to be in a time zone that changed during the meeting." So what meta information is that ? > To force the mistakes of a few implementations on all others? No, to toss what is not working. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020304030100070405050107 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020304030100070405050107-- --------------ms020105000901080401030605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDEyMTg1NjUxWjAjBgkqhkiG9w0BCQQxFgQU3xuelNBgVag81NDd6Dp6 r0nl/GgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAvk4S1+GnC7kp+LkzugFxF9o3fNEYt9lQmPy1Y3ih+2eb7mSMQ/0hZDxRkwInCkVg tQd3rBwWXEp1jG1g0tTKoDUOFvwmDRxhE2RQoQZqhyl7MUk51VWkK3zlWuBTE4E9uAmoXm8v QWgVg671Xs4pTJnPpkN+jyfxth33Umjlc2GHvrGE3/cQ+3MI44NuzEQ3uK3OSOvlcfl8S17w 3a6NiUinM/9LvlptwLUIZxyy/p8Z+dAMX3FmnUdnsSir9ZMZaCTsaGxlqih3asi9gOnfHub1 v3e6opRf15ZIsKk9bVrjxHnX8VgKEOWgTO6Dul7CWgcVKwRYKWiIiK+5angDXAAAAAAAAA== --------------ms020105000901080401030605-- X-Envelope-From: lennox@cnr.cs.columbia.edu X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3CCw1aa024727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 05:58:02 -0700 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j3CCw1ZU006291; Tue, 12 Apr 2005 08:58:01 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j3CCw1Pj006288; Tue, 12 Apr 2005 08:58:01 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16987.50648.894601.65432@cnr.cs.columbia.edu> Date: Tue, 12 Apr 2005 08:58:00 -0400 To: Sam Roberts <sroberts@uniserve.com> Subject: Re: [Ietf-calsify] PERIOD types In-Reply-To: <20050412030051.GA1143@ensemble.local> References: <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> <20050412022155.GC1048@ensemble.local> <425B3346.8010701@Royer.com> <20050412030051.GA1143@ensemble.local> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 12:58:06 -0000 On Monday, April 11 2005, "Sam Roberts" wrote to "ietf-calsify@osafoundation.org" saying: > Has anybody implemented date-time arithmetic in timezones other than > localtime and UTC well? I'd like to hear how they did it. I have -- I modified the Olson TZ code to take a timezone argument. I can send a patch if people are interested. (Markus Kuhn has a version of my patch against an old version of the Olson code up at <http://www.cl.cam.ac.uk/~mgk25/time/c/proposal-lennox.patch>.) Java's java.util.Calendar class can also take a java.util.TimeZone class as an argument to its constructor. -- Jonathan Lennox lennox at cs dot columbia dot edu X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C9Ovaa003601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 02:25:00 -0700 Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3C9Oucr028704 for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 11:24:57 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Date: Tue, 12 Apr 2005 11:24:54 +0200 User-Agent: KMail/1.7.2 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504120028.20445.reinhold@kainhofer.com> <425B0504.6060509@Royer.com> In-Reply-To: <425B0504.6060509@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1576497.RUokho6vrg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504121124.56130.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 09:25:06 -0000 --nextPart1576497.RUokho6vrg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 12 April 2005 01:15, Doug Royer wrote: > Reinhold Kainhofer wrote: > > But that's usually not what users would exists [expect?]. If I have an > > event > > > > at 13:00 and it lasts 1 day, I expect it to end on 13:00 on the next > > day, > > > no matter if the night is one hour shorter or longer as usual. > > Then the Organizer CUA is free to do the math that way, as long as what > it sends out is not open to interpretation at least two different ways. But in that case you loose the meta-information that the event is supposed = to=20 last one day. It's the same problem as with removing RRULEs. Sure, the=20 resulting events will look the same, but you loose the meta-information of= =20 what the organizer actually intended. And that's not what I call=20 interoperability. As I already said, I see the purpose of a standard to clearly define how=20 things are supposed to be handled in all cases. So let's clearly state what= =20 1D means, and all standards-compliant applications will then understand it= =20 the same way. > > Even if the "big two" (as you put it) don't think like that, I would say > > that's a bug in their implementation. > > What's the point of CALSIFY? To force the mistakes of a few implementations on all others? Reinhold =2D-=20 =2D----------------------------------------------------------------- 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.a= t/ * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer --nextPart1576497.RUokho6vrg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCW5PoTqjEwhXvPN0RAsLeAJ9j6JmQncQq6XdFnILoC/1boe3DvQCg2qmk CsCnUJ3eup9val2Iag9s6D0= =TzoH -----END PGP SIGNATURE----- --nextPart1576497.RUokho6vrg-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C9ONaa003527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 02:24:24 -0700 Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3C9OLat028617 for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 11:24:22 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types Date: Tue, 12 Apr 2005 11:24:19 +0200 User-Agent: KMail/1.7.2 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <425B03A2.8050206@Royer.com> <6.2.1.2.0.20050411213334.01c74d10@mail.comcast.net> In-Reply-To: <6.2.1.2.0.20050411213334.01c74d10@mail.comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart17131702.r7eHWp1T2v"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504121124.21258.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 09:24:25 -0000 --nextPart17131702.r7eHWp1T2v Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 12 April 2005 03:51, Tim Hare wrote: > I don't see a real problem, however, with a definition that allows certain > longer periods to be transferred (day, month, year especially) and which > defines the addition to be done in the way most people expect - if I say > something occurs monthly, add 1 to the month modulo 12; for daily use the > "usual" date arithmentic allowing for the standard days per month and leap > years. Some of these periods and their associated addition algorithms are > very well defined and probably implemented in similar if not identical > ways. Yes, that's also my view. We only need to write down these well-defined cas= es=20 so that everyone can implement them exactly the same way. Thinking of it, the duration (with intervals >S) is yet another case where = the=20 TZ information is actually needed, since depending on the TZ a day might ha= ve=20 23, 24 or 25 hours. On the other hand, if you give the duration in S, you'l= l=20 need the time zone to determine if a duration of 82800S meant really 23=20 hours, or actually a day which due to the time zone shift has only 23 hours= =2E=20 This may not sound important, but if you try to move the event a day back, = you=20 need exactly this information to determine the end date/time. E.g. take an= =20 event at 14:00 on March 26 (in the EU summer time started on March 27, 2005= )=20 lasting 82800S. It will end on March 27, 14:00. Now move it to March 25. Wi= ll=20 it end on March 26, 14:00 (i.e. duration is one day), or shall it end at=20 13:00 (duration is 23 hours)?=20 Usually, the first is what people would expect, but to recover the informat= ion=20 that the duration is really one day you need to know that the event was=20 planned in a time zone where the shift happens while the event takes place. Reinhold =2D-=20 =2D----------------------------------------------------------------- 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.a= t/ * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer --nextPart17131702.r7eHWp1T2v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCW5PFTqjEwhXvPN0RAhoFAJ9N1x0xH7lIVuwQspsWazEL65JzFQCgw+Wh rvb2s+EO1Vc8xmWYAKcGLAs= =etOO -----END PGP SIGNATURE----- --nextPart17131702.r7eHWp1T2v-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C9Efaa002996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 02:14:45 -0700 Received: from curie.fam.tuwien.ac.at (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3C9EdoK026778 for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 11:14:40 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: FAM, Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types Date: Tue, 12 Apr 2005 11:14:37 +0200 User-Agent: KMail/1.7.2 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504120008.05795.reinhold@kainhofer.com> <20050412021650.GB1048@ensemble.local> In-Reply-To: <20050412021650.GB1048@ensemble.local> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7233246.ZOxQ5Sm3gs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504121114.39217.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 09:14:59 -0000 --nextPart7233246.ZOxQ5Sm3gs Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 12 April 2005 04:16, Sam Roberts wrote: > Quoting reinhold@kainhofer.com, on Tue, Apr 12, 2005 at 12:08:00AM +0200: > > Am Montag, 11. April 2005 23:44 schrieb Jonathan Lennox: > > > On Monday, April 11 2005, "Reinhold Kainhofer" wrote to > > > > "ietf-calsify@osafoundation.org" saying: > > Exactly, you run into the same problems. In particular, take (March 27, > > 2005, is the date when summer time was introduced everywhere in the EU): > > DTSTART;TZID=3D"Europe/Vienna":20050326T023000 > > DURATION:P1DT > > Since the hour from 02:00 to 03:00 is skipped, there is no 02:30 on Mar= ch > > 27.... I'd say, the event should end at the last valid time before that > > time. > > I can see that, it needs clarification, though. > > What do you do with a DTSTART of January 31st, set to recur > FREQ=3Dmonthly? > > My interpretation of RFC2445 was that if running the RRULE results in a > non-existent time, the event doesn't happen. So, that particular rule > would only give occurences in months that have a 31st=20 Yes, but these are different problems. With RRULE the problem is that the=20 event might not happen at all. With duration the problem is that the start= =20 date/time exists, so the event does happen. The problem is when it ends. Reinhold =2D-=20 =2D----------------------------------------------------------------- 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.a= t/ * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer --nextPart7233246.ZOxQ5Sm3gs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCW5F/TqjEwhXvPN0RApkEAJsEirVt5Q2YT1W+So494sE5ImkXHgCgzRuB zd88bzt84hck57JiVFnXbx0= =5XiE -----END PGP SIGNATURE----- --nextPart7233246.ZOxQ5Sm3gs-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C3kraa019002 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 20:46:54 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3C3kl9h007922 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 20:46:49 -0700 Message-ID: <425B44A6.3040808@Royer.com> Date: Mon, 11 Apr 2005 21:46:46 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> <200504120028.20445.reinhold@kainhofer.com> <425B0504.6060509@Royer.com> <20050412025024.GE1048@ensemble.local> In-Reply-To: <20050412025024.GE1048@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080804060507040004090506" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 03:46:56 -0000 This is a cryptographically signed message in MIME format. --------------ms080804060507040004090506 Content-Type: multipart/mixed; boundary="------------080806040305060500010503" This is a multi-part message in MIME format. --------------080806040305060500010503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Roberts wrote: > Quoting Doug@royer.com, on Mon, Apr 11, 2005 at 05:15:16PM -0600: > > And that doesn't include things that are widely implemented fairly well, > like RRULE. RRULE is one of the most busted features of iCal. I know of several valid iCal files I can send to various vendors that will cause them to crash, display totally bogus information, or completely ignore many of the instances. I do not own the files or I would send them out. Mostly multiple RRULEs, some can not handle any EXRULEs. Some crash or display bogus information if there is a RECURRENCE-ID and no RDATE or RRULEs. The parser is the easy part. Is where it fails most of the time is creating a UI that can display odd recurrence rules. Almost NO CUA can display multiple RRULEs. In most cases they can display them on a calendar. However when their vendor GUI tries to edit an entry - everything goes nuts. Their bugs - YES. However it limits interoperability. Or worse, they do not have the ability to display the odd or multiple RRULEs, so the user thinks the set of appointment does not match the text attachment or what it should, so they edit the GUI contents and maybe update the store overwriting instances their CUA did not display. Their less complex CUA does a simple thing. It enters the data in RDATEs because it can not handle complex RRULE editing. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------080806040305060500010503 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------080806040305060500010503-- --------------ms080804060507040004090506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDEyMDM0NjQ3WjAjBgkqhkiG9w0BCQQxFgQUytlkECKefI6AH5Bq7oqC u0RiN1wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAxjTl6TnJ7GhpirK4N+N3dZggDRbpcUtihUQ6LUMSDXmXwK8uAeNdZBayq9cSA9ZO XmHA8Cyz8BPYm/1p3++NlzKd2eNpbbffX+f0mC9P3M1z7IFTMERmTZGTiwnGbDLfD1ISBbdk L5o4MCSKPv/m2IpiKZNWabi6q6E8CdGHSOmG9/C2z1NKIAf2hfH26mScBIpNZChNOCoIFJex rJWL0hk6vrg3dSL8P4/926HJOm9aZzeGWlsW3Mae6lQprp0Eul7xSWk5dqrXH/Akpz37xwDq +TSX3WhQeadDg3tkecT857YaeIyVeM5v1JeZI0V3zeetIuLrSoTYIPooZkE/0gAAAAAAAA== --------------ms080804060507040004090506-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C3g6aa018541 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 20:42:08 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3C3fxg2007871 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 20:42:01 -0700 Message-ID: <425B4386.30003@Royer.com> Date: Mon, 11 Apr 2005 21:41:58 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types References: <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> <20050412022155.GC1048@ensemble.local> <425B3346.8010701@Royer.com> <20050412030051.GA1143@ensemble.local> In-Reply-To: <20050412030051.GA1143@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050503080407030300090109" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 03:42:13 -0000 This is a cryptographically signed message in MIME format. --------------ms050503080407030300090109 Content-Type: multipart/mixed; boundary="------------030307020205030801000601" This is a multi-part message in MIME format. --------------030307020205030801000601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Roberts wrote: > > > Has anybody implemented date-time arithmetic in timezones other than > localtime and UTC well? I'd like to hear how they did it. Yes, I know of many that do TZ math. They can't use mktime. And you can't really do RRULEs unless you can do TZ math on any VTIMEZONE time zone. Unless you never get any from a TZ that is not yours. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------030307020205030801000601 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------030307020205030801000601-- --------------ms050503080407030300090109 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDEyMDM0MTU4WjAjBgkqhkiG9w0BCQQxFgQUOGGTbmFVQbhSg/uHBSI8 0WUhVSQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAEB3/iAFDgiCkYFFyh+KIpnhgolyAzHAGtbg9GnBcwgI2bw9e/OBcBpRiGXxiAfmr Ll68/87qxxApHLx2o3IqsfIkFI7rXxLVDFNbhme8mo2mJTAaoxkuIPL70mlANpR1rM/KpR+d icM3hM+X+a98KjdXEouoc+A7z9GYKHQUbQUHrq/lRiQWV42mS7BvwiwNCXj5h6YsxB7q8yyP TEyycfF0EMr2+0ptaTUJTZiHiRdpKfWdx/mHY/FEc5N17XfniyCFcjQyIKb2yjkgOz7r3Olv ueW1BGQ3la+CXxkadnZ8abCaGLc8LznRG1/WK3CnDVynhSDJU6bRDfN2p4BDfwAAAAAAAA== --------------ms050503080407030300090109-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts46-srv.bellnexxia.net (tomts46.bellnexxia.net [209.226.175.190]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C3XHaZ017965 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 20:33:18 -0700 Received: from ensemble.local ([70.50.63.29]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050412030120.HWSK8412.tomts20-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 23:01:20 -0400 Received: by ensemble.local (Postfix, from userid 501) id 98D4F4313FE; Mon, 11 Apr 2005 23:00:51 -0400 (EDT) Date: Mon, 11 Apr 2005 23:00:51 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Message-ID: <20050412030051.GA1143@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> <20050412022155.GC1048@ensemble.local> <425B3346.8010701@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425B3346.8010701@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 03:33:20 -0000 Quoting Doug@royer.com, on Mon, Apr 11, 2005 at 08:32:38PM -0600: > Sam Roberts wrote: > > >Most ignore all time zone shifts. As in: > >> > >> 1D always == 86400S > >> 1W always == 604800S > > > >That surprises me, even the standard C library deals with time shifts > >better than that! Are you just looking at windows? > > > >If you use mktime to construct two times, they are handled internally as > >UTC, so subtraction gives true duration in seconds. > > Because there is no time shift in UTC, and ignoring leap seconds. > IT means that 1D always == 86400S and 1W always == 604800S Exactly. > Maybe most people use mktime ? Likely, so most implementations with no special effort, using only POSIX APIs, can deal with 1 day meaning 1 day in their timezone, so that your statement that "most should ignore time zone shifts" really surprises me. > >Ruby's Time class is > >a pretty thing wrapper around the C APIs, so vPim deals with this just > >fine. > > Try trying to get mktime to do the math on times that are not in > the systems TZ :-) I'm aware of that, and so I suspect that most systems work well only in their local timezone and UTC. I would not be suprised by a statement of "most don't know how to deal with timezones other than theirs and UTC". Its hard to deal with non-local timezones, but I don't think they can be removed. Timezones exist, you have to deal with them, and not all events are fixed in UTC. Meetings are, thats true, but if the Vatican published a calendar of expected times for sunday mass, would they have to publish one for each timezone, with all times in UTC? Has anybody implemented date-time arithmetic in timezones other than localtime and UTC well? I'd like to hear how they did it. Cheers, Sam X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts40-srv.bellnexxia.net (tomts40-srv.bellnexxia.net [209.226.175.97] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C2otaZ014367 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:50:55 -0700 Received: from ensemble.local ([70.50.63.29]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050412025054.ZGNW27737.tomts40-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 22:50:54 -0400 Received: by ensemble.local (Postfix, from userid 501) id 2858A4313C3; Mon, 11 Apr 2005 22:50:25 -0400 (EDT) Date: Mon, 11 Apr 2005 22:50:25 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Message-ID: <20050412025024.GE1048@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> <200504120028.20445.reinhold@kainhofer.com> <425B0504.6060509@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425B0504.6060509@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 02:50:58 -0000 Quoting Doug@royer.com, on Mon, Apr 11, 2005 at 05:15:16PM -0600: > Reinhold Kainhofer wrote: > >But that's usually not what users would exists [expect?]. If I have an > >event > > at 13:00 and it lasts 1 day, I expect it to end on 13:00 on the next > day, > > no matter if the night is one hour shorter or longer as usual. > > Then the Organizer CUA is free to do the math that way, as long as what > it sends out is not open to interpretation at least two different ways. > > >Even if the "big two" (as you put it) don't think like that, I would say > >that's a bug in their implementation. > > What's the point of CALSIFY? To clarify points the have been interpreted differently due to weaknesses in the spec. To throw things away that noone has implemented interoperably. No interoperable implementation means it can't be standardized, if I understand IETF rules. Thats my understanding, anyhow. And that doesn't include things that are widely implemented fairly well, like RRULE. I did a clean room implementation, not having found any informative source, and the other calendars I've seen do fine when interpreted by my RRULE code. I publish all the birthdays in my address book to Apple's iCal recurring events, and it worked fine. I've had one problem with a RRULE, a misinterpretation by Apple, IMO, of an odd-ball provincial holiday on the second monday of every August. I need to post about that. Also, I've got 75 RRULE's in my local calendars, my calendars are published to others, and many of those RRULEs are my friends work or play schedules, and they have events that recur indefinitely every week. Explicitly listing a twice-a-week event with RDATE would be an exercise in pain! Even Canada Day occurs every year. The "RRULE doesn't work well story" just doesn't fit my experience. But, I haven't implemented iTIP. I have the impression RRULE doesn't work so well in iTIP. If there aren't any interoperable implementations of scheduling events specified using RRULE, then maybe the iTIP profile needs to be amended to state that all meetings use RDATE with explicit end times, or maybe every event occurence as a single VEVENT. If thats what the implementors of scheduling programs think will make their job easier, I could easily be convinced that was reasonable. Cheers, Sam X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C2Wjaa012486 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:32:47 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3C2WdGr007064 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:32:41 -0700 Message-ID: <425B3346.8010701@Royer.com> Date: Mon, 11 Apr 2005 20:32:38 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types References: <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> <20050412022155.GC1048@ensemble.local> In-Reply-To: <20050412022155.GC1048@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010907010302040409070502" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 02:32:48 -0000 This is a cryptographically signed message in MIME format. --------------ms010907010302040409070502 Content-Type: multipart/mixed; boundary="------------040200020104040008060402" This is a multi-part message in MIME format. --------------040200020104040008060402 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Roberts wrote: >Most ignore all time zone shifts. As in: >> >> 1D always == 86400S >> 1W always == 604800S > > That surprises me, even the standard C library deals with time shifts > better than that! Are you just looking at windows? > > If you use mktime to construct two times, they are handled internally as > UTC, so subtraction gives true duration in seconds. Because there is no time shift in UTC, and ignoring leap seconds. IT means that 1D always == 86400S and 1W always == 604800S Maybe most people use mktime ? > Ruby's Time class is > a pretty thing wrapper around the C APIs, so vPim deals with this just > fine. Try trying to get mktime to do the math on times that are not in the systems TZ :-) The TZ info like the locale information on POSIX systems is not thread specific. (see tzset) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040200020104040008060402 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------040200020104040008060402-- --------------ms010907010302040409070502 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDEyMDIzMjM4WjAjBgkqhkiG9w0BCQQxFgQUQsF0KSYmMdLijpiJSwkh CkqAUMIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAXRb7KO0w5grvcVHioN2THEmXIER2LJFax9KnsE8fZz3/TQFw/LWa8FQqIlHF0bE9 e3XztFKwdPkXRRp1BYuFqLRcOFQVj3wVEbcESFEKDEpwaG4vTp2GgXM94dOuIlTfmEMcaQD2 vaDQNCT4BQ3oiG6J5OrL3kOG0NV1HHxjuXBQuAGbHo226eu0odumba57LRIKhfC34yqtaBNk h+aHGrs/MshGkX/+WsA9M93soFr195/xCMQByOioOg4IVa87kdXCwOs+HryJ16Go9V2JdU0U 6Fc4MUeiYOL2CVnHlrIC8ugrX5GlvjxrGhazWZC4k8gyssas6XPhIDXR9AnY8gAAAAAAAA== --------------ms010907010302040409070502-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts20-srv.bellnexxia.net (tomts20.bellnexxia.net [209.226.175.74]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C2U6aZ012194 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:30:06 -0700 Received: from ensemble.local ([70.50.63.29]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050412023005.HQGC8412.tomts20-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 22:30:05 -0400 Received: by ensemble.local (Postfix, from userid 501) id 09EB74313A0; Mon, 11 Apr 2005 22:29:35 -0400 (EDT) Date: Mon, 11 Apr 2005 22:29:35 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Message-ID: <20050412022935.GD1048@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> <200504120028.20445.reinhold@kainhofer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504120028.20445.reinhold@kainhofer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 2.429 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 02:30:07 -0000 Quoting reinhold@kainhofer.com, on Tue, Apr 12, 2005 at 12:28:18AM +0200: > > And lets say that 1W == 7D. > > Yes, that's clear, because no weekdays are skipped or added, even in leap > years. But only if a day is really a day, and not 24 hours/24*60*60 secs! Btw, my interpretation is like yours. When you add a year, you get the same date and time, one year later irrespective of leap years. When you add a day, you get the same time, one day later, irrespective of DST shifts. That was easy to implement. The only oddities are when I arrive at a time that doesn't exist on a particular day. Sam X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C2Mwaa011765 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:22:59 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3C2MoOa006962 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:22:52 -0700 Message-ID: <425B30FA.9060405@Royer.com> Date: Mon, 11 Apr 2005 20:22:50 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> <d3et07$l4k$1@sea.gmane.org> <425B03A2.8050206@Royer.com> <6.2.1.2.0.20050411213334.01c74d10@mail.comcast.net> In-Reply-To: <6.2.1.2.0.20050411213334.01c74d10@mail.comcast.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080204020107030803040506" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 02:23:02 -0000 This is a cryptographically signed message in MIME format. --------------ms080204020107030803040506 Content-Type: multipart/mixed; boundary="------------080904020701010302090001" This is a multi-part message in MIME format. --------------080904020701010302090001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim Hare wrote: > So, if I'm following this correctly, what we're saying is that the UI of > any CUA can present whatever it wants, but when sending duration it > should always use seconds. For example, I say a meeting occurs once per > day and lasts one hour; but when one implementation sends it to another, > the meeting occurs once every 86,400 seconds and lasts 3600 seconds. I > still think there might be problems with time shifts under this method, > unless the implementations calculate the correct number of seconds for > leap years and centuries, and add leap seconds as appropriate, but this > should in general work. I have not seen a proposal to change RDATE to seconds (if that is what you meant). And yes, the Organizer must calculate the length of the instances in order to ensure that all Attendees know how long a meeting will be. That's the 2445 bug that Sam found. > I don't see a real problem, however, with a definition that allows > certain longer periods to be transferred (day, month, year especially) > ... We are not talking about recurrence rules, we are talking about instance lengths. > ...and which defines the addition to be done in the way most people expect > - if I say something occurs monthly, add 1 to the month modulo 12; for > daily use the "usual" date arithmentic allowing for the standard days > per month and leap years. Some of these periods and their associated > addition algorithms are very well defined and probably implemented in > similar if not identical ways. Yes, and many of those functions that I have tried, do not take a timezone name as an argument. So they can be off by as much as a day on leap year depending on how the Organizer expected the behavior Did you know that the US Congress is debating a bill to change the US time zones now? Do those functions know what someone in a non-US country sends to a US Attendee expects as the length of a meeting will be on a date in the future when the US time zone changes?. Only the Organizer knows how much time an event is supposed to consume. I gave up on those functions and convert all instance dates to UTC using the TZID time zone information. Then convert them to seconds from a specific date/time, do the duration/dtend math and then convert the seconds back to UTC date/time. Then use the TZ information to figure out the TZID date/time for the end. By doing the math for each instance in UTC, there is no time zone changing in the middle issue. Is what I did not notice until Sam sent the email is that not everyone calculated the end time for the nTh instance using duration between DTEND/DTSTART. And as all DTEND's that I have seen have a TZID when DTSTART has a TZID, when I converted each time into UTC, it took the TZ shift into account. Others choose other methods. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------080904020701010302090001 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------080904020701010302090001-- --------------ms080204020107030803040506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDEyMDIyMjUwWjAjBgkqhkiG9w0BCQQxFgQU96/+n7ZH4LJ9WajNM7P4 auAMEnUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAbiWOmmtNtTrBhDC6OcRZ5/bJArWblAbvL5KQHpiikQNgd5ic4szxKqXsR7lEmvXT jQYpE6qT/lte05LfG+n65O5cGxQzLGHssvnkFDj9+BQCi+YWLpZNkhAZbH4RdD9TapWy9AdU 2du6Zu6RfooZ/UN/6ReRrUeQ1tcddaPQ8YQ9VwJBFwywIPl9KK6H9m1iJ3Q+vki73IwOG4pN DK/kK0EVJ4zq6ItHnIARhSMxUexFVUkLHjTV/67mG7xw3DTeF7jD6H9dJBOVE1oMDaALvJly fIe15VvtTVK+Wpcdtzj0K6VeGYLubc34rP9uI+1hDGYC2z7GRhEzK0n5s22ZYgAAAAAAAA== --------------ms080204020107030803040506-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts43-srv.bellnexxia.net (tomts43.bellnexxia.net [209.226.175.110]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C2MPaZ011716 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:22:26 -0700 Received: from ensemble.local ([70.50.63.29]) by tomts43-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050412022225.BEJI28273.tomts43-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 22:22:25 -0400 Received: by ensemble.local (Postfix, from userid 501) id ACBAD43135C; Mon, 11 Apr 2005 22:21:55 -0400 (EDT) Date: Mon, 11 Apr 2005 22:21:55 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Message-ID: <20050412022155.GC1048@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425AE17F.7040806@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 02:22:27 -0000 Quoting Doug@royer.com, on Mon, Apr 11, 2005 at 02:43:43PM -0600: > > > Jonathan Lennox wrote: > > > >We could certainly define semantics for time-unit arithmetic -- the basics > >aren't very hard, though the corner cases are tricky -- but I'd really > >rather know what existing systems actually do first, so we don't go too far > >off into the weeds defining weird semantics. > > Most ignore all time zone shifts. As in: > > 1D always == 86400S > 1W always == 604800S That surprises me, even the standard C library deals with time shifts better than that! Are you just looking at windows? If you use mktime to construct two times, they are handled internally as UTC, so subtraction gives true duration in seconds. Ruby's Time class is a pretty thing wrapper around the C APIs, so vPim deals with this just fine. Sam X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts40-srv.bellnexxia.net (tomts40-srv.bellnexxia.net [209.226.175.97] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C2HKaZ011443 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:17:21 -0700 Received: from ensemble.local ([70.50.63.29]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050412021720.YYWZ27737.tomts40-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 22:17:20 -0400 Received: by ensemble.local (Postfix, from userid 501) id B0C5443133A; Mon, 11 Apr 2005 22:16:50 -0400 (EDT) Date: Mon, 11 Apr 2005 22:16:50 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types Message-ID: <20050412021650.GB1048@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504112330.58109.reinhold@kainhofer.com> <16986.61391.797972.759023@cnr.cs.columbia.edu> <200504120008.05795.reinhold@kainhofer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504120008.05795.reinhold@kainhofer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 2.429 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 02:17:21 -0000 Quoting reinhold@kainhofer.com, on Tue, Apr 12, 2005 at 12:08:00AM +0200: > Am Montag, 11. April 2005 23:44 schrieb Jonathan Lennox: > > On Monday, April 11 2005, "Reinhold Kainhofer" wrote to > "ietf-calsify@osafoundation.org" saying: > Exactly, you run into the same problems. In particular, take (March 27, 2005, > is the date when summer time was introduced everywhere in the EU): > DTSTART;TZID="Europe/Vienna":20050326T023000 > DURATION:P1DT > Since the hour from 02:00 to 03:00 is skipped, there is no 02:30 on March > 27.... I'd say, the event should end at the last valid time before that time. I can see that, it needs clarification, though. What do you do with a DTSTART of January 31st, set to recur FREQ=monthly? My interpretation of RFC2445 was that if running the RRULE results in a non-existent time, the event doesn't happen. So, that particular rule would only give occurences in months that have a 31st (you can always use one of the BY* rules to select the last day of all months, if that was what was intended). Sam X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C2BFaZ011068 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:11:16 -0700 Received: from ensemble.local ([70.50.63.29]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050412021114.UUI26128.tomts5-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 22:11:14 -0400 Received: by ensemble.local (Postfix, from userid 501) id DD012431324; Mon, 11 Apr 2005 22:10:44 -0400 (EDT) Date: Mon, 11 Apr 2005 22:10:44 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types Message-ID: <20050412021044.GA1048@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <16986.57297.446923.781606@cnr.cs.columbia.edu> <d3en9f$v7m$1@sea.gmane.org> <200504112330.58109.reinhold@kainhofer.com> <16986.61391.797972.759023@cnr.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16986.61391.797972.759023@cnr.cs.columbia.edu> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 02:11:19 -0000 Quoting lennox@cs.columbia.edu, on Mon, Apr 11, 2005 at 05:44:47PM -0400: > On Monday, April 11 2005, "Reinhold Kainhofer" wrote to "ietf-calsify@osafoundation.org" saying: > > I think that 1M doesn't mean "add 60 seconds", rather it means "add1 to the > > minutes" (even if the minute doesn't have exactly 60 seconds). > > Given that, how would you handle my case D? > > DTSTART:19981231T235960Z > DURATION:PT1M > > "Add one to the minutes, leave the seconds alone" would imply an end time of > 1999-01-01 00:00:60 UTC, but there is no such time. > > This is nit-picky for leap seconds, which nobody really handles anyway, but > it's important for daylight saving time shifts. IIRC, even POSIX says that standard time is time without considering leap seconds. A bit of a cop-out, but understandable - unlike leap years leap seconds are added "every once in a while", theres some international body that looks at the drift in the clock from the solar year and issues corrections. So, its possible to handle the past ones, but impossible to handle future ones without some kind of real-time mechanism. I hope I didn't butcher that description! Anyhow, leap seconds are unpredictable, to my knowledge, but leap years, DST, and the fact that months have different lengths is all known in advance. Cheers, Sam X-Envelope-From: TimHare@comcast.net X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3C1pSaZ010030 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 18:51:28 -0700 Received: from thare.comcast.net (pcp03614075pcs.micske01.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc12) with SMTP id <2005041201512201400het2qe>; Tue, 12 Apr 2005 01:51:23 +0000 Message-Id: <6.2.1.2.0.20050411213334.01c74d10@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 11 Apr 2005 21:51:19 -0400 To: ietf-calsify@osafoundation.org From: Tim Hare <TimHare@comcast.net> Subject: Re: [Ietf-calsify] Re: PERIOD types In-Reply-To: <425B03A2.8050206@Royer.com> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> <d3et07$l4k$1@sea.gmane.org> <425B03A2.8050206@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.75 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 12 Apr 2005 01:51:30 -0000 So, if I'm following this correctly, what we're saying is that the UI of any CUA can present whatever it wants, but when sending duration it should always use seconds. For example, I say a meeting occurs once per day and lasts one hour; but when one implementation sends it to another, the meeting occurs once every 86,400 seconds and lasts 3600 seconds. I still think there might be problems with time shifts under this method, unless the implementations calculate the correct number of seconds for leap years and centuries, and add leap seconds as appropriate, but this should in general work. I don't see a real problem, however, with a definition that allows certain longer periods to be transferred (day, month, year especially) and which defines the addition to be done in the way most people expect - if I say something occurs monthly, add 1 to the month modulo 12; for daily use the "usual" date arithmentic allowing for the standard days per month and leap years. Some of these periods and their associated addition algorithms are very well defined and probably implemented in similar if not identical ways. At 07:09 PM 4/11/2005, you wrote: >Michiel van Leeuwen wrote: >>Doug Royer wrote: >> >>>Lets deprecate all but 'S' so that everyone can >>>use the same calculation method and keep the >>>most compatibility with existing CUA's. >> >>How would you express an event lasting 1 day in this suggested way? (1 >>day meaning just add 1 to the day, don't touch time) Which is the >>situation where dtend is problematic, and what duration was supposed to >>be a solution for. But if you can't use duration either, there is a problem... > >Send the duraiton in seconds. > >If The Organizer CUA hard code 1D = 86400S, then all Attendees >will know how long of a time period is being talked about >because it is in the duration in seconds. > >If they hard code 1D = 86400S +/- some time shift on rare >occasions then they will send out ####s and all Attendees >will know how long of a time period is being talked about >because it is in the duration in seconds. > >The purpose of CALSIFY is to make things work between >vendors. Eliminating things that are not portable (D, W, >and M) and keeing things that are portable (S), makes >it work for everyone. > > > But if you can't use duration either, there is a > > problem... > >You can use duration, just not non-portable values. > >-- > >Doug Royer | http://INET-Consulting.com >-------------------------------|----------------------------- > > We Do Standards - You Need Standards > > > > > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BNFSaa001036 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 16:15:30 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3BNFGPt005091 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 16:15:20 -0700 Message-ID: <425B0504.6060509@Royer.com> Date: Mon, 11 Apr 2005 17:15:16 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> <200504120028.20445.reinhold@kainhofer.com> In-Reply-To: <200504120028.20445.reinhold@kainhofer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070306000703060003090602" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 23:15:32 -0000 This is a cryptographically signed message in MIME format. --------------ms070306000703060003090602 Content-Type: multipart/mixed; boundary="------------020403020900090506010603" This is a multi-part message in MIME format. --------------020403020900090506010603 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reinhold Kainhofer wrote: > > > But that's usually not what users would exists [expect?]. If I have an event > at 13:00 and it lasts 1 day, I expect it to end on 13:00 on the next day, > no matter if the night is one hour shorter or longer as usual. Then the Organizer CUA is free to do the math that way, as long as what it sends out is not open to interpretation at least two different ways. > Even if the "big two" (as you put it) don't think like that, I would say > that's a bug in their implementation. What's the point of CALSIFY? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020403020900090506010603 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020403020900090506010603-- --------------ms070306000703060003090602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDExMjMxNTE2WjAjBgkqhkiG9w0BCQQxFgQUhxJHe4hyODU0+fotSp3k W+kxSF4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAjw1Or+V6K7yI37XU+2xNsPGRJgLnTzSXobqUMZm82YR4jo7BRhYUi+86HaVobuo7 9TS/hJf9ptGS35B0wM1sBp5f7MzyRAkoEpnYyx+eiZBvP47ijsYq49d3s4pw350HrlKmqL6E v2gbaMlDW936nn7EY1xPJRDJ/6yh5Pfqno7fjrzBXc6jNt16DKoS/m3YlwQA3CCAmT79WYwt 0uGTt21QmRrQgUUwe1wcN1LCN/l7Bs5ANkxewNy+K0Tcn/6Rv2gppAliy0xfgxzasaPd5iSK J8wtvdGOOcJ8ouAJy6yjCU5eEsdM/wYUHGU8iZscXbv7pkhJuJaS8H3VtGfrVwAAAAAAAA== --------------ms070306000703060003090602-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BN9Vaa000500 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 16:09:34 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3BN9N87005030 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 16:09:27 -0700 Message-ID: <425B03A2.8050206@Royer.com> Date: Mon, 11 Apr 2005 17:09:22 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> <d3et07$l4k$1@sea.gmane.org> In-Reply-To: <d3et07$l4k$1@sea.gmane.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030307050108010509030808" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 23:09:37 -0000 This is a cryptographically signed message in MIME format. --------------ms030307050108010509030808 Content-Type: multipart/mixed; boundary="------------000307060603000905010405" This is a multi-part message in MIME format. --------------000307060603000905010405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michiel van Leeuwen wrote: > Doug Royer wrote: > >> Lets deprecate all but 'S' so that everyone can >> use the same calculation method and keep the >> most compatibility with existing CUA's. > > > How would you express an event lasting 1 day in this suggested way? (1 > day meaning just add 1 to the day, don't touch time) Which is the > situation where dtend is problematic, and what duration was supposed to > be a solution for. But if you can't use duration either, there is a > problem... Send the duraiton in seconds. If The Organizer CUA hard code 1D = 86400S, then all Attendees will know how long of a time period is being talked about because it is in the duration in seconds. If they hard code 1D = 86400S +/- some time shift on rare occasions then they will send out ####s and all Attendees will know how long of a time period is being talked about because it is in the duration in seconds. The purpose of CALSIFY is to make things work between vendors. Eliminating things that are not portable (D, W, and M) and keeing things that are portable (S), makes it work for everyone. > But if you can't use duration either, there is a > problem... You can use duration, just not non-portable values. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------000307060603000905010405 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------000307060603000905010405-- --------------ms030307050108010509030808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDExMjMwOTIyWjAjBgkqhkiG9w0BCQQxFgQUfQuRvf/jqJaXIOfwzk8f zXE2EQcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAnhkR1sAtHx0E6vNCEl0+lo0TI0eNJ4G1rGCABWwR4emz8aJrCjZtwak6nQ42Pb9Y 4dUvbJkEn3VlXj3i/GLLE+ThlNK1eU+oXmmsTuO2c8/CUlNkUtB+Sswph3gN2/K3Ocp86aG+ VjEZalI29jm8bkz3t2lP5i2Z0AsskjPIb1Pj1JfMbYukC0yCIYjv/PxaDbLfQtojY8cvwa02 CN4qaKxVMQfYtBmRKMvAWl1VUwliZ9AgH/VW8BanZir8uI2rQMaB9vyzoCqm/3GvReJ4okF5 wlVatFt5mLvgID6bY6IKPGvjlOyhOhnXGcag9WSM+vLdoIicb4E2COHsNsfwNAAAAAAAAA== --------------ms030307050108010509030808-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BMSNaa030710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 15:28:25 -0700 Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3BMSLGj016713 for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 00:28:22 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Date: Tue, 12 Apr 2005 00:28:18 +0200 User-Agent: KMail/1.8 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> In-Reply-To: <425AF429.8060805@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart23200271.ihL2WUrhVG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504120028.20445.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 22:28:26 -0000 --nextPart23200271.ihL2WUrhVG Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Dienstag, 12. April 2005 00:03 schrieb Doug Royer: > This seems to be the same argument how to find the correct > end time. If the argument is that is all the Attendee CUA > has to do is add to DATE (not time), then why can't the > Organizer CUA do that and send out everything in seconds? Because it makes a difference when you use RRULE or RDATE (and one of the=20 occurences fall on the daylight shift).=20 > Existing 2445 implementation would process ##S correctly > as would CALSIFY implementations. But that's usually not what users would exists. If I have an event at 13:00= =20 and it lasts 1 day, I expect it to end on 13:00 on the next day, no matter = if=20 the night is one hour shorter or longer as usual. Even if the "big two" (as you put it) don't think like that, I would say=20 that's a bug in their implementation.=20 > Lets deprecate all but 'S' so that everyone can > use the same calculation method=20 Hell, let's just get rid of all RRULE and RDATE (and the RECURRENCE-ID)! If= =20 each event is created separately with it's own DTSTART and DTEND, we won't= =20 have any problems </sarcasm> Just because we find some inconsistencies,=20 doesn't mean it's best to simply remove that feature. That's throwing out t= he=20 child with the bath. I think it's more important to write down how to handle all these cases=20 exactly (because that's what lead to the fragmentation: nothing in the spec= =20 said how to calculate the dtend).=20 > Converting from 2445 DURATIONs: > > I think we could live with saying 1M =3D=3D 60S. > > The big two vendor seem to say that 1D =3D 86400S. Oh, great. Exchange also didn't use the minus sign in the alarms, so let's= =20 just disallow the minus in the alarm offset! </sarcasm> Just because one=20 company chose one particular implemention (which in my eyes is not what is= =20 meant in rfc 2445), all others should be forced to use the same brain-dead= =20 implementation? There are lots of places where Exchange is not really standard-compliant. A= re=20 you now trying to argue to adapt the standard to what Exchange implement?=20 (And leave all other existing applications in the cold, when they try to ge= t=20 things right). > And lets say that 1W =3D=3D 7D. Yes, that's clear, because no weekdays are skipped or added, even in leap=20 years. Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart23200271.ihL2WUrhVG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCWvoETqjEwhXvPN0RAm2sAKCfv6YRvvd/AEu0cAB47qHiOTRO8wCfeuF0 6Yuo5qCSuf4uknkip577Te0= =MV8E -----END PGP SIGNATURE----- --nextPart23200271.ihL2WUrhVG-- X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BMKgaa030068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 15:20:44 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL7Dl-000250-CV for ietf-calsify@osafoundation.org; Tue, 12 Apr 2005 00:17:29 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 00:17:29 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 00:17:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Tue, 12 Apr 2005 00:19:38 +0200 Lines: 12 Message-ID: <d3et07$l4k$1@sea.gmane.org> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> <200504112328.27917.reinhold@kainhofer.com> <425AF429.8060805@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050407 In-Reply-To: <425AF429.8060805@Royer.com> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: PERIOD types X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 22:20:46 -0000 Doug Royer wrote: > Lets deprecate all but 'S' so that everyone can > use the same calculation method and keep the > most compatibility with existing CUA's. How would you express an event lasting 1 day in this suggested way? (1 day meaning just add 1 to the day, don't touch time) Which is the situation where dtend is problematic, and what duration was supposed to be a solution for. But if you can't use duration either, there is a problem... Michiel X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BM87aa029228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 15:08:09 -0700 Received: from ip6-localhost (doob.fam.tuwien.ac.at [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3BM86IY013566 for <ietf-calsify@osafoundation.org>; Tue, 12 Apr 2005 00:08:06 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types Date: Tue, 12 Apr 2005 00:08:00 +0200 User-Agent: KMail/1.8 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504112330.58109.reinhold@kainhofer.com> <16986.61391.797972.759023@cnr.cs.columbia.edu> In-Reply-To: <16986.61391.797972.759023@cnr.cs.columbia.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4955196.fdbWMrTMAE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504120008.05795.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 22:08:10 -0000 --nextPart4955196.fdbWMrTMAE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 11. April 2005 23:44 schrieb Jonathan Lennox: > On Monday, April 11 2005, "Reinhold Kainhofer" wrote to=20 "ietf-calsify@osafoundation.org" saying: > > Since in leap seconds the 59th minute has 60 seconds, in both cases the > > DTEND would be 19990101T000000Z (since 1M should mean: just add 1 to the > > minutes count, leave the seconds untouched). > > > > > (Note that if it just splits into hours, minutes, seconds etc, and th= en > > > adds to the minute, it might looks like it handled leapseconds, while > > > in fact it didn't. or the other way around.) > > > > I think that 1M doesn't mean "add 60 seconds", rather it means "add1 to > > the minutes" (even if the minute doesn't have exactly 60 seconds). > > Given that, how would you handle my case D? > > DTSTART:19981231T235960Z > DURATION:PT1M > > "Add one to the minutes, leave the seconds alone" would imply an end time > of 1999-01-01 00:00:60 UTC, but there is no such time. Intuitively I'd say 00:00:59 (i.e. the last second of the minute). Of cours= e,=20 that can't be deduced from any standard, but that's what I as a user would= =20 expect. Of course, for me as a programmer it would be simpler to just=20 understand 1M as 60 seconds, but I doubt that this is what a user would=20 expect. > This is nit-picky for leap seconds, which nobody really handles anyway, b= ut > it's important for daylight saving time shifts. Exactly, you run into the same problems. In particular, take (March 27, 200= 5,=20 is the date when summer time was introduced everywhere in the EU): DTSTART;TZID=3D"Europe/Vienna":20050326T023000 DURATION:P1DT Since the hour from 02:00 to 03:00 is skipped, there is no 02:30 on March=20 27.... I'd say, the event should end at the last valid time before that tim= e.=20 That would mean it would end a 02:00.=20 Actually this would make sense insofar as before 02:00 the event was still= =20 going on. Then the time jumps to 03:00, and then the event is not going on= =20 any more according to the calculation without time jump. =46rom a user's perspective: If the event starts at 2:30 and takes one day,= I=20 wouldn't expect it to end at 3:30, even if there's no 2:30. (Actually, KOrganizer still shows an end time of 02:30, since the UI doesn'= t=20 show time zone shifts.) Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart4955196.fdbWMrTMAE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCWvVFTqjEwhXvPN0RAm1PAKCNyeWGx3jCH4lmleGsjh/JCKe+SgCgkrIW yfOw/whymMVBFezJY7bpn2Y= =Iv2S -----END PGP SIGNATURE----- --nextPart4955196.fdbWMrTMAE-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BM3Taa028934 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 15:03:32 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3BM3LDQ004259 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 15:03:25 -0700 Message-ID: <425AF429.8060805@Royer.com> Date: Mon, 11 Apr 2005 16:03:21 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> <200504112328.27917.reinhold@kainhofer.com> In-Reply-To: <200504112328.27917.reinhold@kainhofer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090603070801020608060806" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 22:03:35 -0000 This is a cryptographically signed message in MIME format. --------------ms090603070801020608060806 Content-Type: multipart/mixed; boundary="------------050801040200010205080109" This is a multi-part message in MIME format. --------------050801040200010205080109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reinhold Kainhofer wrote: > > In KOrganizer its "1D always means: Increase the date by one, leave the time > untouched.". Michiel van Leeuwen wrote: > I checked the source of libical (which at least mozilla calendar uses, > and afaik evolution uses it too), and it indeed does that. So this is the problem. Not done the same way in at least two applications that were found in less than an hour of looking. Leap seconds could arguably be ignored, but not one lost or gained hour in D or W. This seems to be the same argument how to find the correct end time. If the argument is that is all the Attendee CUA has to do is add to DATE (not time), then why can't the Organizer CUA do that and send out everything in seconds? Existing 2445 implementation would process ##S correctly as would CALSIFY implementations. Implementations that have D = 86400S would correctly display the end time from implementations where D means add to the date only if it were send out in 'S' and not 'D'. Lets deprecate all but 'S' so that everyone can use the same calculation method and keep the most compatibility with existing CUA's. Converting from 2445 DURATIONs: I think we could live with saying 1M == 60S. The big two vendor seem to say that 1D = 86400S. They DO include a PRODID, so we could specify that 1D = 86400S and learn who does not, publish those results and for those when converting from 2445 objects to date math. And lets say that 1W == 7D. I have not tested for leap year across a #W rule yet with other vendors :-) -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------050801040200010205080109 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------050801040200010205080109-- --------------ms090603070801020608060806 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDExMjIwMzIxWjAjBgkqhkiG9w0BCQQxFgQUy/cgygShpV4ADHW8MaXz al7bA8kwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEApsKESDjm4O6Xvu3cMPdOtD0TN0Q51Zo5RzrM9tAHND3urOT4/OTa+Ss6ZWulb0Do xrBRB+bpV8QR3ZQ61tIYc4iH6RXeDat/e+X47KcKSBthDMuNrh1a1Ku7ZIBpHq/SCVL5WGgj Yt3pQGG7AFc2RE0GtInZv2Mel3ZN7SGolRU4mXxYetBioy4c61BhEOQfKOHG+bCIYrgqb8Yg AqLRQP1FjWjtHZj369MvbMMS5sk7uVpZo27DEaECTFrzOYBrDKTUgA6BivEeLDyEkQkTljbb 4l4Iy3T7ujEzn1hSnq6RFXSZlrDNTEQJpXgfgaBPWQFNK3Jr5+7Sjv2r8uOLdgAAAAAAAA== --------------ms090603070801020608060806-- X-Envelope-From: lennox@cnr.cs.columbia.edu X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BLimaa026975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 14:44:49 -0700 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j3BLil6m004033 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 17:44:47 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j3BLilk9004030; Mon, 11 Apr 2005 17:44:47 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16986.61391.797972.759023@cnr.cs.columbia.edu> Date: Mon, 11 Apr 2005 17:44:47 -0400 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types In-Reply-To: <200504112330.58109.reinhold@kainhofer.com> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <16986.57297.446923.781606@cnr.cs.columbia.edu> <d3en9f$v7m$1@sea.gmane.org> <200504112330.58109.reinhold@kainhofer.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 21:44:51 -0000 On Monday, April 11 2005, "Reinhold Kainhofer" wrote to "ietf-calsify@osafoundation.org" saying: > Since in leap seconds the 59th minute has 60 seconds, in both cases the DTEND > would be 19990101T000000Z (since 1M should mean: just add 1 to the minutes > count, leave the seconds untouched). > > > (Note that if it just splits into hours, minutes, seconds etc, and then > > adds to the minute, it might looks like it handled leapseconds, while in > > fact it didn't. or the other way around.) > > I think that 1M doesn't mean "add 60 seconds", rather it means "add1 to the > minutes" (even if the minute doesn't have exactly 60 seconds). Given that, how would you handle my case D? DTSTART:19981231T235960Z DURATION:PT1M "Add one to the minutes, leave the seconds alone" would imply an end time of 1999-01-01 00:00:60 UTC, but there is no such time. This is nit-picky for leap seconds, which nobody really handles anyway, but it's important for daylight saving time shifts. -- Jonathan Lennox lennox at cs dot columbia dot edu X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BLV0aa025420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 14:31:02 -0700 Received: from ip6-localhost (doob.fam.tuwien.ac.at [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3BLUxZj012864 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 23:30:59 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types Date: Mon, 11 Apr 2005 23:30:46 +0200 User-Agent: KMail/1.8 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <16986.57297.446923.781606@cnr.cs.columbia.edu> <d3en9f$v7m$1@sea.gmane.org> In-Reply-To: <d3en9f$v7m$1@sea.gmane.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1483851.jQRzh01Qk0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504112330.58109.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 21:31:03 -0000 --nextPart1483851.jQRzh01Qk0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 11. April 2005 22:42 schrieb Michiel van Leeuwen: > Jonathan Lennox wrote: > > Indeed, do any current CUs handle leap seconds at all? If they don't, > > I'd be strongly tempted to forbid leap second handling in iCalendar at > > all. > > > > A) > > DTSTART:19981231T235900Z > > DURATION:PT1M > > What would be the expected result if the CU handles leap seconds? And > what if it doesnt? Since in leap seconds the 59th minute has 60 seconds, in both cases the DTE= ND=20 would be 19990101T000000Z (since 1M should mean: just add 1 to the minutes= =20 count, leave the seconds untouched). > (Note that if it just splits into hours, minutes, seconds etc, and then > adds to the minute, it might looks like it handled leapseconds, while in > fact it didn't. or the other way around.) I think that 1M doesn't mean "add 60 seconds", rather it means "add1 to the= =20 minutes" (even if the minute doesn't have exactly 60 seconds). Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart1483851.jQRzh01Qk0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCWuySTqjEwhXvPN0RAmaHAJ4pQLONBHGnUCylPPD/HgfpNpbzbwCgl4SR 5KnAGDorOnPoj57QX5pc/+U= =oCCF -----END PGP SIGNATURE----- --nextPart1483851.jQRzh01Qk0-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BLSUaa025194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 14:28:32 -0700 Received: from ip6-localhost (doob.fam.tuwien.ac.at [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3BLST8H012823 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 23:28:29 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types Date: Mon, 11 Apr 2005 23:28:26 +0200 User-Agent: KMail/1.8 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> In-Reply-To: <425AE17F.7040806@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3310813.57JFOgyxlo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504112328.27917.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 21:28:36 -0000 --nextPart3310813.57JFOgyxlo Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 11. April 2005 22:43 schrieb Doug Royer: > Jonathan Lennox wrote: > > We could certainly define semantics for time-unit arithmetic -- the > > basics aren't very hard, though the corner cases are tricky -- but I'd > > really rather know what existing systems actually do first, so we don't > > go too far off into the weeds defining weird semantics. > > Most ignore all time zone shifts. As in: > > 1D always =3D=3D 86400S > 1W always =3D=3D 604800S=20 In KOrganizer its "1D always means: Increase the date by one, leave the tim= e=20 untouched.". > I would be happy if we just specified that in CALSIFY. No, that completely defeats the purpose of having D and W durations. D mean= s=20 "Add one day to the date", W means "add 7 days to the date" (even if one of= =20 these days is longer/shorter than 86400 seconds). Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart3310813.57JFOgyxlo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCWuv7TqjEwhXvPN0RAmQcAKC5/PXrVylPg5UdBGHHkJilMnRVXACgyBUm GIkkARcSjOFlFAAImNk3Tyk= =G89G -----END PGP SIGNATURE----- --nextPart3310813.57JFOgyxlo-- X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BL6vaa023200 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 14:06:59 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL64C-0006mn-1r for ietf-calsify@osafoundation.org; Mon, 11 Apr 2005 23:03:32 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 23:03:32 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 23:03:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Mon, 11 Apr 2005 23:05:02 +0200 Lines: 10 Message-ID: <d3eokd$5gc$1@sea.gmane.org> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050407 In-Reply-To: <425AE17F.7040806@Royer.com> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: PERIOD types X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 21:07:00 -0000 Doug Royer wrote: > Most ignore all time zone shifts. As in: > > 1D always == 86400S > 1W always == 604800S I checked the source of libical (which at least mozilla calendar uses, and afaik evolution uses it too), and it indeed does that. Michiel X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BL4Taa022836 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 14:04:30 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3BL4NMS003316 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 11 Apr 2005 14:04:26 -0700 Message-ID: <425AE657.9010502@Royer.com> Date: Mon, 11 Apr 2005 15:04:23 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> <425AE17F.7040806@Royer.com> In-Reply-To: <425AE17F.7040806@Royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030302070407050608050805" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 21:04:34 -0000 This is a cryptographically signed message in MIME format. --------------ms030302070407050608050805 Content-Type: multipart/mixed; boundary="------------040200070605010504040700" This is a multi-part message in MIME format. --------------040200070605010504040700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Correcting myself again. Doug Royer wrote: > Most ignore all time zone shifts. As in: > > 1D always == 86400S > 1W always == 604800S > > I would be happy if we just specified that in CALSIFY. > And if you want a specific end time, the Organizer > needs to use 'S' to specify the duration they want. Its not that they seem to hard code those rules. Most ignore time zone shifts, so it looks as if they hard code those values. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040200070605010504040700 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------040200070605010504040700-- --------------ms030302070407050608050805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDExMjEwNDIzWjAjBgkqhkiG9w0BCQQxFgQUELKuiNt3Z3M6myNA6SWG 6AgKJv4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAEz2FkBKNaQKm25lQcFN5vpnC1VvYWz7t2xpbIBy+1ZaSx1yccT9x6hhO3Lu07uK/ wxZ0zD+o/P9ijpLQyxuP/9NC/6OMjFY48DnCqc9JgigtaiAduOjLlBsn4oHgL2dayjdSfW8v m4FgOjHQ4EpglF/4howWJa67a5D0rGHuxppnpUcv8EdFJOqkGzWcbGhzv0MXNkXrbsGP+9mF 1yId7fwFGy5ox0I3iwMu5KrJJb51+8ZrldVbl5af2mYGehZM/TVmAcWdCguv86cz3Kys4+IB V3wkMFr72A/SBLNAofK7bmYbompANIUIEhsOKVKs1rQH4A0wyLoSNbACnhN0nwAAAAAAAA== --------------ms030302070407050608050805-- X-Envelope-From: lennox@cnr.cs.columbia.edu X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BKlVaa021133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 13:47:32 -0700 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j3BKlSB9003351; Mon, 11 Apr 2005 16:47:28 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j3BKlSnk003348; Mon, 11 Apr 2005 16:47:28 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16986.57952.696766.472109@cnr.cs.columbia.edu> Date: Mon, 11 Apr 2005 16:47:28 -0400 To: Michiel van Leeuwen <mvl@exedo.nl> Subject: Re: [Ietf-calsify] Re: PERIOD types In-Reply-To: <d3en9f$v7m$1@sea.gmane.org> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> <16986.57297.446923.781606@cnr.cs.columbia.edu> <d3en9f$v7m$1@sea.gmane.org> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 20:47:33 -0000 On Monday, April 11 2005, "Michiel van Leeuwen" wrote to "ietf-calsify@osafoundation.org" saying: > Jonathan Lennox wrote: > > Indeed, do any current CUs handle leap seconds at all? If they don't, I'd > > be strongly tempted to forbid leap second handling in iCalendar at all. > > > > A) > > DTSTART:19981231T235900Z > > DURATION:PT1M > > What would be the expected result if the CU handles leap seconds? And > what if it doesnt? That's the question -- I don't know. RFC 2445 is silent on this. > (Note that if it just splits into hours, minutes, seconds etc, and then > adds to the minute, it might looks like it handled leapseconds, while in > fact it didn't. or the other way around.) Indeed. -- Jonathan Lennox lennox at cs dot columbia dot edu X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BKi1aa020860 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 13:44:04 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL5i1-0003JY-3P for ietf-calsify@osafoundation.org; Mon, 11 Apr 2005 22:40:37 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 22:40:36 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 22:40:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Mon, 11 Apr 2005 22:42:09 +0200 Lines: 15 Message-ID: <d3en9f$v7m$1@sea.gmane.org> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> <16986.57297.446923.781606@cnr.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050407 In-Reply-To: <16986.57297.446923.781606@cnr.cs.columbia.edu> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: PERIOD types X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 20:44:24 -0000 Jonathan Lennox wrote: > Indeed, do any current CUs handle leap seconds at all? If they don't, I'd > be strongly tempted to forbid leap second handling in iCalendar at all. > > A) > DTSTART:19981231T235900Z > DURATION:PT1M What would be the expected result if the CU handles leap seconds? And what if it doesnt? (Note that if it just splits into hours, minutes, seconds etc, and then adds to the minute, it might looks like it handled leapseconds, while in fact it didn't. or the other way around.) Michiel X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BKhoaa020850 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 13:43:51 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3BKhiQA002868 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 13:43:48 -0700 Message-ID: <425AE17F.7040806@Royer.com> Date: Mon, 11 Apr 2005 14:43:43 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> In-Reply-To: <16986.55962.308561.222259@cnr.cs.columbia.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000207030902050108050909" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 20:43:55 -0000 This is a cryptographically signed message in MIME format. --------------ms000207030902050108050909 Content-Type: multipart/mixed; boundary="------------090304070103090502000701" This is a multi-part message in MIME format. --------------090304070103090502000701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > > We could certainly define semantics for time-unit arithmetic -- the basics > aren't very hard, though the corner cases are tricky -- but I'd really > rather know what existing systems actually do first, so we don't go too far > off into the weeds defining weird semantics. Most ignore all time zone shifts. As in: 1D always == 86400S 1W always == 604800S I would be happy if we just specified that in CALSIFY. And if you want a specific end time, the Organizer needs to use 'S' to specify the duration they want. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------090304070103090502000701 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------090304070103090502000701-- --------------ms000207030902050108050909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDExMjA0MzQ0WjAjBgkqhkiG9w0BCQQxFgQUKls2j6UuIvNvBQnMjKJR 3EubcGYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAsZKLPYV74Q+m1BJSK/KcTsJ9ERA7yHLsXSPC3BsJ4mYdmOMPzc9SmLR4iXhWD3tl KGlMKBlw+RVT4ZHimQAadTOTRArj6dNhkVs5TGK2BacCQ6PJ9vU6dNoWzuITb2UB0ncfdBZv +SsDlx0hQADJHdBFSjWaIu+8Hc2ND75JLqS6WpROtaJuJFLpusPQtInt7d/rsnuKDip08Zmj /n3v6GYAqLBNPBzIWBUgScjCdFEIf7bZw+RqJIAY/Rjzo4+IQnhs4+hJM795O6Qqg04+8wiw g9C9xiNQruqgVXpp+H2qlNJ8y2HAhygnK5YQG13RxUtp0Q8QLhYoI6FWt/kLqAAAAAAAAA== --------------ms000207030902050108050909-- X-Envelope-From: lennox@cnr.cs.columbia.edu X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BKaXaa020322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 13:36:34 -0700 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j3BKaX9L003281 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 16:36:33 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j3BKaXXw003278; Mon, 11 Apr 2005 16:36:33 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16986.57297.446923.781606@cnr.cs.columbia.edu> Date: Mon, 11 Apr 2005 16:36:33 -0400 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types In-Reply-To: <16986.55962.308561.222259@cnr.cs.columbia.edu> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <16986.55962.308561.222259@cnr.cs.columbia.edu> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 20:36:35 -0000 On Monday, April 11 2005, "Jonathan Lennox" wrote to "ietf-calsify@osafoundation.org" saying: > We could certainly define semantics for time-unit arithmetic -- the basics > aren't very hard, though the corner cases are tricky -- but I'd really > rather know what existing systems actually do first, so we don't go too far > off into the weeds defining weird semantics. (Following up to myself...) Indeed, do any current CUs handle leap seconds at all? If they don't, I'd be strongly tempted to forbid leap second handling in iCalendar at all. Relevant corner case events whose end times I'd like to nail down (1998-12-31 23:59:60 UTC was the most recent leap second): A) DTSTART:19981231T235900Z DURATION:PT1M B) DTSTART:19981231T235900Z DURATION:PT2M C) DTSTART:19981231T230000Z DURATION:PT2H D) [this is the tricky one] DTSTART:19981231T235960Z DURATION:PT1M And the equivalent cases for both date-time with TZID and for floating times (for a local time corresponding to midnight UTC). -- Jonathan Lennox lennox at cs dot columbia dot edu X-Envelope-From: lennox@cnr.cs.columbia.edu X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BKEIaa017600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 13:14:19 -0700 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j3BKEI7M003133 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 16:14:18 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j3BKEIv4003130; Mon, 11 Apr 2005 16:14:18 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16986.55962.308561.222259@cnr.cs.columbia.edu> Date: Mon, 11 Apr 2005 16:14:18 -0400 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] PERIOD types In-Reply-To: <425AC759.5090608@Royer.com> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 20:14:20 -0000 On Monday, April 11 2005, "Doug Royer" wrote to "ietf-calsify@osafoundation.org" saying: > > Isn't that exactly why you do need them? Without them, i don't see how > > you set a duration of 1 day. Using 24 hours won't do, because 1 day > > might be 25 hours. A duration of 1 day would mean: until the same time > > the next day. > > The problem is defining how to uses them so that all ends have > the results when they display to a CU. Its We could certainly define semantics for time-unit arithmetic -- the basics aren't very hard, though the corner cases are tricky -- but I'd really rather know what existing systems actually do first, so we don't go too far off into the weeds defining weird semantics. -- Jonathan Lennox lennox at cs dot columbia dot edu X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BJNUaa013330 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 12:23:32 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL4Ra-00084u-9j for ietf-calsify@osafoundation.org; Mon, 11 Apr 2005 21:19:34 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 21:19:34 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 21:19:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Mon, 11 Apr 2005 21:21:53 +0200 Lines: 14 Message-ID: <d3eij0$dqq$1@sea.gmane.org> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <d3ehlg$aq2$1@sea.gmane.org> <425ACC67.10000@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050407 In-Reply-To: <425ACC67.10000@Royer.com> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: PERIOD types X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 19:23:33 -0000 Doug Royer wrote: > Martijn did today on this list - leap seconds. Yes, and that is why i think you need to be able to say that an event lasts 1hour. The amount of seconds in that hour might differ, just like the amount of hours in a day. But for the user, it is still an hour, or a day. So i stil don't see why the different length of a day is a problem. If you remove the ability to express a day from duration, and at the same time duration is the solution to the dtend problem, you just can no longer express an event that just takes 8 hours, no matter if there is daylight saving. Michiel X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BJDoaa012386 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 12:13:51 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3BJDi0l001670 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 12:13:47 -0700 Message-ID: <425ACC67.10000@Royer.com> Date: Mon, 11 Apr 2005 13:13:43 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: PERIOD types References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> <d3ehlg$aq2$1@sea.gmane.org> In-Reply-To: <d3ehlg$aq2$1@sea.gmane.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080305040808060708030205" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 19:13:53 -0000 This is a cryptographically signed message in MIME format. --------------ms080305040808060708030205 Content-Type: multipart/mixed; boundary="------------020908030800070303070109" This is a multi-part message in MIME format. --------------020908030800070303070109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Martijn did today on this list - leap seconds. I am not sure that I could 'see' the problem. It does exist. Michiel van Leeuwen wrote: > Doug Royer wrote: > >> The problem is defining how to uses them so that all ends have >> the results when they display to a CU. Its >> > Can hou give an example of a rule that is ambigious? Or is you remark > based on experience with existing clients? if so, can you give an example? > > Michiel -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020908030800070303070109 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020908030800070303070109-- --------------ms080305040808060708030205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDExMTkxMzQzWjAjBgkqhkiG9w0BCQQxFgQUhmDjOX7MPiJiUF1QgVHd a8sNLS8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAug0qqqk8xRpYh0mQBX+lJdu6OleAI8Kg4Pn6Jf+csqH5GdGC9SwVXb+2g59TYKwL WZ4IhivMdzK2IcPANQ7iYKeVEIQuyDnn30dAXhqUDfLiodhBV0T0N+ihY0TaM0e9QczV4IxG r3fYJ+KXtXggCtjte9koIsGeJyk5FvVOHjwl5dgM6V2YUPeh19Vp9Pamt0pFEdaEUCKum+CL hqoVUSjo2f4uJMGdqV8k6BJPV2zmPmMSnpBJ7M1WT8nLmabvgi8p7iD2iUHCMBBO9A8n2Vxo DuM9ynP1Rltuhkl6yz1PpLGIQtCMnSRiPtMAkBFTlB9h9ursX03q8p+dqDITmQAAAAAAAA== --------------ms080305040808060708030205-- X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BJ8Baa011760 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 12:08:13 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL4Cs-0005jc-68 for ietf-calsify@osafoundation.org; Mon, 11 Apr 2005 21:04:22 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 21:04:22 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 21:04:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Mon, 11 Apr 2005 21:06:09 +0200 Lines: 8 Message-ID: <d3ehlg$aq2$1@sea.gmane.org> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <425AC759.5090608@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050407 In-Reply-To: <425AC759.5090608@Royer.com> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: PERIOD types X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 19:08:14 -0000 Doug Royer wrote: > The problem is defining how to uses them so that all ends have > the results when they display to a CU. Its > Can hou give an example of a rule that is ambigious? Or is you remark based on experience with existing clients? if so, can you give an example? Michiel X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BIqIaa010248 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 11:52:19 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3BIq9rQ001212 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 11:52:12 -0700 Message-ID: <425AC759.5090608@Royer.com> Date: Mon, 11 Apr 2005 12:52:09 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> In-Reply-To: <d3eb83$kas$1@sea.gmane.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060301090807070507090702" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] PERIOD types X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 18:52:21 -0000 This is a cryptographically signed message in MIME format. --------------ms060301090807070507090702 Content-Type: multipart/mixed; boundary="------------080600040502000806050308" This is a multi-part message in MIME format. --------------080600040502000806050308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michiel van Leeuwen wrote: > Doug Royer wrote: > >> Good point. We decided against 'M' (month) in PERIOD because it has >> a variable length >> >> We could eliminate 'W' and 'D' as they can get confusing for that >> reason. > > > Isn't that exactly why you do need them? Without them, i don't see how > you set a duration of 1 day. Using 24 hours won't do, because 1 day > might be 25 hours. A duration of 1 day would mean: until the same time > the next day. The problem is defining how to uses them so that all ends have the results when they display to a CU. Its Martijn van Beers wrote: > Then you'd have to eliminate minute and hour too, since leap seconds > make them variable length too. > S is the only one that always works. Yep. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------080600040502000806050308 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------080600040502000806050308-- --------------ms060301090807070507090702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDExMTg1MjA5WjAjBgkqhkiG9w0BCQQxFgQUhKJ5c2DSK4VmOOA3wZTy mRsLu50wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAnfnGddXEjCumas///xpKqYGFqZTDqUnCdLpSZQQ45qJLqIltYEsi5a7xHeLsbo43 W/bCSgv4H86DjMAYitjNW9VlWTNfGmuXmSvUoSjS7BTPUrUvnCHx3iaWqpzdixO1vGMHkw5p eqvWWk6aLgeZecYP5vtDrmNVjLbOFVfqTiVxupO5NAlfiXKnv6JvCcqESGevnSfdWJnKg02I E/e44sNNNYUOoCSBNGDVcgVlp7xccl4RvxwTURwDqKCTMLXd+E0BuLaA/ug6TVN8EUsSfmDS VHu4vLzDq99ArwX6NGvT+gb7gPHP3oPm14Q8abgvDawgmiwAGQ3c4f+E5S8IUAAAAAAAAA== --------------ms060301090807070507090702-- X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BIeLaa008536 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 11:40:23 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL3lx-0001TL-0G for ietf-calsify@osafoundation.org; Mon, 11 Apr 2005 20:36:33 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 20:36:32 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 20:36:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Mon, 11 Apr 2005 20:38:03 +0200 Lines: 15 Message-ID: <d3eg0q$4d5$1@sea.gmane.org> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> <16986.47114.3567.477734@cnr.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050407 In-Reply-To: <16986.47114.3567.477734@cnr.cs.columbia.edu> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: 2nd and higher instance busted across time zone changes. X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 18:40:24 -0000 Jonathan Lennox wrote: > What does DURATION:P1DT8H mean, then? A duration of 1 day, 8 hours. So first add one day (23, 24 or 25 hours), then add another 8 hours. > Also, since this is calsify -- how do existing clients handle day-based > durations (with or without hours) which cross an offset change? This discussion has gone a long way from looking at what existing clients do anyway, with all kind of suggestions for forbidding things and about what certain things should mean etc. So i just added another suggestion :) Michiel X-Envelope-From: lennox@cnr.cs.columbia.edu X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BHkoaa002925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 10:46:51 -0700 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j3BHkoNB000840 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 13:46:50 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j3BHko39000837; Mon, 11 Apr 2005 13:46:50 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16986.47114.3567.477734@cnr.cs.columbia.edu> Date: Mon, 11 Apr 2005 13:46:50 -0400 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: 2nd and higher instance busted across time zone changes. In-Reply-To: <d3eb83$kas$1@sea.gmane.org> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> <d3eb83$kas$1@sea.gmane.org> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 17:46:52 -0000 On Monday, April 11 2005, "Michiel van Leeuwen" wrote to "ietf-calsify@osafoundation.org" saying: > Doug Royer wrote: > > Good point. We decided against 'M' (month) in PERIOD because it has > > a variable length > > > > We could eliminate 'W' and 'D' as they can get confusing for that > > reason. > > Isn't that exactly why you do need them? Without them, i don't see how > you set a duration of 1 day. Using 24 hours won't do, because 1 day > might be 25 hours. A duration of 1 day would mean: until the same time > the next day. What does DURATION:P1DT8H mean, then? Also, since this is calsify -- how do existing clients handle day-based durations (with or without hours) which cross an offset change? -- Jonathan Lennox lennox at cs dot columbia dot edu X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BHI3aa000467 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 10:18:05 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL2UN-0005x4-Uz for ietf-calsify@osafoundation.org; Mon, 11 Apr 2005 19:14:20 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:14:19 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 19:14:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Mon, 11 Apr 2005 19:16:35 +0200 Lines: 13 Message-ID: <d3eb83$kas$1@sea.gmane.org> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050407 In-Reply-To: <4259EF82.9070608@Royer.com> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: 2nd and higher instance busted across time zone changes. X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 17:18:06 -0000 Doug Royer wrote: > Good point. We decided against 'M' (month) in PERIOD because it has > a variable length > > We could eliminate 'W' and 'D' as they can get confusing for that > reason. Isn't that exactly why you do need them? Without them, i don't see how you set a duration of 1 day. Using 24 hours won't do, because 1 day might be 25 hours. A duration of 1 day would mean: until the same time the next day. Michiel X-Envelope-From: martijn@eekeek.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from amsfep18-int.chello.nl (amsfep18-int.chello.nl [213.46.243.13]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3BAgfaZ006480 for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 03:42:41 -0700 Received: from erebor.copa ([62.195.44.109]) by amsfep18-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050411104234.FUD1293.amsfep18-int.chello.nl@erebor.copa> for <ietf-calsify@osafoundation.org>; Mon, 11 Apr 2005 12:42:34 +0200 Received: from fangorn.copa ([192.168.123.11]) by erebor.copa with esmtp (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.34) id 1DKwNF-0001Te-1M for ietf-calsify@osafoundation.org; Mon, 11 Apr 2005 12:42:33 +0200 Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. From: Martijn van Beers <martijn@eekeek.org> To: ietf-calsify@osafoundation.org In-Reply-To: <4259EF82.9070608@Royer.com> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> <4259EF82.9070608@Royer.com> Content-Type: text/plain Date: Mon, 11 Apr 2005 12:44:04 +0200 Message-Id: <1113216244.4375.1.camel@fangorn.copa> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Mon, 11 Apr 2005 09:37:28 -0700 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 10:42:43 -0000 On Sun, 2005-04-10 at 21:31 -0600, Doug Royer wrote: > Good point. We decided against 'M' (month) in PERIOD because it has > a variable length > > We could eliminate 'W' and 'D' as they can get confusing for that > reason. Then you'd have to eliminate minute and hour too, since leap seconds make them variable length too. Martijn X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3B3VPaa008783 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 20:31:27 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3B3VFT7023181 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 20:31:20 -0700 Message-ID: <4259EF82.9070608@Royer.com> Date: Sun, 10 Apr 2005 21:31:14 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> <16985.59246.497875.226380@cnr.cs.columbia.edu> In-Reply-To: <16985.59246.497875.226380@cnr.cs.columbia.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060504050009070108000309" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 03:31:31 -0000 This is a cryptographically signed message in MIME format. --------------ms060504050009070108000309 Content-Type: multipart/mixed; boundary="------------000008000107050500060904" This is a multi-part message in MIME format. --------------000008000107050500060904 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > On Sunday, April 10 2005, "Sam Roberts" wrote to "ietf-calsify@osafoundation.org" saying: > > I think this *should* be a normative requirement; it's clearly the only > meaningful semantic for date-times with time zone references. > > Now, how this should be interpreted for floating date-times is another > question. Why do people use floating events? (I know why I use them) Do we need them ? > There's also the question of "does 1 day equal 24 hours", which was the > subject of a long thread on the ietf-calendar list (I think). Which is to > say, when does an event with DTSTART;TZID=America/New_York:20050403T000000 > and DURATION:P1D end? (Note to non-US readers: Sunday April 3 2005 was this > year's leap-forward date; 24 hours after 2005-04-03 00:00:00 EST is > 2005-04-04 01:00:00 EDT.) Good point. We decided against 'M' (month) in PERIOD because it has a variable length We could eliminate 'W' and 'D' as they can get confusing for that reason. I suspect that most have not noticed these issues because there is currently little cross vendor scheduling - yet. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------000008000107050500060904 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------000008000107050500060904-- --------------ms060504050009070108000309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDExMDMzMTE0WjAjBgkqhkiG9w0BCQQxFgQUGytuJZwDA4LXKbOc0n6I moz6kqcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAdvpLJhy7XvjI4Rc3Ur3kh1T4dMbOHk7LQk6Vfq0L1pkFJFrMYpiTjM2ajnAZOAgM IUl+r5ztZIDaTYbxqvgS5RcyKxYmdV1f7/sp6SVrf37NkXFyxj5YVs5PgObpFDwnuMlVyUi9 i2xYt+hU7J6khlUm80W40ddmS+35U2U51hfG1FG652CEgMCqptSDqcDK4M58sYrqn4S6sD82 qBurE7vd/29GtRiP4L4QPA3d3I5s+WZ42Yx4wdHoW1I+v4kq4sdWSKvcbtna7kC4TTPRMmS+ C2SNSTXuBs5X8v0+853EGGFcdBJryzyduLPXd1L2181ZIRh9jeOlZK6mHzo6WwAAAAAAAA== --------------ms060504050009070108000309-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3B3Ecaa007398 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 20:14:39 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3B3EVIY023064 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 20:14:33 -0700 Message-ID: <4259EB96.5080809@Royer.com> Date: Sun, 10 Apr 2005 21:14:30 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> In-Reply-To: <20050411014952.GA782@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070303020108030209080607" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 03:14:42 -0000 This is a cryptographically signed message in MIME format. --------------ms070303020108030209080607 Content-Type: multipart/mixed; boundary="------------000909020203010403010604" This is a multi-part message in MIME format. --------------000909020203010403010604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Roberts wrote: > Quoting lennox@cs.columbia.edu, on Sat, Apr 09, 2005 at 11:14:35PM -0400: > >>On Saturday, April 9 2005, "Doug Royer" wrote to "ietf-calsify@osafoundation.org" saying: >> >> >>>In CALSIFY I am proposing that we say that DURATION = DTEND - DTSTART >>>as the way to process RDATE and any 2445 RRULE found. It ~looks~ >>>to me as if that is how most implementations did it. >> >>That's certainly the simpler way to do it, and possibly the best-defined >>way. > > > But even saying DURATION = DTEND - DTSTART isn't sufficient. And yes - know to calculate duration. It looks like the way it is done most often is to subtract the end-time as seen by the user from the start-time as seen by the user and ignore all time shifts at the Organizer end. In many implementations when you select BY-MONTHLY, the CUA asks you if you mean by DATE or DAY-OF-MONTH. It has to because the CUA can not figure it out on its own. The same will have to be done for fixed END or fixed DURATION. Perhaps a little check box next to the end-time or duration values on the CUA. If the CU wants fixed end time, the CUA will have to create a DTSTART+DURATION for the 1st instance. And use RDATE/PERIOD-explicit for the 2nd and higher instances. If the CU wants fixed duration, create a DTSTART+DURATION. And use RDATE/PERIOD-start or the 2nd and higher instances. By always using DTSTART/DURATION and RDATE/PERIOD in CALSIFY, any object processed by a 2445 CUA will always create the time slots as expected by the CALSIFY Organizer. Because all start times and lengths are explicit and will not require any CUA (2445 or CALSIFY) to do any tz math. They will all get the same results. Why is RRULE busted - because if the 1st instance of a vevent is across a TZ shift, those that calculate the 2nd and higher instances might use the same duration, for all (1-up), or might notice the TZ and adjust (2-up). Inconsistent! And there is no way to tell what the Organizer intended. It looks to me as if implementations use the DTEND-DTSTART duration value of the 1st instances, even when it should be noticed as the exception. Or - if the Nth instance is across a TZ shift, implementations use the duration of the 1st instance. Resulting in a incorrect end time (if the organizer meant fixed end-time), or correct when the organizer meant a fixed duration. Inconsistent! The BY-HOUR, BY-MINUTE ... parts of an RRULE only specify the start time, not the Organizers intention of fixed end or fixed duration. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------000909020203010403010604 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------000909020203010403010604-- --------------ms070303020108030209080607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDExMDMxNDMwWjAjBgkqhkiG9w0BCQQxFgQUow1KCFQeJPr2WQMryNhW wYMUtWowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAQjTFXe0vEihP4gsHXcw4jhorTNXurgwXZc+/KW9sr6tEDgqS8We9H7Oe3cVtHhHX ZWW5HxwlNf89TElPXNI7b4CVabDh/iiKcmqu+pSRKCOVkdd94ywPAPNd3cmP2JVe+xyBS04m iWuD7L76m+tvOltDY3MRYLRBhyk1euT6SwlVgIiSR8pJV8Z0Hf7loJo07VVo/fFut/Ko6zsH 9RQII6nrXZLJbemCIgvc5R4ObvFsVSpZNb7cUCFnbbmnGp97qX6h9umB+5W6PnPK9qKZWFig uiPDDsHiriLhPY1ABzZXvtBLk2yUiFgVgeXv/9gQQj00OPBcK1HXq0gYW1hO2gAAAAAAAA== --------------ms070303020108030209080607-- X-Envelope-From: lennox@cnr.cs.columbia.edu X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3B2ulaa005245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 19:56:47 -0700 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j3B2uk4b023012 for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 22:56:46 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j3B2ukPI023009; Sun, 10 Apr 2005 22:56:46 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16985.59246.497875.226380@cnr.cs.columbia.edu> Date: Sun, 10 Apr 2005 22:56:46 -0400 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. In-Reply-To: <20050411014952.GA782@ensemble.local> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> <20050411014952.GA782@ensemble.local> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 02:56:49 -0000 On Sunday, April 10 2005, "Sam Roberts" wrote to "ietf-calsify@osafoundation.org" saying: > We need to specify how the subtraction is done when DTEND and DTSTART > straddle a time shift, and warn implementors to consider the issue I > think that the DURATION should be in *absolute* time. I.e., 10AM - 5AM > is 5 hours only if there really are 5 hours between them, and not 4 or 6 > hours (for example). > > I'm not suggesting this as some kind of a normative requirement, just > that it is easy to calculate offsets with absolute durations if you can > convert between localtime and UTC - and if you can't do that you'll be > in trouble. I think this *should* be a normative requirement; it's clearly the only meaningful semantic for date-times with time zone references. Now, how this should be interpreted for floating date-times is another question. There's also the question of "does 1 day equal 24 hours", which was the subject of a long thread on the ietf-calendar list (I think). Which is to say, when does an event with DTSTART;TZID=America/New_York:20050403T000000 and DURATION:P1D end? (Note to non-US readers: Sunday April 3 2005 was this year's leap-forward date; 24 hours after 2005-04-03 00:00:00 EST is 2005-04-04 01:00:00 EDT.) -- Jonathan Lennox lennox at cs dot columbia dot edu X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts36-srv.bellnexxia.net (tomts36-srv.bellnexxia.net [209.226.175.93]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3B1oOaZ001895 for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 18:50:24 -0700 Received: from ensemble.local ([70.50.63.29]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050411015021.CSTO16985.tomts36-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 21:50:21 -0400 Received: by ensemble.local (Postfix, from userid 501) id 8B416430C6F; Sun, 10 Apr 2005 21:49:52 -0400 (EDT) Date: Sun, 10 Apr 2005 21:49:52 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. Message-ID: <20050411014952.GA782@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16984.39451.946598.669379@cnr.cs.columbia.edu> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 01:50:27 -0000 Quoting lennox@cs.columbia.edu, on Sat, Apr 09, 2005 at 11:14:35PM -0400: > On Saturday, April 9 2005, "Doug Royer" wrote to "ietf-calsify@osafoundation.org" saying: > > > In CALSIFY I am proposing that we say that DURATION = DTEND - DTSTART > > as the way to process RDATE and any 2445 RRULE found. It ~looks~ > > to me as if that is how most implementations did it. > > That's certainly the simpler way to do it, and possibly the best-defined > way. But even saying DURATION = DTEND - DTSTART isn't sufficient. We need to specify how the subtraction is done when DTEND and DTSTART straddle a time shift, and warn implementors to consider the issue I think that the DURATION should be in *absolute* time. I.e., 10AM - 5AM is 5 hours only if there really are 5 hours between them, and not 4 or 6 hours (for example). This is easy to implement, since you can take DTSTART and DTEND and convert them to an absolute time scale, such as UTC, then do the subtraction there. You can do addition in UTC as well. I'm not suggesting this as some kind of a normative requirement, just that it is easy to calculate offsets with absolute durations if you can convert between localtime and UTC - and if you can't do that you'll be in trouble. Cheers, Sam X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts13-srv.bellnexxia.net (tomts13-srv.bellnexxia.net [209.226.175.34]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3B1OaaZ032601 for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 18:24:36 -0700 Received: from ensemble.local ([70.50.63.29]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050411012436.NPST25800.tomts13-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 21:24:36 -0400 Received: by ensemble.local (Postfix, from userid 501) id C9945430C0E; Sun, 10 Apr 2005 21:24:06 -0400 (EDT) Date: Sun, 10 Apr 2005 21:24:06 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. Message-ID: <20050411012406.GA751@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42588DC9.5050600@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 11 Apr 2005 01:24:40 -0000 Quoting Doug@royer.com, on Sat, Apr 09, 2005 at 08:22:01PM -0600: > > > Cyrus Daboo wrote: > > >The issue is that right now clients have to infer the end time of > >recurrence instances (after the first one) in some unspecified manner > >(2445 does not really explain), unless an RDATE with PERIOD values is > >used (the period explicitly gives both the start and the end). > > > >i.e. to remove any ambiguity the second instance could have been > >specified as: > > > >RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/20050410080000 > > > > (always end at 8 am local time) > > > >or: > > > >RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/20050410070000 > > > > (always run for 7 hours) > > > >depending on what was actually wanted. > > > > or > > RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/+PT8H > > or > > RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/+PT7H > > So, I think this means that RRULE is busted as it can > not fix the above problem. What do you mean by "RRULE is busted"? That example doesn't even have an RRULE in it. If you always want a fixed duration: DTSTART;TZID=US/Eastern:20050403000000 DURATION:+PT7H RRULE:FREQ=weekly Whats "busted"? > In CALSIFY I am proposing that we say that DURATION = DTEND - DTSTART > as the way to process RDATE and any 2445 RRULE found. It ~looks~ > to me as if that is how most implementations did it. > > And in CALSIFY I am proposing that we say you MUST use > RDATE/PERIOD because RDATE/DATE, RDATE/DATE-TIME and RRULE > are busted in such cases. Busted in which cases? The specific case of wanting fixed-end events as opposed to fixed-duration? Sam X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3AHGNaa003910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 10:16:25 -0700 Received: from ip6-localhost (doob.fam.tuwien.ac.at [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3AHGFU6023904; Sun, 10 Apr 2005 19:16:15 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: Cyrus Daboo <daboo@isamet.com>, ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time =?iso-8859-1?q?zone=09changes=2E?= Date: Sun, 10 Apr 2005 19:16:11 +0200 User-Agent: KMail/1.8 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> In-Reply-To: <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1127370.KXCXXn4jE4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504101916.13688.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 10 Apr 2005 17:16:27 -0000 --nextPart1127370.KXCXXn4jE4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 10. April 2005 03:59 schrieben Sie: > Hi Reinhold, > > --On Sunday, April 10, 2005 02:15:52 AM +0200 Reinhold Kainhofer > > <reinhold@kainhofer.com> wrote: > > 45 minutes after the 1st instance ended. (Take the rdate and simply add > > the difference between dtend and dtstart to it). > > No - you are missing the point. Lets explain this again a little > differently: > > Consider an event that occurs twice between the hours of 12 am and 8 am > local time (EST is used in my example). It occurs on two consecutive > Sundays. One of those Sundays involves a daylight savings change.=20 Ah, sorry. I didn't know that US/Eastern time switches to DST in April.=20 Everywhere here in Europe the DST changes occur on the last sunday in march= =20 and the last sunday in October. Basically, your problem just makes it clear what I meant by "But then, I'm = not=20 sure if there is really a unique way to calculate the DTEND=20 without using the duration..." in my mail on April 3=20 (http://lists.osafoundation.org/pipermail/ietf-calsify/2005-April/000483.ht= ml). Actually, as long as the frequency is >=3D daily in an RRULE (without a BYH= OUR=20 or BYMINUTE value), or no new time is given in an RDATE, the end time can b= e=20 taken from the original DTEND. But as soon as the start time changes compar= ed=20 to the first occurence, you're out of luck. The same problem happens with the date and leap years. And there it happens= =20 even without strange things like an RDATE with explicit time. Just take=20 weekly recurrence rules. How will you ever correctly calculate the end date= ,=20 since you only have the n-th day of the month available from the DTEND. But= =20 since you are using weekly recurrence, the only information that you have=20 available is the duration. E.g. take the event=20 DTSTART;VALUE=3DDATE:20040206 DTEND;VALUE=3DDATE:20040211 RRULE:FREQ=3DWEEKLY;INTERVAL=3D1;BYDAY=3DFR The occurences will be=20 =2D) Feb 6 - 10, 2004 =2D) Feb 13 - 17, 2004 =2D) Feb 20 - 24, 2004 And the next one creates the problems: It will be Feb 27 - March 2, 2004,=20 right (where you use the duration to calculate the end date)? The only=20 information that you can use here is the duration. So, only in some cases is it possible to use the real end date to obtain mo= re=20 information. In some cases only the duration is available. the question now= =20 is whether the standard should just use duration-based end date / times , o= r=20 whether it should be smart and describe when it's possible to use more=20 information about the end date/time and when one needs to use the duration.= =20 My guess is that the latter is quite tricky to get right and water-proof. Now take a monthly event: RRULE:FREQ=3DMONTHLY;INTERVAL=3D1;BYMONTHDAY=3D27 DTSTART;VALUE=3DDATE:20040127 DTEND;VALUE=3DDATE:20040203 If you want to take the end date from the DTEND (which is basically what is= =20 suggested on calsify), you'll have the following events: =2D) Jan 27 - Feb 2, 2004 (7 days) =2D) Feb 27 - March 2, 2004 (5 days) =2D) March 27 - April 2, 2004 (7 days) =2D) April 27 - May 2, 2004 (6 days) Okay, so this event has a varying duration. Now imagine an additional RDATE;VALUE=3DDATE:20040225 When will this occurence end? The only information that you have now availa= ble=20 is the duration. So, this problem is not restricted to RDATEs that give a different start ti= me=20 than the first occurence, but it also happens with date-only events. Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart1127370.KXCXXn4jE4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCWV9dTqjEwhXvPN0RAiL5AKDK0jV1EcDFo0Y9kUoamy2DYEF9JQCgoB+7 zu7bhYWwwXIwP7ApE2fBR7k= =VLXd -----END PGP SIGNATURE----- --nextPart1127370.KXCXXn4jE4-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3ADgwaZ025545 for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 06:42:58 -0700 Received: from ensemble.local ([65.95.224.30]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050410134257.SAJJ21470.tomts22-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 09:42:57 -0400 Received: by ensemble.local (Postfix, from userid 501) id 8CC0743091F; Sun, 10 Apr 2005 09:42:27 -0400 (EDT) Date: Sun, 10 Apr 2005 09:42:27 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. Message-ID: <20050410134227.GB472@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> <20050406040534.GB589@ensemble.local> <42558BB6.9090307@Royer.com> <20050408032450.GA530@ensemble.local> <4255FFA7.4040001@Royer.com> <20050409161022.GB492@ensemble.local> <42584D1D.4090806@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42584D1D.4090806@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 10 Apr 2005 13:43:00 -0000 Quoting Doug@royer.com, on Sat, Apr 09, 2005 at 03:46:05PM -0600: > Sam Roberts wrote: Doug, this is a DTSTART/DTEND style example. You have said, unless I completely misunderstand, that even DTSTART/DURATION style specifications have a problem, perhaps even the same problem, and that it has something to do with floating times. This is what I haven't seen an example of. Thanks, Sam > > Start off with: > > DTSTART:20050402T150000 2-APR-2005 3pm > DTEND:20050403T180000 3-APR-2005 6pm > > Now add 2-APR-2006 and with a time: > > RDATE:20060402T154500 > > Notice that the RDATE value starts 45 minutes after the 1st instance. > > So at what time does the 2nd instance end ? > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > > We Do Standards - You Need Standards X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3A53iaa013358 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 22:03:45 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3A53aWd021576 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 22:03:39 -0700 Message-ID: <4258B3A8.4030702@Royer.com> Date: Sat, 09 Apr 2005 23:03:36 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org, ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> <16984.39451.946598.669379@cnr.cs.columbia.edu> In-Reply-To: <16984.39451.946598.669379@cnr.cs.columbia.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050809070808000302020304" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 10 Apr 2005 05:03:49 -0000 This is a cryptographically signed message in MIME format. --------------ms050809070808000302020304 Content-Type: multipart/mixed; boundary="------------050709090503080602010801" This is a multi-part message in MIME format. --------------050709090503080602010801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > On Saturday, April 9 2005, "Doug Royer" wrote to "ietf-calsify@osafoundation.org" saying: > > >>In CALSIFY I am proposing that we say that DURATION = DTEND - DTSTART >>as the way to process RDATE and any 2445 RRULE found. It ~looks~ >>to me as if that is how most implementations did it. > > > That's certainly the simpler way to do it, and possibly the best-defined > way. > > However, I don't think it satisfies the principle of least astonishment. If > a work shift always goes from midnight to eight a.m., the usual cultural > convention is that you have a seven hour shift on the clocks-forward day, and > a nine hour shift on the clocks-backward day. > I think a more intuitive resolution rule is as follows: > > 1. If the RDATE or RRULE instance falls at a different time of day than > DTSTART, DURATION = DTEND - DTSTART always. I assume you mean the 'time' part of a date-time. > 2. However, if an RDATE or instance of an RRULE falls at the same time of > day (in the relevant time zone, ignoring offset shifts) as DTSTART, then > the end of the recurrance instance falls at the same time of day as > DTEND, even if this would mean that the event has greater or lesser > duration. If starting from scratch that would be logical. However the implementations I tested did not generate their data using that procedure, so there would be a larger number of data conversion errors when moving to CALSIFY data. I have tested only a handful of implementations. I just tested this with Outlook 2003 on a 2000 exchange server and local (non-exchange) calendars. Using Outlook 2003 I set it from 2-APR-2005 -> 4-APR-2005, yearly by date. All instances are exactly 2 days long (48 hours), They display end time, yet they seem to use duration based on the users end time entered. Outlook calculates by duration (end-time - start-time and does NOT take time shits into account). I find that that is the way every implementations I have tested does it. Outlook also allows you to enter by duration, when you do it modifies the end time to match the duration. At least that gives correct answers for both 2005 and 2006 cases. All durations are equal. It looks to me as if they use DURATION and sometimes incorrectly display end-time. I have tried several start/end times and several start/durations. They all produce the same results. The duration is constant, not the real end time. I have not found an implementation that varies duration to take time shift into account. > ... > This definition is more complicated, but I think it reflects human > expectations better. The counter-argument for Calsify of "it's not how > existing clients do it" is a strong one, though. I think that even among the implementations that always generate DTSTART/DTEND, they generate their 2nd and higher instances with duration. > Either way, these semantics needs to be made explicit in whatever becomes > the updated definition of recurring events. YES! I wish I had more real data! -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------050709090503080602010801 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------050709090503080602010801-- --------------ms050809070808000302020304 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDEwMDUwMzM2WjAjBgkqhkiG9w0BCQQxFgQU1QgaWQSviX56vmK3hB+q cPXVh2owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAB1dGwxXFaNv4KzR13TE/q49SHjYCZhY5/+7nCfJTSpyNOuJbdUOSAifKkSUtz0XW DfccvYQ7L9W15c4/fr7ZOlFGMxxnjuYesahsAs2EVfmTDNPJCT08tn26O/rood5wMs5Z3HdV Qn/NiXGx8ofXci1s8Xf81HzoV3tnHNlJ5N37NZkX0gVORaD4y2m6StMWMTdESwUmM6fjCf7H LjBnOrIOb+LXFlHVqmsG3VV3IbowjBBl977FAQC8YLcYf14ccmMwnJnTK8Ywum3Pa2sYbz0F Ag81UhvDSQHGLMeQwCqteenRJYpW9L8P4eo53p3H4Dxs7r57Tu7XXa5Xpn6kgQAAAAAAAA== --------------ms050809070808000302020304-- X-Envelope-From: lennox@cnr.cs.columbia.edu X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3A3Eaaa007422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 20:14:37 -0700 Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id j3A3Eavj013567 for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 23:14:36 -0400 (EDT) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.1/8.13.1/Submit) id j3A3EaAR013564; Sat, 9 Apr 2005 23:14:36 -0400 (EDT) (envelope-from lennox) From: Jonathan Lennox <lennox@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16984.39451.946598.669379@cnr.cs.columbia.edu> Date: Sat, 9 Apr 2005 23:14:35 -0400 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. In-Reply-To: <42588DC9.5050600@Royer.com> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> <42588DC9.5050600@Royer.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 10 Apr 2005 03:14:38 -0000 On Saturday, April 9 2005, "Doug Royer" wrote to "ietf-calsify@osafoundation.org" saying: > In CALSIFY I am proposing that we say that DURATION = DTEND - DTSTART > as the way to process RDATE and any 2445 RRULE found. It ~looks~ > to me as if that is how most implementations did it. That's certainly the simpler way to do it, and possibly the best-defined way. However, I don't think it satisfies the principle of least astonishment. If a work shift always goes from midnight to eight a.m., the usual cultural convention is that you have a seven hour shift on the clocks-forward day, and a nine hour shift on the clocks-backward day. I think a more intuitive resolution rule is as follows: 1. If the RDATE or RRULE instance falls at a different time of day than DTSTART, DURATION = DTEND - DTSTART always. 2. However, if an RDATE or instance of an RRULE falls at the same time of day (in the relevant time zone, ignoring offset shifts) as DTSTART, then the end of the recurrance instance falls at the same time of day as DTEND, even if this would mean that the event has greater or lesser duration. 3. If the DTEND computed by rule 2 above doesn't exist (because it would fall during a clocks-forward period), or if it is ambiguous (because the time is repeated during a clocks-back period), fall back to rule 1. For clocks-back, this should always have DTEND being one of the repeated times; for clocks-forward, the end time in the new offset should be equivalent to the "proper" end time in the old offset. (Both of these conclusions assume sane DST rules, e.g. you don't have multiple transitions in a single 24-hour period.) The only surprising behavior with this rule would be when you have a rule whose base DTSTART-DTEND period spans an offset shift, *and* some RDATEs or RRULE instances fall at different times of day than DTSTART. This definition is more complicated, but I think it reflects human expectations better. The counter-argument for Calsify of "it's not how existing clients do it" is a strong one, though. Either way, these semantics needs to be made explicit in whatever becomes the updated definition of recurring events. -- Jonathan Lennox lennox at cs dot columbia dot edu X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3A2MAaa003775 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 19:22:11 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3A2M2lf020100 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 19:22:04 -0700 Message-ID: <42588DC9.5050600@Royer.com> Date: Sat, 09 Apr 2005 20:22:01 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> In-Reply-To: <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020809010403090000030105" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 10 Apr 2005 02:22:13 -0000 This is a cryptographically signed message in MIME format. --------------ms020809010403090000030105 Content-Type: multipart/mixed; boundary="------------020802090909000009040507" This is a multi-part message in MIME format. --------------020802090909000009040507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cyrus Daboo wrote: > The issue is that right now clients have to infer the end time of > recurrence instances (after the first one) in some unspecified manner > (2445 does not really explain), unless an RDATE with PERIOD values is > used (the period explicitly gives both the start and the end). > > i.e. to remove any ambiguity the second instance could have been > specified as: > > RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/20050410080000 > > (always end at 8 am local time) > > or: > > RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/20050410070000 > > (always run for 7 hours) > > depending on what was actually wanted. > or RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/+PT8H or RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/+PT7H So, I think this means that RRULE is busted as it can not fix the above problem. In CALSIFY I am proposing that we say that DURATION = DTEND - DTSTART as the way to process RDATE and any 2445 RRULE found. It ~looks~ to me as if that is how most implementations did it. And in CALSIFY I am proposing that we say you MUST use RDATE/PERIOD because RDATE/DATE, RDATE/DATE-TIME and RRULE are busted in such cases. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020802090909000009040507 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020802090909000009040507-- --------------ms020809010403090000030105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDEwMDIyMjAxWjAjBgkqhkiG9w0BCQQxFgQUZTn3gHHPEP/jbfpDMO5Q ek97tSMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAtw85LGQfIh0ScY061CFRFgE6zgee3y68wpdWFxS+trUi6BkHN0quZeBt21t5Jbts s5NV3QyEQoYjAEn2WCijh5dBWlYh8ss8HH5RAHpeogd28rEEnyUdp37YRq0sVIhbh8K7sMqr XmNp/w5/ymkXZIwSpqFR3OMtVJrZ/568y3NHjZJhto6N4cJXYgJ5qb5IygaSEaPTv2c/lnfY l/FDLEFkekwApO8H6CffdZkDMVVgITB7IlEJQX3x6UBQr/pToNw1gjW4bGpAo+OHfhscpv2S YVhIzz7l7pSxkzErCWB3Mg35Y6tZJY0XJpu5E0deuu8Oyxe5yU36GXShIpRRQwAAAAAAAA== --------------ms020809010403090000030105-- X-Envelope-From: daboo@isamet.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3A1xsaa002340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 18:59:55 -0700 Received: from [10.0.1.5] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j3A1gc6g028051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Apr 2005 21:42:40 -0400 Date: Sat, 09 Apr 2005 21:59:50 -0400 From: Cyrus Daboo <daboo@isamet.com> To: Reinhold Kainhofer <reinhold@kainhofer.com>, ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. Message-ID: <E7FD0B8D1CE1A8AE31D9313B@ninevah.cyrusoft.com> In-Reply-To: <200504100215.54082.reinhold@kainhofer.com> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> X-Mailer: Mulberry/4.0.0a8 (Linux/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 10 Apr 2005 01:59:55 -0000 Hi Reinhold, --On Sunday, April 10, 2005 02:15:52 AM +0200 Reinhold Kainhofer <reinhold@kainhofer.com> wrote: > 45 minutes after the 1st instance ended. (Take the rdate and simply add > the difference between dtend and dtstart to it). No - you are missing the point. Lets explain this again a little differently: Consider an event that occurs twice between the hours of 12 am and 8 am local time (EST is used in my example). It occurs on two consecutive Sundays. One of those Sundays involves a daylight savings change. So: Instance 1 (this is the one where DST changes): DTSTART;TZID=US/Eastern:20050403000000 DTEND;TZID=US/Eastern:20050403080000 Instance 2: RDATE;TZID=US/Eastern:20050410000000 Note that in instance 1 the clocks go forward an hour at 2 am. So the duration of the event is actually 7 hours as opposed to 8 hours. Using your algorithm ("Take the rdate and simply add the difference between dtend and dtstart to it") would result in the second instance ending at 7 am. Is that what was intended or should it end at 8 am? i.e. is the local end time supposed to be fixed or is the duration supposed to be fixed? You would have a similar problem if DURATION was used instead of DTEND. The issue is that right now clients have to infer the end time of recurrence instances (after the first one) in some unspecified manner (2445 does not really explain), unless an RDATE with PERIOD values is used (the period explicitly gives both the start and the end). i.e. to remove any ambiguity the second instance could have been specified as: RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/20050410080000 (always end at 8 am local time) or: RDATE;VALUE=PERIOD;TZID=US/Eastern:20050410000000/20050410070000 (always run for 7 hours) depending on what was actually wanted. -- Cyrus Daboo X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3A1pLaa001757 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 18:51:23 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3A1pETG019659 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 18:51:17 -0700 Message-ID: <42588691.1070207@Royer.com> Date: Sat, 09 Apr 2005 19:51:13 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> <200504100215.54082.reinhold@kainhofer.com> In-Reply-To: <200504100215.54082.reinhold@kainhofer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080306090601080306080103" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 10 Apr 2005 01:51:25 -0000 This is a cryptographically signed message in MIME format. --------------ms080306090601080306080103 Content-Type: multipart/mixed; boundary="------------080404070109000901090702" This is a multi-part message in MIME format. --------------080404070109000901090702 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reinhold Kainhofer wrote: > Am Sonntag, 10. April 2005 00:54 schrieb Doug Royer: > >>OOPS - I did not cut out all of what I sent - sorry, I did >>NOT mean to imply that sam said that!! >> >>I say and I ask: >> >> >>Start off with: >> >> DTSTART:20050402T150000 2-APR-2005 3pm >> DTEND:20050403T180000 3-APR-2005 6pm >> >>Now add 2-APR-2006 and with a time: >> >> RDATE:20060402T154500 >> >>Notice that the RDATE value starts 45 minutes after the 1st instance. >> >>So at what time does the 2nd instance end ? > > > 45 minutes after the 1st instance ended. (Take the rdate and simply add the > difference between dtend and dtstart to it). I agree. So Sam's example does not specify a fixed end time. It only happened to be an example and his statement about wanting a fixed end time is valid, however did not match his example. And as DTEND-DTSTART is the only way that always works to calculate the end time for a 2nd and higher instance, then it must also always be true that: DTEND - DTSTART always = DURATION Correct? The only way to specify a fixed end time for a 2nd and higher instance is with an RDATE of type PERIOD. Correct? And there is NO way to specify a fixed end time with RRULE. Correct? So again, I do not see that DTEND does anything except force the recipient to do the math each time for each 2nd and higher instance. The GUI can display the end TIME or DURATION, and the DATA itself only needs to be DURATION. If the Organizer wants a fixed end time, then DTSTART with DURATION for the 1st instance still works. And RDATE/PERIOID MUST BE used for each 2nd and higher instance. Correct? > Why should it make a difference that the first occurence hasn't yet ended? Note that the DATE was not the same as the 1st instance. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------080404070109000901090702 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------080404070109000901090702-- --------------ms080306090601080306080103 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDEwMDE1MTEzWjAjBgkqhkiG9w0BCQQxFgQU56dDWMPdsLy7Vv3ilNWh 4R9OWjUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAR8WVBp9X5Ne8Whl/mMMAa+BvPvWctVtuKfHu2qHSN8h7bLU8Nw94kdEVm9TAwGMK y7wIBC61bkINGbmaRimeLarbGvM31yV90EcpcMMBKILTB21ecd2247LPQp3Q6UQqtpfPh0Va u19vl9qciU0MH9N1nWXid6vHL7UUNpu0QyW65dfiD9DmJWBq/PMORni+0gtjW05v1iZO8/9C UCHNq/EqDlpYNCR/vrU88u7tSgYOtIUKnVk2OgG2MKUZyaWiOZVEjteBZ94F14BA/fnmvTs0 0F0y4hznPd1odUAjG+PeBYV9jNwMk6ViA5y1c1ItNbNzb6ASn9i7YJmMKKHVkwAAAAAAAA== --------------ms080306090601080306080103-- X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3A0Fvaa026550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 17:15:59 -0700 Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j3A0Ftvc024725 for <ietf-calsify@osafoundation.org>; Sun, 10 Apr 2005 02:15:56 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. Date: Sun, 10 Apr 2005 02:15:52 +0200 User-Agent: KMail/1.8 References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <42584D1D.4090806@Royer.com> <42585D2A.3050402@Royer.com> In-Reply-To: <42585D2A.3050402@Royer.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart18254046.VJxPLOjJF2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504100215.54082.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 10 Apr 2005 00:16:03 -0000 --nextPart18254046.VJxPLOjJF2 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 10. April 2005 00:54 schrieb Doug Royer: > OOPS - I did not cut out all of what I sent - sorry, I did > NOT mean to imply that sam said that!! > > I say and I ask: > > > Start off with: > > DTSTART:20050402T150000 2-APR-2005 3pm > DTEND:20050403T180000 3-APR-2005 6pm > > Now add 2-APR-2006 and with a time: > > RDATE:20060402T154500 > > Notice that the RDATE value starts 45 minutes after the 1st instance. > > So at what time does the 2nd instance end ? 45 minutes after the 1st instance ended. (Take the rdate and simply add the= =20 difference between dtend and dtstart to it). Why should it make a difference that the first occurence hasn't yet ended?= =20 E.g. image the planning (or the publication) of museum tours. If you have m= ore=20 than one tour guides, the second tour can alreaday start before the first o= ne=20 ended. All tours will provide the same information, and the name of the gui= de=20 shouldn't be in the published information at all, so you can just create on= e=20 event and let it recur at whatever times the tours start. Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart18254046.VJxPLOjJF2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCWHA6TqjEwhXvPN0RAj3nAJ9/jyC+EvUjFOWCL5vv00q3+x4tVwCeO3Fd mziXq+SZT75cQ2oExFUfQ98= =sW+R -----END PGP SIGNATURE----- --nextPart18254046.VJxPLOjJF2-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (royer.com [4.23.9.161]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j39Msdaa022022 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 15:54:41 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j39MsYca018225 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 15:54:36 -0700 Message-ID: <42585D2A.3050402@Royer.com> Date: Sat, 09 Apr 2005 16:54:34 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> <20050406040534.GB589@ensemble.local> <42558BB6.9090307@Royer.com> <20050408032450.GA530@ensemble.local> <4255FFA7.4040001@Royer.com> <20050409161022.GB492@ensemble.local> <42584D1D.4090806@Royer.com> In-Reply-To: <42584D1D.4090806@Royer.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010305070403080805080201" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sat, 09 Apr 2005 22:54:43 -0000 This is a cryptographically signed message in MIME format. --------------ms010305070403080805080201 Content-Type: multipart/mixed; boundary="------------090503020609070701000408" This is a multi-part message in MIME format. --------------090503020609070701000408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit OOPS - I did not cut out all of what I sent - sorry, I did NOT mean to imply that sam said that!! I say and I ask: Start off with: DTSTART:20050402T150000 2-APR-2005 3pm DTEND:20050403T180000 3-APR-2005 6pm Now add 2-APR-2006 and with a time: RDATE:20060402T154500 Notice that the RDATE value starts 45 minutes after the 1st instance. So at what time does the 2nd instance end ? Doug Royer wrote: > > > Sam Roberts wrote: > > > Start off with: > > DTSTART:20050402T150000 2-APR-2005 3pm > DTEND:20050403T180000 3-APR-2005 6pm > > Now add 2-APR-2006 and with a time: > > RDATE:20060402T154500 > > Notice that the RDATE value starts 45 minutes after the 1st instance. > > So at what time does the 2nd instance end ? > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------090503020609070701000408 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------090503020609070701000408-- --------------ms010305070403080805080201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDA5MjI1NDM0WjAjBgkqhkiG9w0BCQQxFgQUSwklcFNh713OBUIaNPwf lxZv1lQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAsNXSxk0LrdoY2565Zb6B4tYvU8fwdtVv0UYotfYje66SI+Ee5r6TCg2GYEr6AKpG qadc2W0qwfHoDY5nhH6LjkHhTwZDAxEvz8EkJcBjh1qtWoXXHlZ/jUE97knHgjy/ZEYbsQWN BczUmB5d6jMzzMzTXsS6zDRkLpm1tKTVvTjoHtsj96GIAmOrMH7VBzDLponbd/W/jmxe8MTo 9yD0RRjm5uxeSc6pID713FRQckiDpYl1eieXZCxtwde1TGq2gVuV/h6ocFzoG6kGIMbiMynU f8pjChjcCe2knm/sYlPWex8DHi38gGucfDxZWDV1pzLpLrwbxcdf/qSvsGvnqQAAAAAAAA== --------------ms010305070403080805080201-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j39LkBaa019084 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 14:46:13 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j39Lk682017669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 14:46:09 -0700 Message-ID: <42584D1D.4090806@Royer.com> Date: Sat, 09 Apr 2005 15:46:05 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> <20050406040534.GB589@ensemble.local> <42558BB6.9090307@Royer.com> <20050408032450.GA530@ensemble.local> <4255FFA7.4040001@Royer.com> <20050409161022.GB492@ensemble.local> In-Reply-To: <20050409161022.GB492@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080809050602060908010200" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sat, 09 Apr 2005 21:46:15 -0000 This is a cryptographically signed message in MIME format. --------------ms080809050602060908010200 Content-Type: multipart/mixed; boundary="------------080404010202010906040100" This is a multi-part message in MIME format. --------------080404010202010906040100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Roberts wrote: Start off with: DTSTART:20050402T150000 2-APR-2005 3pm DTEND:20050403T180000 3-APR-2005 6pm Now add 2-APR-2006 and with a time: RDATE:20060402T154500 Notice that the RDATE value starts 45 minutes after the 1st instance. So at what time does the 2nd instance end ? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------080404010202010906040100 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------080404010202010906040100-- --------------ms080809050602060908010200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDA5MjE0NjA1WjAjBgkqhkiG9w0BCQQxFgQUc2K0WRW6FNTRoQCnEG/I qcCfJqUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAprqLdI8UMd2l4PuXjNzpKLOLRDLWdKaQylavlw81tfwkFZStYgi3rz1wPJALdb6x SdHTOyO3UMEtPG/stDRmmSKYeJV1V2ZApEhDEje4SjLYtKY+JdQBE5ga60wb+ApF454MGxVs NtGT0RmJ9DXnE31tYUwnt/Og/MtrfzrGewzuetg7P1rcqr3f1lr9IwYfanhCxwx9R5g7Rt8c MjduTuf/X+TXFS4IBUsT9AAGPNNXszByAHUI+1QH4MhqrQHRUpI1Xgz/o7T2tS2JJfuOL3kI +qRMOCQO/848JouQDeUppWa5wU6fPJs0edk70foOUGf2Y5MJ8ULM/eB31DlhhgAAAAAAAA== --------------ms080809050602060908010200-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts22-srv.bellnexxia.net (tomts22-srv.bellnexxia.net [209.226.175.184]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j39GAraZ024301 for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 09:10:54 -0700 Received: from ensemble.local ([65.95.224.30]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050409161052.MNKH21470.tomts22-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sat, 9 Apr 2005 12:10:52 -0400 Received: by ensemble.local (Postfix, from userid 501) id 17F0E4302B5; Sat, 9 Apr 2005 12:10:23 -0400 (EDT) Date: Sat, 9 Apr 2005 12:10:22 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes. Message-ID: <20050409161022.GB492@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> <20050406040534.GB589@ensemble.local> <42558BB6.9090307@Royer.com> <20050408032450.GA530@ensemble.local> <4255FFA7.4040001@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4255FFA7.4040001@Royer.com> User-Agent: Mutt/1.5.0i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sat, 09 Apr 2005 16:10:56 -0000 Wrote Doug Royer <Doug@royer.com>, on Thu, Apr 07, 2005 at 09:51:03PM -0600: > Sam Roberts wrote: > > >p.s. RRULE is an incredibly powerful and useful part of iCalendar, I've > >implemented it, others have, and I'm not giving it up easily. Its > >biggest problem is it is very poorly documented, and this should be > >addressed by RFC2445bis. > > And as you have pointed out on this mailing list RRULE has > exactly the same problem with the 2nd and up instances > occur across time zone changes. Hey, I never said that! You've stated a few times now that RRULE can't work with floating events, even when specified with DTSTART/DURATION, but I don't think I've seen the problem described. Can you give an example detailing the problem you see, or comment on my example below? I do see a problem with RRULE and fixed-end time events (DTSTART/DTEND specified), the KDE developer clued me in to that problem. > Even if RRULE says, it still does not fix the repeating > floating event bug you found. > > This is NOT an RRULE, DTEND, DURATION, RDATE bug. > This is a bug in that 2445 does not document HOW > to define the end time (or duration) of the 2nd > and higher instance so that if they occur across > a time zone change, everyone displays the same > end time (or duration). "across a timezone change". Do you mean when I'm flying on a jet and cross a timezone, or do you mean a DST clock-shift? "everyone displays the same end time (or duration)" Recurring start and end times are either the same or not the same, depending on whether you consider 9AM in Paris to be the same time as 9AM in Toronto. Its not the same for the purposes of having a teleconference (so TZID must be published for a meeting), it is the same for the purposes of making sure you are at work on time (so TZID must NOT be published for these kind of events). What do you mean by "same"? > The problem is that NO RFC or draft currently tells > the implementor HOW to compute the end time or > duration of the 2nd and higher instances. It seems pretty clear to me, so either I'm assuming the intention of the RFC, or I'm missing something that I'd like you to clarify. Maybe you can point out where our understanding diverges below: If RRULE is FREQ=weekly, for ex, RFC2445 explains how to generate all the recurring start times from the DTSTART in the event. Agreed? All start times will be in either the local time zone (no TZID on the DTSTART), or in the timezone specified in the DTSTART. This is the floating/non-floating difference. Agreed? If DURATION specifies each occurence is 1 day (or 5 hours, or whatever), you add that duration to the 1st, 2nd, and later, occurence's start time. The end times, like the start times, are in the local timezone if the TZID is not specified ("floating"). Agreed? Of course, addition of the duration is sensitive to DST shifts, as well as to leap years, etc. So, start=5AM + duration=5hours is not necessarily end=10AM. If the duration is 5 hours, it has to *be* 5 hours of elapsed time. Or, is it possible where this is where we diverge? That you think this isn't specified adequately or at all in RFC2445? Cheers, Sam -- Sam Roberts <sroberts@certicom.com> X-Envelope-From: Chris_Stoner@notesdev.ibm.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j38JhgaZ022467 for <ietf-calsify@osafoundation.org>; Fri, 8 Apr 2005 12:43:42 -0700 In-Reply-To: <4210D4F3.9070405@cse.ucsc.edu> Subject: Re: [Ietf-calsify] Re: Comments on radical simplification and bumping the version To: ietf-calsify@osafoundation.org X-Mailer: Lotus Notes Build V70_03312005NP March 31, 2005 Message-ID: <OF4D1C9E07.030FB75E-ON85256FDD.006C3E91-85256FDD.006CCC3D@notesdev.ibm.com> Date: Fri, 8 Apr 2005 15:43:30 -0400 X-Disclaimed: 1 From: Chris_Stoner@notesdev.ibm.com X-MIMETrack: CD-MIME by Router on Capricorn/Iris(Build V70_M4_12222004 Beta 3|December 22, 2004) at 04/08/2005 03:38:31 PM, CD-MIME complete at 04/08/2005 03:38:32 PM, Itemize by Router on Capricorn/Iris(Build V70_M4_12222004 Beta 3|December 22, 2004) at 04/08/2005 03:38:32 PM, Serialize by Router on Capricorn/Iris(Build V70_M4_12222004 Beta 3|December 22, 2004) at 04/08/2005 03:38:32 PM, Serialize complete at 04/08/2005 03:38:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.552 () DNS_FROM_RFC_ABUSE,NO_REAL_NAME X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 08 Apr 2005 19:43:43 -0000 In trying to get caught up, I didn't see where this thread left off. Maybe there was no consensus...? -CS X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j383p9aa009039 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Thu, 7 Apr 2005 20:51:11 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j383p4LZ001546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Thu, 7 Apr 2005 20:51:06 -0700 Message-ID: <4255FFA7.4040001@Royer.com> Date: Thu, 07 Apr 2005 21:51:03 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> <20050406040534.GB589@ensemble.local> <42558BB6.9090307@Royer.com> <20050408032450.GA530@ensemble.local> In-Reply-To: <20050408032450.GA530@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030107090700010605020009" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] 2nd and higher instance busted across time zone changes. X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 08 Apr 2005 03:51:13 -0000 This is a cryptographically signed message in MIME format. --------------ms030107090700010605020009 Content-Type: multipart/mixed; boundary="------------020605020801090600070207" This is a multi-part message in MIME format. --------------020605020801090600070207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Roberts wrote: > p.s. RRULE is an incredibly powerful and useful part of iCalendar, I've > implemented it, others have, and I'm not giving it up easily. Its > biggest problem is it is very poorly documented, and this should be > addressed by RFC2445bis. And as you have pointed out on this mailing list RRULE has exactly the same problem with the 2nd and up instances occur across time zone changes. Even if RRULE says, it still does not fix the repeating floating event bug you found. This is NOT an RRULE, DTEND, DURATION, RDATE bug. This is a bug in that 2445 does not document HOW to define the end time (or duration) of the 2nd and higher instance so that if they occur across a time zone change, everyone displays the same end time (or duration). If we KEEP RRULE - NOTHING is fixed! If we KEEP DTEND - NOTHING is fixed! The 2445 bug you found still exists and still there is NO interoperable way to do repeating floating or non-floating events and ensure that all implementations calculate and display the same end time (or duration) for the 2nd and higher instances when it occurs across a time zone change. The problem is that NO RFC or draft currently tells the implementor HOW to compute the end time or duration of the 2nd and higher instances. That is what my 01:36PM 7-APR is trying to resolve. It is a solution to the 2445 bug you found. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020605020801090600070207 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020605020801090600070207-- --------------ms030107090700010605020009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDA4MDM1MTAzWjAjBgkqhkiG9w0BCQQxFgQUzoEROQIC04DFDXppBM5J CWjcnHEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAYx9Qi/nds8+xpgQr9TNaOUfsUSGfbH9Ez6xi4g/8Y0TuUL/C3mzizocA0Y2MAlJz b+UIpy5+s7PR8NytxUkdnREgPbRaWzxDBt5k4wGY+Nuya1Fdu3EyuC4YYDvPg+tlRn8kr5+j Z8qmJMiBhjjJs+UxQeRCtEfjdseVoA9+/dzHElOkNbXEIwt+WoShsUsCROwFYQfRBLSuXQ3u SS77iN61C4p1QT2LSVEzkdB8btzbYOD32Cbrx2gCXHjMwXuTGGYJ8SzAH3/rv8v6Sj5vMMNG cBJzEMAJX+Pjvloq1DqlrNllEa/gDguIKmzX+kQCuQEXe2k01sH0nK5rd/P6MgAAAAAAAA== --------------ms030107090700010605020009-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts22-srv.bellnexxia.net (tomts22-srv.bellnexxia.net [209.226.175.184]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j383PLaZ032219 for <ietf-calsify@osafoundation.org>; Thu, 7 Apr 2005 20:25:21 -0700 Received: from ensemble.local ([65.95.224.30]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050408032520.BMBR21470.tomts22-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Thu, 7 Apr 2005 23:25:20 -0400 Received: by ensemble.local (Postfix, from userid 501) id 7C35442F79E; Thu, 7 Apr 2005 23:24:50 -0400 (EDT) Date: Thu, 7 Apr 2005 23:24:50 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? Message-ID: <20050408032450.GA530@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> <20050406040534.GB589@ensemble.local> <42558BB6.9090307@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42558BB6.9090307@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Fri, 08 Apr 2005 03:25:23 -0000 Quoting Doug@royer.com, on Thu, Apr 07, 2005 at 01:36:22PM -0600: > > The real problem is that the viewer of a VEVENT > can not tell if the organizer meant that the end > time is fixed or if the duration is fixed for the > 2nd and higher instances. > > How about this: Your proposal basically boils down to: a - specify that when dtstart/dtend is used, it is an alternate notation for period for the first recurrence b - explicitly list every single occurence with: - its duration - its end time - neither, in which case the occurence has the same duration as the first event This seems to assume the RRULE is some kind of anachronism, best replaced by RDATE. I get this general impression you feel this way from also from your draft, in which you chopped it out, and with all your recurrence examples, in which you laboriously write out the RDATE for each occurence instead of doing the simple "FREQ=weekly". Perhaps I misintepret your feelings about RRULE? In the calendars I've seen, RRULE is the most common way to express recurrence (I confess: I've never seen an RDATE, but that might because OS X iCal never outputs one, so its not a good basis to say its not widely deployed). Anyhow, my calendar is full of things that recur indefinitely. The encoding space used to represent a weekly recurring sunday event goes through the roof, I don't think forcing CUAs to manually encode them is such a great option. I'd like to see an approach that states that when DTSTART/DURATION is used with an RRULE, then each recurrence is of DURATION. When DTSTART/DTEND is used with an RRULE, then you do <....> to figure out the implied endtime of each recurrence. So, what can <...> be? I'll spend some time thinking about it this weekend. Cheers, Sam p.s. RRULE is an incredibly powerful and useful part of iCalendar, I've implemented it, others have, and I'm not giving it up easily. Its biggest problem is it is very poorly documented, and this should be addressed by RFC2445bis. X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j37Mnwaa022503 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Thu, 7 Apr 2005 15:49:59 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j37MnpX4030960 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Thu, 7 Apr 2005 15:49:54 -0700 Message-ID: <4255B90E.7010208@Royer.com> Date: Thu, 07 Apr 2005 16:49:50 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> <20050406040534.GB589@ensemble.local> <42558BB6.9090307@Royer.com> <23414912231efac6ec9d494df1a9d20c@technorati.com> In-Reply-To: <23414912231efac6ec9d494df1a9d20c@technorati.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090901050904040003000307" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Thu, 07 Apr 2005 22:50:03 -0000 This is a cryptographically signed message in MIME format. --------------ms090901050904040003000307 Content-Type: multipart/mixed; boundary="------------020600050506040000040906" This is a multi-part message in MIME format. --------------020600050506040000040906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Tantek =C7elik wrote: > On Apr 7, 2005, at 12:36 PM, Doug Royer wrote: >=20 >> Did I miss any other options ? >=20 >=20 > So, for practical purposes, the concepts that DURATION and DTEND=20 > represent don't mean the same thing, and attempting to excise one will = > simply mean that you can't represent some real world situations. Sure you can, use explicit start/end or start/duration in the 2nd and up instances. Currently everyone just makes a guess when looking at the data. Is the duration constant? or is the end time constant? Once the CUA tags the data as explicit start/end then the Attendee CUA does not have to make a guess. >=20 > With all due respect, if this translates into the user having to know=20 > when a shift crosses a time zone boundary and make adjustments=20 > accordingly, this is ridiculous. And if the CUA doesn't automatically = > "do the right thing", then the user (or others involved with the event)= =20 > will be quite upset -- see previous emails on the thread. Our first goal has to be able to tell just looking at the data. Currently we can not tell, we just make a guess. Some guessed that end 'time' was constant, others guessed that duration was constant. > This is the problem with programmer-centered-solutions. You are asking= =20 > people (CU) to behave in a particular way in order to match the solutio= n. No, I am saying that currently no matter what the CUA/CU wants, the other end has to just make a guess. So *IF* the CUA/CU cares, then the data will need to reflect that choice. Right now it is valid to assume that duration is constant for the 2nd and higher instances. And it is valid to assume that the Organizer wants you to use the DTEND 'time' part appended to the RDATE value. However NETHER is documented. So no matter what the CUA/CU wants, no matter what assumptions were made by ether ends CUA implementor, the Attendee's CUA may get a different answer than the Organizer's CUA. If I say that I want it to start and 1am and end at 2am. I as as user am talking about wall clock time. And as there is no documented way to arrive at the end time for the 2nd instance then we do not have interoperability. > Your last sentence clearly points out the problem when you say "CU MUST= ". >=20 > "CUA MUST" is greatly preferable to "CU MUST", and every "CU MUST" is a= =20 > likely usability problem. By that I mean if the CUA/CU does not, then the Attendee will not have a clue and the Attendee CUA will have to guess which method to use. As a human we want end times or duration. The Organizer CUA needs to explicitly and unambiguously tell the Attendee's what time slot is being used or requested when the iCal object is generated. If implementation 'A' always uses RDATE value=3DPERIOD 'period-explicit' that's fine. Now all CUA's know in an unambiguous way what time slice is being talked about. If implementation 'B' always uses RDATE value=3DPERIOD 'period-start' that's fine. Now all CUA's know in an unambiguous way what time slice is being talked about. If implementation 'C' always uses RDATE value=3DDATE or value=3DDATE-TIME= , then implementation 'A', 'B' AND 'C' just by looking at the iCal object has to guess if 'time' or 'duration' is constant in the 2nd and higher instances. And more importantly 'A' and 'b' show the SAME time slice 100% of the time to their users. And 'C' might not. Lets say I forgot that the time changed on a specific day in the future. So I using my CUA I say 1am-3am. That's fine and valid. Now is all I am saying that is if the CUA produces a RDATE value=3DPERIOD, then no-one has to guess about what the Organizer's CUA shows the Organizer. If I use RDATE value=3DDATE or value=3DDATE-TIME, then everyone has to guess if the Organizer knew about the time shift. They have to guess if the Organizer's CUA made the adjustment, or if they have to make the adjustment. So the Organizer CUA does not need to ask the user (however it can if the implementor wants). If it wants explicit start/end times that fine. Just tag the RDATE values that way. I think that if we use PERIOD only in RDATE, then it will not matter what the CUA/CU does. All users, Organizer and Attendees will treat the start/end the same. As soon as I did that I looked at all edge cases I could think of and did a feature and time slice matrix. There is a 100% overlap in duration vs dtend. To the data and the viewing Attendee's, it is always the same. The only time there is not an overlap is when one CUA uses DTEND-time as a constant and the other uses DTEND-DTSTART duration as a constant. And that's not a feature, that's a interoperability bug. --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020600050506040000040906 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020600050506040000040906-- --------------ms090901050904040003000307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDA3MjI0OTUwWjAjBgkqhkiG9w0BCQQxFgQUP9uiQ9jnNhU1/trfMRfl O2dRQr8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAnO+wBTMAKvN2KcKD9ZC2Q/vP/j4B+8SnCAuyuhPSxgQzIXmD5MxazcJ/RzCgk6nl OhyX+cSuT+a1brat+ql7H+46zV/AkOcSKbhU3sCzWaOXA2ooJLBlHheOUWkUT0bCspYjKfbE /Qsx0j+k6m8Off7uxht4M3zaw2zQyQLy8RLesegiH9u3AEMRE1ncRBhOEcHHeC0StHxM+Bls YGJh9oFAIZ2wQH+S0ZSBp6Sp1fnr63+mzblPLzVtDcQCWdnlQkhMcUchSPlulvLaaR4odLs5 qfJHfU3U/UPui3CasVgakUgOrEFWlSIzlTUirUjnLnhCFaUTGTrIcjDvHAwKPwAAAAAAAA== --------------ms090901050904040003000307-- X-Envelope-From: tantek@technorati.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from mail.technorati.com (mail.technorati.com [209.237.227.245]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j37Kvlaa001660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Thu, 7 Apr 2005 13:57:47 -0700 Received: from [10.0.1.3] (m206-184.dsl.tsoft.com [198.144.206.184]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.technorati.com (Postfix) with ESMTP id A4B012127E0 for <ietf-calsify@osafoundation.org>; Thu, 7 Apr 2005 13:58:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <42558BB6.9090307@Royer.com> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> <20050406040534.GB589@ensemble.local> <42558BB6.9090307@Royer.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23414912231efac6ec9d494df1a9d20c@technorati.com> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Tantek_=C7elik?= <tantek@technorati.com> Subject: Re: [Ietf-calsify] Re: dtend removed? Date: Thu, 7 Apr 2005 13:58:20 -0700 To: ietf-calsify@osafoundation.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Thu, 07 Apr 2005 20:57:50 -0000 On Apr 7, 2005, at 12:36 PM, Doug Royer wrote: > Did I miss any other options ? I think the problem here is one of perspective: programmer-centered-design vs. user-centered-design. > > I still think this means we can eliminate DTEND. If there is > exactly one instance, both DURATION and DTEND mean the same thing. Agreed, except they mean different things to people. Frankly, *people* treat events differently when they discuss them having a duration vs. having an end time. E.g. some events start at a certain time, e.g. 8pm and last 2 hours, and if the event starts late (8:15pm), it still lasts two hours, and ends up ending at 10:15pm. Other events start at a certain time, e.g. 8pm, and have a hard stop time, e.g. of 10pm, (e.g. a meeting room conflict, or a restaurant closing time etc.), so that if the event starts late (8:15pm) it still ends at 10pm. So, for practical purposes, the concepts that DURATION and DTEND represent don't mean the same thing, and attempting to excise one will simply mean that you can't represent some real world situations. The user-centered solution would ask the question of how do people treat duration and end time differently (if at all), and if so (e.g. as shown above), build the solution to take it into account. People's use cases drive the solution rather than the other way around. The programmer-centered-solution is what you wrote: > > When there is more than one instance, the originating CUA MUST > specify the start and duration (even if by end time) of each > additional instance. Once that is done, there is no point > in having a DTEND that can only be used for the 1st instance. > > I assert that if an Organize GUI and CU want explicit end times, > then the Organizer GUI and CU MUST set those for all instances. With all due respect, if this translates into the user having to know when a shift crosses a time zone boundary and make adjustments accordingly, this is ridiculous. And if the CUA doesn't automatically "do the right thing", then the user (or others involved with the event) will be quite upset -- see previous emails on the thread. This is the problem with programmer-centered-solutions. You are asking people (CU) to behave in a particular way in order to match the solution. Your last sentence clearly points out the problem when you say "CU MUST". "CUA MUST" is greatly preferable to "CU MUST", and every "CU MUST" is a likely usability problem. Tantek X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j37JaTaa012816 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Thu, 7 Apr 2005 12:36:31 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j37JaN7w028760 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Thu, 7 Apr 2005 12:36:26 -0700 Message-ID: <42558BB6.9090307@Royer.com> Date: Thu, 07 Apr 2005 13:36:22 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> <20050406040534.GB589@ensemble.local> In-Reply-To: <20050406040534.GB589@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080104010707040000060707" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Thu, 07 Apr 2005 19:36:34 -0000 This is a cryptographically signed message in MIME format. --------------ms080104010707040000060707 Content-Type: multipart/mixed; boundary="------------040205010207000009050409" This is a multi-part message in MIME format. --------------040205010207000009050409 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The real problem is that the viewer of a VEVENT can not tell if the organizer meant that the end time is fixed or if the duration is fixed for the 2nd and higher instances. How about this: (1) We only allow RDATE with a value type PERIOD. So we deprecate 'RDATE;VALUE=date:...,...' and we deprecate 'RDATE;VALUE=date=time:...,...' and only keep 'RDATE;VALUE=period:...,...' This eliminates all questions about if the Organizer meant that the end 'time' was fixed or the 'duration' of the event was fixed. And the above problem is also a probelm for RRULE and EXRULE! (2) To migrate RDATE non-PERIOD value types to RDATE PERIOD types: (2a) If the 2445 object has a DURATION, then any RDATE value be replaced by one that has an RDATE value type of 'period-start' giving all instances the same duration. (2b) If the 2445 object has a DTSTART of type 'date', then the RDATE values must be of type 'date'. (2c) If the 2445 object has a DTSTART of type 'date-time'. Then all RDATE values must be of type 'date-time'. (2c1) If the 2445 object has a DTSTART of type 'date-time'. And the RDATE values are type 'date'. Then convert assuming that the RDATE 'time' value is the same as the DTSTART 'time' value. (2d) If the 2445 object has a DTEND: Here is the part we have to decide based on what everyone does: (2d1) option (2d1-1): The 'time' part of the 2nd 'period-explicit' must be set to the 'time' part of DTEND. Giving it the same end 'time'. --> What happens when that makes the 2nd 'period-explicit' part equal to or before the 1st 'period-explicit' part? I think that we have to assume that the implementation meant duration is fixed and use 'period-start'. option (2d1-2): Subtract the DTEND value from the DTSTART value to get the meeting length. option (2d1-2a): Use an RDATE value type of 'period-explicit'. Set the 'time' part of the 2nd 'period-explicit' so that the RDATE instance has the same meeting length as the 1st instance. option (2d1-2b): Use an RDATE value type of 'period-start'. How many assumed that RDATE (and other) instances always had the same end 'time' as the 1st instance ? How many assumed that the RDATE (and other) instances always had the same duration as the 1st instance ? Did I miss any other options ? I still think this means we can eliminate DTEND. If there is exactly one instance, both DURATION and DTEND mean the same thing. When there is more than one instance, the originating CUA MUST specify the start and duration (even if by end time) of each additional instance. Once that is done, there is no point in having a DTEND that can only be used for the 1st instance. I assert that if an Organize GUI and CU want explicit end times, then the Organizer GUI and CU MUST set those for all instances. Are there any other edge cases I forgot about ? -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040205010207000009050409 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------040205010207000009050409-- --------------ms080104010707040000060707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDA3MTkzNjIyWjAjBgkqhkiG9w0BCQQxFgQUy+szE7F9YiUXF16YWwGF 9cs8s0EwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAh6LiGfcVDd3EmpvhevB0vpPZkDN7uTX6vpaCanA+2NMkmXoDZXsbiNrHVX1X3aSr 6SHHy9Bncy4Q3sD918BEYYaE9Vebo6ocW+45MgwIj+6X5ulnm/3Lr/K9nFSC8TX5p/qt2SVu hnT5NrWqR3aTiRQyAc7t5js4nW7V2BQB4LCN8goobf/cuJZ6uL16B2sMUpo37UBBUBA7xWuH VquQWKIgHaRiVnGUYdU+WXfhLHWPdPz595VeSJLHuaXrfvEXPuDs3TEv0kiGsYi4+TazzcQs ADYAYeiS4JOfugNWtRotmqybr1xJpFjqg6MXEvF5hFypSAy8hrdP+laI8a3A9QAAAAAAAA== --------------ms080104010707040000060707-- X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from smtp813.mail.sc5.yahoo.com (smtp813.mail.sc5.yahoo.com [66.163.170.83]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j36GxHaZ018583 for <ietf-calsify@osafoundation.org>; Wed, 6 Apr 2005 09:59:17 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.236.43.183 with plain) by smtp813.mail.sc5.yahoo.com with SMTP; 6 Apr 2005 16:36:21 -0000 Message-ID: <42540FFA.9080106@calconnect.org> Date: Wed, 06 Apr 2005 09:36:10 -0700 From: Dave Thewlis <Dave.Thewlis@calconnect.org> Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify list <ietf-calsify@osafoundation.org> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.245 (*) HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Calconnect Questionnaire on Recurrence - request responses by 11 April X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Wed, 06 Apr 2005 16:59:18 -0000 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> I would like to thank those who have already responded to our request last week to complete our Recurrence Questionnaire, and to ask for more responses. If you haven't responded, please do so -- the more implementations we have information about, the more valuable the results will be to everyone.<br> <br> We really need your responses by <b>Monday evening, 11 April</b>, as we want to start looking at the results later next week. <br> <br> You can find the questionnaire at<br> <br> <a class="moz-txt-link-freetext" href="http://www.calconnect.org/recurrencequestionnaire.html">http://www.calconnect.org/recurrencequestionnaire.html</a><br> <br> Please contact me with any questions.<br> <br> Dave Thewlis<br> Calconnect - The Calendaring and Scheduling Consortium<br> +1 707 840 9391<br> <a class="moz-txt-link-abbreviated" href="mailto:Dave.Thewlis@calconnect.org">Dave.Thewlis@calconnect.org</a><br> <a class="moz-txt-link-abbreviated" href="http://www.calconnnect.org">www.calconnnect.org</a><br> <br> </body> </html> X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts25-srv.bellnexxia.net (tomts25-srv.bellnexxia.net [209.226.175.188]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j36CWPaZ029543 for <ietf-calsify@osafoundation.org>; Wed, 6 Apr 2005 05:32:26 -0700 Received: from ensemble.local ([65.95.224.30]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050406123223.KIKG27245.tomts25-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Wed, 6 Apr 2005 08:32:23 -0400 Received: by ensemble.local (Postfix, from userid 501) id 809C342F268; Wed, 6 Apr 2005 00:05:34 -0400 (EDT) Date: Wed, 6 Apr 2005 00:05:34 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? Message-ID: <20050406040534.GB589@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 2.011 (**) DATE_IN_PAST_06_12, DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Wed, 06 Apr 2005 12:32:26 -0000 Quoting Chris_Stoner@notesdev.ibm.com, on Mon, Apr 04, 2005 at 01:39:24PM -0400: > I don't think I really understand the Use Case. Can you give me two > examples of nursing shifts that you cannot express in iCalendar? (or maybe > not sure if you can express in iCalendar) 2 shifts a day, every day, with no overlaps or breaks between: DTSTART;TZID=blah:... april 1, 00 AM DTEND;TZID=blah:april 1, 12AM RRULE:FREQ=daily DTSTART;TZID=blah:... april 1, 12 AM DTEND;TZID=blah:april 1, 12PM RRULE:FREQ=daily Works great the first day, but when the next day comes, how do you calculate the end of that occurence? The obvious way, calculating an implicit duration from the DTSTART/DTEND of the first day and adding that duration to all future occurences, will cause each shift to be 12 hours (assuming no DST oddities on the first day of the event). But, not all days have 24 hours in them. So some days will have hours not covered by a shift, and some will have hours covered twice. Other irregularities in the way we measure time cause similar symptoms, such as leap years. The solutions appears to be either: a - saying that DTEND is just another way of saying DURATION (this leads to Doug's suggestion of just deprecating DTEND and just putting the DURATION in, since there is no difference) b - outlaw RRULE, and allow only with RDATE which forces you to list every single occurence in the RDATE (imo, this can't be taken seriously) c - fix the problem if we can d - change to a different calendar, maybe the French revolutionary calendar? :-) e - ???? (c) would mean figuring out a way of having the above example "work". Personally, I think expressing events as having a start and stop time is a very common and human way of doing things, and so is worth supporting if possible. Nursing shifts is my example. If all you want to do with iCalendar is express customer meetings, then just stating DURATION is enough, but is the case of repeating shift work really such a fringe case that we can ignore it? Cheers, Sam X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j35LHTaa023049 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Tue, 5 Apr 2005 14:17:30 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j35LHLJm029495 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Tue, 5 Apr 2005 14:17:24 -0700 Message-ID: <42530061.3030201@Royer.com> Date: Tue, 05 Apr 2005 15:17:21 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) References: <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> <0268403586f07b20af6bd4273c27f79d@technorati.com> <42509217.10804@Royer.com> <20050404031813.GA8592@ensemble.local> <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <68B2E4564C63126CBF980094@ninevah.local> In-Reply-To: <68B2E4564C63126CBF980094@ninevah.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060300020404040802080703" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 05 Apr 2005 21:17:33 -0000 This is a cryptographically signed message in MIME format. --------------ms060300020404040802080703 Content-Type: multipart/mixed; boundary="------------050807040105050409040005" This is a multi-part message in MIME format. --------------050807040105050409040005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cyrus Daboo wrote: > Hi Lisa, > > --On April 3, 2005 22:26:16 -0700 Lisa Dusseault > <lisa@osafoundation.org> wrote: > >> I'm curious, are there any clients with UIs that are capable of making >> the distinction between those two kinds of user intent? >> > > I allow a user to choose whether to set an end time or a duration on an > event (the default for new events being duration). I had remembered this conversation from years ago. The real problem is that the RDATE's are invalid for the example. Solution below: This example shows that for DTEND events the same problem exists. Here I took Sam's example and tweak it a bit to show the real problem. His original example was in effect: DTSTART:20050402T150000 2-APR 3pm DTEND:20050403T180000 3-APR 6pm RDATE;VALUE-DATE:20060403 (Not sure you can mix dtstart:date-time with rrule:date, I thought I read that, but lets assume you can). Now change it to this and you will see the real issue: Start off with: DTSTART:20050402T150000 2-APR-2005 3pm DTEND:20050403T180000 3-APR-2005 6pm Now add 2-APR-2006 and with a time: RDATE:20060402T154500 So at what time does the 2nd instance end ? Notice that the RDATE value starts 45 minutes after the 1st instance. I think the answer is - undocumented. Solution: If you want an explicit end time for a repeating floating event, then RDATE's MUST always be a 'PERIOD' format. RDATE;VALUE=PERIOD:20060402T154500/20060403T180000 or RDATE;VALUE=PERIOD:20060402T154500/+PT14H15M That is the only way that repeating floating events can have a forced end time that is predictable. If you use DURATION and all of them have the same length, then RDATE of type PERIOD is not needed. If you use DURATION and they do not have the same length, the it also needs RDATEs of type PERIOD. Again two ways to do exactly the same thing. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------050807040105050409040005 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------050807040105050409040005-- --------------ms060300020404040802080703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDA1MjExNzIxWjAjBgkqhkiG9w0BCQQxFgQUaK15dJW/Kw2tBy406X1G clkqUqwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAMtDrJeP9RBjVDgeDomwgMTJeJEItJLt5opDpsSXUb8s4oK902kk7WnbjO0H7eUSS YPR+blr45MD0XDZa8Cdu0B+lvK6LMf/MESfx1pa49HoYRKDssU8gsLM2dS8X5SvMQwDKvJXP 4QSYkHjb0Qde1IVmUI4UzUfJ60KpefmGFBRBXK3hC8agR+sdVWethRLc+tNaXyPA95DBJ9Vv SCr73SfLGcNkgaIaKo6ElUwFXeoQct4mY28d39rJFnoEWVwmS28Gm5p7cooLuUIOAoCP3Eu1 qfZZmMDbpW9AeRVdnVvsLmkg3Lm0yey82sICU+Aq3suycSOE3vIDZ2NRGpYrFQAAAAAAAA== --------------ms060300020404040802080703-- X-Envelope-From: TimHare@comcast.net X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j352o1aZ031609 for <ietf-calsify@osafoundation.org>; Mon, 4 Apr 2005 19:50:02 -0700 Received: from thare.comcast.net (pcp03614075pcs.micske01.fl.comcast.net[68.84.31.33]) by comcast.net (rwcrmhc11) with SMTP id <2005040502495401300dta18e>; Tue, 5 Apr 2005 02:49:54 +0000 Message-Id: <6.2.1.2.0.20050404224350.01cda8e8@mail.comcast.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 04 Apr 2005 22:50:08 -0400 To: ietf-calsify@osafoundation.org From: Tim Hare <TimHare@comcast.net> Subject: Re: [Ietf-calsify] Re: dtend removed? In-Reply-To: <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@ notesdev.ibm.com> References: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Score: 1.75 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j352o1aZ031609 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Tue, 05 Apr 2005 02:50:03 -0000 Putting in my two (okay, maybe one-and-a-quarter) cents worth: It doesn't really matter that much, for calsify, what the UI can accept from, or express to, the user. The main goal of calsify should be to find what should pass from one piece of calendar code, whether it's a CUA or a CS, to another. If a UI supports incredibly complex definitions of appointments, whether using DTEND, DURATION, RRULEs, or whatever, the CUA/CS still needs to be able to pass it to another CUA/CS using whatever we determine the basic interoperability spec to be. For me, that means the use cases we should be discussing should not be UI-dependent. At 01:39 PM 4/4/2005, Chris_Stoner@notesdev.ibm.com wrote: >I don't think I really understand the Use Case. Can you give me two >examples of nursing shifts that you cannot express in iCalendar? (or maybe >not sure if you can express in iCalendar) > >We (Notes) might be able to express this in our UI in release 6 going >forward if this is what I think it is... >Thanks- >CS > > >ietf-calsify-bounces@osafoundation.org wrote on 04/04/2005 01:26:16 AM: > > > I'm curious, are there any clients with UIs that are capable of making > > the distinction between those two kinds of user intent? > > > > Lisa > > > > On Apr 3, 2005, at 8:18 PM, Sam Roberts wrote: > > > > > Quoting Doug@royer.com, on Sun, Apr 03, 2005 at 07:02:15PM -0600: > > >> Tantek Çelik wrote: > > >>> +1 > > >>> > > >>> I concur with Sam's examples and conclusions. > > >>> > > >>> If interoperability is the primary goal of this endeavor rather than > > >>> theoretical reductionist simplification, then we should keep DTEND. > > >> > > >> The only thing proved is that nether DTEND or DURATION solves > > >> the problem. > > >> > > >> The real problem he found was that there is no one way > > >> to solve the problem of floating time events that > > >> occur access a time zone change. > > > > > > DURATION is a good solution for fixed-duration events. > > > > > >> We need to define the TZ math rules in the spec. Even > > >> with DTEND, it sill does not work all of the time. > > > > > > DTEND is the beginning of the solution for fixed-end events. It has > > > problems, they should be fixed. > > > > > > Saying there is no way in iCalendar to represent very common event > > > occurences such as a work shift doesn't seem like it will broaden > > > acceptance. > > > > > > When a hospital wants to represent its nursing shifts as recurring > > > events, an iCalendar doesn't do it they have two choices: > > > > > > - throw iCalendar away, which would be a pity > > > - extend the meaning of iCalendars to support this > > > > > > This group should define the meaning of recurring events with DTEND, to > > > avoid ad-hoc implementations by implementors. > > > > > > Sam > > > > > > > > > _______________________________________________ > > > 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 > > >_______________________________________________ >Ietf-calsify mailing list >Ietf-calsify@osafoundation.org >http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Tim Hare Interested Bystander, Non-Inc. X-Envelope-From: Chris_Stoner@notesdev.ibm.com Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j34HdWaZ006914; Mon, 4 Apr 2005 10:39:32 -0700 In-Reply-To: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> Subject: Re: [Ietf-calsify] Re: dtend removed? X-Mailer: Lotus Notes Build V70_03312005NP March 31, 2005 Message-ID: <OF2EB55BA5.41F7ED81-ON85256FD9.0060D66B-85256FD9.006173EC@notesdev.ibm.com> Date: Mon, 4 Apr 2005 13:39:24 -0400 X-Disclaimed: 1 To: lisa@osafoundation.org From: Chris_Stoner@notesdev.ibm.com X-MIMETrack: CD-MIME by Router on Capricorn/Iris(Build V70_M4_12222004 Beta 3|December 22, 2004) at 04/04/2005 01:34:53 PM, CD-MIME complete at 04/04/2005 01:34:53 PM, Itemize by Router on Capricorn/Iris(Build V70_M4_12222004 Beta 3|December 22, 2004) at 04/04/2005 01:34:53 PM, Serialize by Router on Capricorn/Iris(Build V70_M4_12222004 Beta 3|December 22, 2004) at 04/04/2005 01:34:53 PM, Serialize complete at 04/04/2005 01:34:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0.552 () DNS_FROM_RFC_ABUSE,NO_REAL_NAME X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j34HdWaZ006914 Cc: ietf-calsify@osafoundation.org, ietf-calsify-bounces@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 04 Apr 2005 17:39:34 -0000 I don't think I really understand the Use Case. Can you give me two examples of nursing shifts that you cannot express in iCalendar? (or maybe not sure if you can express in iCalendar) We (Notes) might be able to express this in our UI in release 6 going forward if this is what I think it is... Thanks- CS ietf-calsify-bounces@osafoundation.org wrote on 04/04/2005 01:26:16 AM: > I'm curious, are there any clients with UIs that are capable of making > the distinction between those two kinds of user intent? > > Lisa > > On Apr 3, 2005, at 8:18 PM, Sam Roberts wrote: > > > Quoting Doug@royer.com, on Sun, Apr 03, 2005 at 07:02:15PM -0600: > >> Tantek Çelik wrote: > >>> +1 > >>> > >>> I concur with Sam's examples and conclusions. > >>> > >>> If interoperability is the primary goal of this endeavor rather than > >>> theoretical reductionist simplification, then we should keep DTEND. > >> > >> The only thing proved is that nether DTEND or DURATION solves > >> the problem. > >> > >> The real problem he found was that there is no one way > >> to solve the problem of floating time events that > >> occur access a time zone change. > > > > DURATION is a good solution for fixed-duration events. > > > >> We need to define the TZ math rules in the spec. Even > >> with DTEND, it sill does not work all of the time. > > > > DTEND is the beginning of the solution for fixed-end events. It has > > problems, they should be fixed. > > > > Saying there is no way in iCalendar to represent very common event > > occurences such as a work shift doesn't seem like it will broaden > > acceptance. > > > > When a hospital wants to represent its nursing shifts as recurring > > events, an iCalendar doesn't do it they have two choices: > > > > - throw iCalendar away, which would be a pity > > - extend the meaning of iCalendars to support this > > > > This group should define the meaning of recurring events with DTEND, to > > avoid ad-hoc implementations by implementors. > > > > Sam > > > > > > _______________________________________________ > > 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 X-Envelope-From: daboo@isamet.com Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j34ESWaa024185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2005 07:28:33 -0700 Received: from [10.0.1.4] (ninevah.cyrusoft.com [63.163.82.9]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j34EC86g005584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Apr 2005 10:12:09 -0400 Date: Mon, 04 Apr 2005 10:28:30 -0400 From: Cyrus Daboo <daboo@isamet.com> To: Lisa Dusseault <lisa@osafoundation.org>, Sam Roberts <sroberts@uniserve.com> Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) Message-ID: <68B2E4564C63126CBF980094@ninevah.local> In-Reply-To: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> References: <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> <0268403586f07b20af6bd4273c27f79d@technorati.com> <42509217.10804@Royer.com> <20050404031813.GA8592@ensemble.local> <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> X-Mailer: Mulberry/4.0.0a7 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 04 Apr 2005 14:28:35 -0000 Hi Lisa, --On April 3, 2005 22:26:16 -0700 Lisa Dusseault <lisa@osafoundation.org> wrote: > I'm curious, are there any clients with UIs that are capable of making > the distinction between those two kinds of user intent? > I allow a user to choose whether to set an end time or a duration on an event (the default for new events being duration). The client will then use DTEND or DURATION in the resulting VEVENT depedning on what the user used. When an event is edited, we detect whether DTEND or DURATION is present and set the UI fields accordingly. Thus if a user uses a duration in an event, when they come back to edit it they will see the duration active rather than the end time. Of course if some other client comes along and changes DURATION into DTEND, then we loose that state. -- Cyrus Daboo X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j34758aa006299 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Mon, 4 Apr 2005 00:05:09 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j34753d8002192 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Mon, 4 Apr 2005 00:05:05 -0700 Message-ID: <4250E71F.2030707@Royer.com> Date: Mon, 04 Apr 2005 01:05:03 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) References: <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> <0268403586f07b20af6bd4273c27f79d@technorati.com> <42509217.10804@Royer.com> <20050404031813.GA8592@ensemble.local> <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> In-Reply-To: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010702010301070707060309" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 04 Apr 2005 07:05:14 -0000 This is a cryptographically signed message in MIME format. --------------ms010702010301070707060309 Content-Type: multipart/mixed; boundary="------------020907000309070907050708" This is a multi-part message in MIME format. --------------020907000309070907050708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lisa Dusseault wrote: > I'm curious, are there any clients with UIs that are capable of making > the distinction between those two kinds of user intent? I can't find any that do both duration and dtend. All that I can find convert the 'other' one to the one they use for display. This repeating floating bug is a 2445 bug that we just found. I think we have to add it to the list of 2445 issues that need to be fixed in calsify. I do not think that repeating floating events can ever be fixed. The reason is they really are in a TZID, just a random unnamed TZID. And repeating events do not work without a TZ. Floating events can never repeat. And this is a bug that has nothing to do with DTEND or DURATION. Sam just pointed it out in what happened to be a DTEND discussion. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020907000309070907050708 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020907000309070907050708-- --------------ms010702010301070707060309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDA0MDcwNTAzWjAjBgkqhkiG9w0BCQQxFgQUoBlUaJn4NnpcBe8V6PQ9 M03WmwIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAJ5Kobf6Vps9Ee7mYkcUcFkENFsM4iVSQn0mMaCFZx22LJ75UEvHHu8CR5LvrB2XU 8k0uh/y+3gWm0FtEOCvXDNRghSWi2nflEsNhVyzTlVv1cWcwuZyYPaBbhbcYggK8qMHty8qV mcCMCKP0A1La8AQsh0qQVB7Sg5khcae+NYnLG9Oc7AsvGVND6V0N1LvbsG5KhjbJBNJVTYYb ICW+9VEq1j+DHwQ8t93i1pKahC457f1yO3Y9Q3FUnqOto2s7C2SSX65QmsgfgVXSGs90d1v5 oRkWMPnA1LvADAMje2xvVugu2f06lS/UEtXLY6sk0RZwTpm8SG2qcuxOWK1LRgAAAAAAAA== --------------ms010702010301070707060309-- X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.101] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j345Pvab027911 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 3 Apr 2005 22:26:17 -0700 In-Reply-To: <20050404031813.GA8592@ensemble.local> References: <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> <0268403586f07b20af6bd4273c27f79d@technorati.com> <42509217.10804@Royer.com> <20050404031813.GA8592@ensemble.local> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7914e895bbc685c1315fa5ac319343fe@osafoundation.org> From: Lisa Dusseault <lisa@osafoundation.org> Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) Date: Sun, 3 Apr 2005 22:26:16 -0700 To: Sam Roberts <sroberts@uniserve.com> X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j345Pvab027911 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 04 Apr 2005 05:26:28 -0000 I'm curious, are there any clients with UIs that are capable of making the distinction between those two kinds of user intent? Lisa On Apr 3, 2005, at 8:18 PM, Sam Roberts wrote: > Quoting Doug@royer.com, on Sun, Apr 03, 2005 at 07:02:15PM -0600: >> Tantek Çelik wrote: >>> +1 >>> >>> I concur with Sam's examples and conclusions. >>> >>> If interoperability is the primary goal of this endeavor rather than >>> theoretical reductionist simplification, then we should keep DTEND. >> >> The only thing proved is that nether DTEND or DURATION solves >> the problem. >> >> The real problem he found was that there is no one way >> to solve the problem of floating time events that >> occur access a time zone change. > > DURATION is a good solution for fixed-duration events. > >> We need to define the TZ math rules in the spec. Even >> with DTEND, it sill does not work all of the time. > > DTEND is the beginning of the solution for fixed-end events. It has > problems, they should be fixed. > > Saying there is no way in iCalendar to represent very common event > occurences such as a work shift doesn't seem like it will broaden > acceptance. > > When a hospital wants to represent its nursing shifts as recurring > events, an iCalendar doesn't do it they have two choices: > > - throw iCalendar away, which would be a pity > - extend the meaning of iCalendars to support this > > This group should define the meaning of recurring events with DTEND, to > avoid ad-hoc implementations by implementors. > > Sam > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j344Dgaa020372 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 21:13:43 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j344DMu2000318 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 21:13:39 -0700 Message-ID: <4250BEE2.4030508@Royer.com> Date: Sun, 03 Apr 2005 22:13:22 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calsify <ietf-calsify@osafoundation.org> Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) References: <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> <0268403586f07b20af6bd4273c27f79d@technorati.com> <42509217.10804@Royer.com> <20050404031813.GA8592@ensemble.local> In-Reply-To: <20050404031813.GA8592@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030505050907070005020003" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 04 Apr 2005 04:13:46 -0000 This is a cryptographically signed message in MIME format. --------------ms030505050907070005020003 Content-Type: multipart/mixed; boundary="------------050201040807090503090203" This is a multi-part message in MIME format. --------------050201040807090503090203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Sam Roberts wrote: > Quoting Doug@royer.com, on Sun, Apr 03, 2005 at 07:02:15PM -0600: >=20 >>Tantek =C7elik wrote: >> >>>+1 >>> >>>I concur with Sam's examples and conclusions. >>> >>>If interoperability is the primary goal of this endeavor rather than=20 >>>theoretical reductionist simplification, then we should keep DTEND. >> >>The only thing proved is that nether DTEND or DURATION solves >>the problem. >> >>The real problem he found was that there is no one way >>to solve the problem of floating time events that >>occur access a time zone change. >=20 >=20 > DURATION is a good solution for fixed-duration events. No it does not. If the other end displays an end time only. >>We need to define the TZ math rules in the spec. Even >>with DTEND, it sill does not work all of the time. >=20 > DTEND is the beginning of the solution for fixed-end events. It has > problems, they should be fixed. No, the problem is not fixed at the other end. Only at one end. The GUI that does the opposite is still going to have an incorrect value for repeating 'floating' events. > Saying there is no way in iCalendar to represent very common event > occurences such as a work shift doesn't seem like it will broaden > acceptance. DTEND and DURATION are irrelevant. GUI's do not do both. The problem persists. It looks like we have to eliminate all multiple time zone repeating events. With repeating events (RDATE) that are tied to UTC this does not happen. This problem exists in 2445, I just do not remember it being discovered before. It is a repeating 'floating' event problem that is independent of DURATION or DTEND. Two independent implementations at the endpoints can not be guaranteed to interoperate on those rare occasions. We will need to say that 'floating' events must not contain an RDATE property in order to avoid this problem. --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------050201040807090503090203 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------050201040807090503090203-- --------------ms030505050907070005020003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDA0MDQxMzIyWjAjBgkqhkiG9w0BCQQxFgQUkb3CHHScW7gCdlktyYUw 29/IzhUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEArMmlme3N+jDrVVCKtWVaASvX2IWNm4hgn9J2UdFf4vJ8g0OIDwXwdPXiuWvthAWN N6HPFuUDPQbTX3biYJC4ObzgFUduRnGtuCG8hG2sTDJGSAjxn1d+5ScDTuMpFU6gk5m2vg6y cuZCobO5dNtJluZ4lvcP8z7SegWDe+CHZ0nUXR3bpLkBcjz5p55vpbgIDm6Q7rvAWU26tq2Y aU+SE5KIFTkccUV65qtlaKCp89AuCRTfsZGCAKn4Z8SJvjCKRjH+r0peqGVDvZZdbl+89DJQ 9eGZkuu0dglRf8KKAk9J7s6ABMAD6ZzvB4H3ZILtsnErVB6HZvFhBuxsyb9qqQAAAAAAAA== --------------ms030505050907070005020003-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts40-srv.bellnexxia.net (tomts40-srv.bellnexxia.net [209.226.175.97] (may be forged)) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j343IiaZ017302 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 20:18:45 -0700 Received: from ensemble.local ([64.229.170.33]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050404031843.CCAJ27737.tomts40-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 23:18:43 -0400 Received: by ensemble.local (Postfix, from userid 501) id F39AF42E824; Sun, 3 Apr 2005 23:18:13 -0400 (EDT) Date: Sun, 3 Apr 2005 23:18:13 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) Message-ID: <20050404031813.GA8592@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> <0268403586f07b20af6bd4273c27f79d@technorati.com> <42509217.10804@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <42509217.10804@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j343IiaZ017302 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 04 Apr 2005 03:18:46 -0000 Quoting Doug@royer.com, on Sun, Apr 03, 2005 at 07:02:15PM -0600: > Tantek Çelik wrote: > >+1 > > > >I concur with Sam's examples and conclusions. > > > >If interoperability is the primary goal of this endeavor rather than > >theoretical reductionist simplification, then we should keep DTEND. > > The only thing proved is that nether DTEND or DURATION solves > the problem. > > The real problem he found was that there is no one way > to solve the problem of floating time events that > occur access a time zone change. DURATION is a good solution for fixed-duration events. > We need to define the TZ math rules in the spec. Even > with DTEND, it sill does not work all of the time. DTEND is the beginning of the solution for fixed-end events. It has problems, they should be fixed. Saying there is no way in iCalendar to represent very common event occurences such as a work shift doesn't seem like it will broaden acceptance. When a hospital wants to represent its nursing shifts as recurring events, an iCalendar doesn't do it they have two choices: - throw iCalendar away, which would be a pity - extend the meaning of iCalendars to support this This group should define the meaning of recurring events with DTEND, to avoid ad-hoc implementations by implementors. Sam X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j3412Laa007624 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 18:02:23 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3412GW1031138 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 18:02:18 -0700 Message-ID: <42509217.10804@Royer.com> Date: Sun, 03 Apr 2005 19:02:15 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) References: <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> <0268403586f07b20af6bd4273c27f79d@technorati.com> In-Reply-To: <0268403586f07b20af6bd4273c27f79d@technorati.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010202000106030808030005" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify <ietf-calsify@osafoundation.org> List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 04 Apr 2005 01:02:24 -0000 This is a cryptographically signed message in MIME format. --------------ms010202000106030808030005 Content-Type: multipart/mixed; boundary="------------070604030705080508070306" This is a multi-part message in MIME format. --------------070604030705080508070306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Tantek =C7elik wrote: > +1 >=20 > I concur with Sam's examples and conclusions. >=20 > If interoperability is the primary goal of this endeavor rather than=20 > theoretical reductionist simplification, then we should keep DTEND. The only thing proved is that nether DTEND or DURATION solves the problem. The real problem he found was that there is no one way to solve the problem of floating time events that occur access a time zone change. We need to define the TZ math rules in the spec. Even with DTEND, it sill does not work all of the time. --=20 Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------070604030705080508070306 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------070604030705080508070306-- --------------ms010202000106030808030005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDA0MDEwMjE1WjAjBgkqhkiG9w0BCQQxFgQU+0bY9aMzYuM+V7vC1dJH nkCSI1owUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAKYn9GRj0oT2O6o1c0wTwlRP09pu7Jydsuei5opzeAeKnrqE7btZo7K9uDwsJQXgZ OeDwuMMKVdTe4G606UZ0/694vz1f+f2FmZ9nm2RT9VFJE2b64xe59fu5j1l24c8zTRmnNLjt W7az/zPsvzja8KXkkL5ayjhNZpxboeMvpUjd+zkJ011O9svW6gl8G9GBx35JPPJOeMsu8JDe XR+61c3vmuX0j9xPXFW/U7HsRFgLCNIicos9XstMeEA1NIB/OrOJzsWP+oaqsScgYUlO/egZ +/bElH7Nqh3XJyy16mNDzNJd37jrMdaCgIKxABY8deDJPKv2N6XvfpP7sgmSzgAAAAAAAA== --------------ms010202000106030808030005-- X-Envelope-From: tantek@technorati.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from mail.technorati.com (mail.technorati.com [209.237.227.245]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j340mZaa006871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 17:48:35 -0700 Received: from [192.168.1.102] (adsl-63-195-114-133.dsl.snfc21.pacbell.net [63.195.114.133]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.technorati.com (Postfix) with ESMTP id D8CA92127AC; Sun, 3 Apr 2005 17:48:34 -0700 (PDT) In-Reply-To: <20050403152514.GA7838@ensemble.local> References: <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0268403586f07b20af6bd4273c27f79d@technorati.com> From: =?ISO-8859-1?Q?Tantek_=C7elik?= <tantek@technorati.com> Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) Date: Sun, 3 Apr 2005 17:49:09 -0700 To: Sam Roberts <sroberts@uniserve.com> X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j340mZaa006871 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Mon, 04 Apr 2005 00:48:37 -0000 +1 I concur with Sam's examples and conclusions. If interoperability is the primary goal of this endeavor rather than theoretical reductionist simplification, then we should keep DTEND. Thanks, Tantek P.S. The popular "iCal" built-in application on MacOSX generates DTEND. -- Tantek Çelik Senior Technologist, Technorati, Inc. On Apr 3, 2005, at 8:25 AM, Sam Roberts wrote: > Quoting Doug@royer.com, on Sun, Apr 03, 2005 at 01:02:48AM -0700: >> Sam Roberts wrote: >> > > I removed my example, and used yours, since it shows the problem with > the reductionist approach so well. > >> Lets say you work a 10pm - 6am work shift and are allowed >> to eat at 1am - 2am. > > The example above is a concise example of why both representations are > necessary, simply understood, and model different things. > > Case a: > > A shift of work: 10pm - 6am. This is when I work, those times being > in > my local timezone. Most days my shift will be 8 hours long, on > occaisonal days it will be 7, and on others it will 9. > > Maybe my company will pay me for the 8 hours on days I only work 7, > thats an accounting issue, not a scheduling issue. Either way, they > don't have two chairs at the security desk that I work at, there is no > point me standing there looking over the other guards shoulder. Our > shifts do not overlap, on any day. > > This is an example of when DTEND would be used. DTSTART is when I start > work, DTEND is when I end work, very simple, always right. > > > Case b: > > My lunch break: it is at 1 AM, and I am allowed 1 hour. I don't get > more or less. > > This is an example of when DURATION would be used. You still allow > this. > > To answer your questions: > >> Even with DTSTART and DTEND do you think your employer will allow you >> to take two hours in the rare cases that the TZID changes on those >> times? > > No, breaks have a DURATION, not a start time and end time. > > Your one size fits-all attitude would cause this problem, not fix it. > >> Would you accept the fact that on other rare dates you can't >> eat at all because the 1am-2am went away? > > So at 1AM, people set their clocks forward to 2am. But I set DURATION, > so 1 hour later is 3AM on this day, and I get the same time to eat > I get every other day. > > The above point would be valid if you had chose to allow only > dtstart/dtend. In which case I would be complaining about that, but the > above case works fine with DURATION. > >> Or do you have to be there 9 hours ether way? Or maybe 8 hours on rare >> dates, or 10 hours on rare dates. > > Exactly. > >> Will you accept the fact that you do not get paid for one of the hours >> because the TZID shifted back one hour? > > I may file a union greviance, but there isn't room for two people to > sit > at the guard desk, and there must be a guard there every hour of the > day, whether there are 23 or 25 hours in the day. > > How I get payed for this is a problem well outside of the scope of > iCalendar! Probably, I don't get paid enough. > >>> Your choice to prefer duration over dtend appears based on the >>> assumption >>> they can represent the same information. >> >> It can represent the same information. Just perhaps not in >> exactly one object. So ether way you have the multiple >> TZID across time shift problems. Few CUAs allow the user >> to select DTEND or DURATION. > > > You started off wanting to make things simple, and now you've > introduced > the need for multiple objects, sometimes? > > You started off by wanting to increase inter-operability, and now state > that half the implementations out there are non-compliant? > > >> THE REAL PROBLEM: >> >> YOUR-BOSS-CUA-WORK generates DURATION. >> YOUR-CUA-WORK generates DTEND. >> >> So your boss tells the company calendar you will be >> here 10 hours on that rare day when DURATION is >> longer. Saved as 'floating time' appointment. >> >> You read your company calendar with YOUR-CUA-WORK >> which converts a DURATION to a DTEND for display. It notices >> the TZID shift and subtracts out the hour to display >> the correct time and it uses the end time as the >> display time. >> >> Your fired - you left work early. >> >> Should your CUA have calculated the shift based on >> the start time? End time? Duration? Was your CUA >> busted? Your bosses CUA bused? > > If my boss specified I work for 8 hours his CUA should have encoded it > as he specified it (with dtstart/duration) - in which case I better > work > 8 hours. My CUA will add 8 hours of duration to the dtstart, do it > correctly for my timezone, and display when the event ends on that > particular day so I quit at the correct time. Anything else is wrong. > > If my boss specified that I work from 10PM to 6AM, his CUA should have > represented it as such, and my CUA better show my shift ending at 6AM. > > >> CALSIFY - lets all do it exactly one way. >> With DURATION all calculation have to be done relative >> to the start time. It has to, there is no end time. > > The world doesn't work in one way. > > Hospitals have 3 shifts a day, ending at fixed times, and not > overlapping. > > Offices have 1 shift, starting at 9AM, and we work for 8 hours, no > matter when the end time is after 8 hours. > > RFC2445 allows both to be trivially representable. > > Your draft makes one trivial, and the other has to be represented as 3 > objects. > > To generate a shift that goes from 10PM to 6AM, every sunday of the > year, I have to notice that timezone changes on some sundays, generate > one event with a duration of 8 hours, exclude that event on all days in > which timezone changes occur, then put two other events, one with a > duration of 7 hours, the other with a duration of 9, that occur on > single sundays in the year, the DST adjustment days. > >> NO CUA I have found says: >> "I know you specified an DTEND time, however the time shift occurs >> on that night, do you want to adjust it or not?" >> >> Same problem with DURATION: >> "I know you specified an DURATION, however the time shift occurs >> on that night, do you want to adjust it or not?" >> >> Your CUA can not tell why you entered the value. > > The CUA doesn't have to do this, it should represent it exactly as the > BOSS entered it. > > The problems you describe are all problems in conversion between the > two > kinds of natural events, those with a fixed end, and those with a fixed > duration. > > Since you propose to allow only one kind of representation, all the > problems you describe above occur. If you allow the two > representations, > they don't occur. > > This situation is CAUSED by your proposal, not fixed. > > And a CUA that only allows inputting start and duration is incapable of > allowing my boss to input my shift that starts at 10PM and ends at 6AM. > > This is a problem with that CUA, it is not a problem with RFC2445. Once > it's users complain, the CUA will implement events that end at a > specific time. > > If you mention this issue in RFC2445bis, people might implement it > correctly the first time. > >>> Are you sure this is the case? It sure doesn't look like it to me. > > 1 - > >> I still think so, again perhaps not in exactly one object. > > 2 - > >> I do think we need to reduce the number of ways to do >> exactly the same thing to 'one'. > > Statements 1 and 2 are in direct conflict. One says there will be "one > way" to represent an even, the other says that in cases of events > crossing > timezones the CUA will have to notice, and generate more than one > object. This is not "one way". > > > Why are you removing simple things that work well? > > There are things in RFC2445 that are complicated, this isn't one of > them, leave it alone. > > Sam > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from smtp812.mail.sc5.yahoo.com (smtp812.mail.sc5.yahoo.com [66.163.170.82]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j33MoDaZ031406 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 15:50:13 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.113.23 with plain) by smtp812.mail.sc5.yahoo.com with SMTP; 3 Apr 2005 22:50:13 -0000 Message-ID: <4250731E.6070007@calconnect.org> Date: Sun, 03 Apr 2005 15:50:06 -0700 From: Dave Thewlis <Dave.Thewlis@calconnect.org> Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo <daboo@isamet.com> Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify References: <1198328AFDBF5841B27E40C40C33153702D8693F@df-chewy-msg.exchange. corp.microsoft.com> <DD3329D1CEC8BB980104925F@ninevah.local> In-Reply-To: <DD3329D1CEC8BB980104925F@ninevah.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: Cameron Stillion <camerost@exchange.microsoft.com>, ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 22:50:13 -0000 I made it "YES" "NO" and "OTHER" which amounts to the same thing. Now up on the site. Cyrus Daboo wrote: > Hi Cameron, > > --On April 3, 2005 11:50:44 -0700 Cameron Stillion > <camerost@exchange.microsoft.com> wrote: > >> Just one little bug - or rather niggly - is that it is rather difficult >> in an HTML form to deselect all options in a set of radio buttons, >> therefore the approach of "don't select either" is somewhat problematic >> in the cases where you may have already chosen one (for whatever reason) >> - without completely resetting the form to try again. :) >> > > Right - I think what we need is a three-state choice: 'yes', 'no', > 'n/a' (not applicable for whatever reason - e.g. question about iTIP > but product does not implement iTIP at all). > X-Envelope-From: daboo@isamet.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33Mkjaa031310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 15:46:47 -0700 Received: from [10.0.1.4] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j33MUH6g020417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2005 18:30:20 -0400 Date: Sun, 03 Apr 2005 18:46:32 -0400 From: Cyrus Daboo <daboo@isamet.com> To: Cameron Stillion <camerost@exchange.microsoft.com>, Dave.Thewlis@calconnect.org Subject: RE: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify Message-ID: <DD3329D1CEC8BB980104925F@ninevah.local> In-Reply-To: <1198328AFDBF5841B27E40C40C33153702D8693F@df-chewy-msg.exchange.corp.microsoft.com> References: <1198328AFDBF5841B27E40C40C33153702D8693F@df-chewy-msg.exchange. corp.microsoft.com> X-Mailer: Mulberry/4.0.0a7 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 22:46:48 -0000 Hi Cameron, --On April 3, 2005 11:50:44 -0700 Cameron Stillion <camerost@exchange.microsoft.com> wrote: > Just one little bug - or rather niggly - is that it is rather difficult > in an HTML form to deselect all options in a set of radio buttons, > therefore the approach of "don't select either" is somewhat problematic > in the cases where you may have already chosen one (for whatever reason) > - without completely resetting the form to try again. :) > Right - I think what we need is a three-state choice: 'yes', 'no', 'n/a' (not applicable for whatever reason - e.g. question about iTIP but product does not implement iTIP at all). -- Cyrus Daboo X-Envelope-From: Doug@Royer.com Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33LHFaa026606 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Sun, 3 Apr 2005 14:17:16 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j33LH5FJ028281 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 3 Apr 2005 14:17:08 -0700 Message-ID: <42505D51.7070404@Royer.com> Date: Sun, 03 Apr 2005 15:17:05 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Roberts <sroberts@uniserve.com> References: <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> In-Reply-To: <20050403022715.GB7536@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010102060608050004010305" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org, CalDAV DevList <ietf-caldav@osafoundation.org>, "ietf-calendar@imc.org" <ietf-calendar@imc.org> Subject: [Ietf-calsify] Re: [Ietf-caldav] dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 21:17:18 -0000 This is a cryptographically signed message in MIME format. --------------ms010102060608050004010305 Content-Type: multipart/mixed; boundary="------------040500020902040002060007" This is a multi-part message in MIME format. --------------040500020902040002060007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This discussion belongs in CALSIFY - not CALDAV. Sam Roberts wrote: > Quoting Doug@royer.com, on Sun, Jan 16, 2005 at 02:11:43PM -0700: > >>I send -01 of iCal-Basis to the IETF. It fixed some problems and >>typos that were sent to me and the lists. It also deprecates DTEND and >>replaced the examples and ABNF with DURATION. > > > dtstart/dtend and dtstart/duration are equivalent ONLY for single > non-recurring events. > A yearly event on that starts at april second 3PM, and goes until > april 3 6PM will have different durations. This year it falls on > DST. The duration will be different next year. > > Anything starting on the 25th and going to the "-1th"/last day of the > month will have a different duration every month. Etc. > > It's also trivial to support doing the calculation of duration/dtend for > a specific event. > > Do you ever intend to support recurring events again? > > I just hours ago wrote a little server that publishes all the birthdays > in my address book as text/calendar over http, which is handy because my > calendar program now subscribes to it. Those birthdays recur! > > Sam > > > >>Copy at: >> >> http://inet-consulting.com/draft-royer-ical-basic-01.txt >> >>And HTML version at: >> >> http://inet-consulting.com/draft-royer-ical-basic-01.html >> >>-- >> >>Doug Royer | http://INET-Consulting.com >>-------------------------------|----------------------------- >>Doug@Royer.com | Office: (208)612-4638 >>http://Royer.com | Fax: (866)594-8574 >> | Cell: (208)520-4044 >> >> We Do Standards - You Need Standards >> > > > > _______________________________________________ > 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 -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040500020902040002060007 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------040500020902040002060007-- --------------ms010102060608050004010305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDAzMjExNzA1WjAjBgkqhkiG9w0BCQQxFgQUEgyEfHfu1gQIt83fzcNi eAQgwigwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAx3T9sssPdmnr5ob9mvMWWVCLAjtuHfnJ1Jmxaamor/OyEGJ0F3ncaXH7OcRhdgEW BHOP/iIt8IxAJDPEFJxV8uvogzQQ1QUSWT9FAz/dSrFFz65x8Op+ozrfV8nXIL/7jiJPYY7G dieFa4cUrzZj9hJ1ufkZW9/JjZDBj0bzQiqIwwDCRuEmqEZa/loVpWjbZhWt+Ovb+aONi7Xh c9q2gZWGPPljLKVYkRdl7Ci2gIp4Z3F8ObNWT0GOOxHzWP5gsKl5TIlGZ+QiSqpyljME1wp4 R/tsx19wFoGdlEjF491rv7ViITn1DV/5/JOQ7k8Yb0LSDIzBxXBTWOQAvmUoygAAAAAAAA== --------------ms010102060608050004010305-- X-Envelope-From: lisa@osafoundation.org Received: from [192.168.1.101] ([198.144.201.116]) (authenticated bits=0) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33L9daa026361 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 3 Apr 2005 14:09:52 -0700 In-Reply-To: <d2pc8u$n4h$1@sea.gmane.org> References: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> <d2pc8u$n4h$1@sea.gmane.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <62e171ed555d1dd13203784d99cf1fc9@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault <lisa@osafoundation.org> Subject: Re: [Ietf-calsify] Re: Proposed Charter Date: Sun, 3 Apr 2005 14:09:32 -0700 To: Michiel van Leeuwen <mvl@exedo.nl> X-Mailer: Apple Mail (2.619.2) X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 21:09:53 -0000 Hi Michiel, The existing calendar specifications (RFC2445) already have the ability to add extensions. Part of standard IETF practice is to have a way to register extensions. So this goal is part of being more rigorous about a solution that's already in place. thanks, Lisa On Apr 3, 2005, at 11:24 AM, Michiel van Leeuwen wrote: > Lisa Dusseault wrote: >> (3) Clarify the registration process for iCalendar extensions (i.e., >> the current core object specification only provides a template >> to register new properties). > > This looks like it is part of a possible solution, using extensions, > instead of a goal in itself. The goal is to solve interop issues, and > it might turn out that extensions are a solution. But using extensions > should not be the goal, so should not be in the charter imo. > (and i don't like the use of extensions, but that's another discussion) > > Michiel > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33Kiwaa025269 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 13:45:00 -0700 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j33KisKm027875 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 13:44:56 -0700 Message-ID: <425055C5.6030008@Royer.com> Date: Sun, 03 Apr 2005 14:44:53 -0600 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) References: <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> In-Reply-To: <20050403152514.GA7838@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000804020902060207020903" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 20:45:02 -0000 This is a cryptographically signed message in MIME format. --------------ms000804020902060207020903 Content-Type: multipart/mixed; boundary="------------020708030901050900050706" This is a multi-part message in MIME format. --------------020708030901050900050706 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Roberts wrote: > Quoting Doug@royer.com, on Sun, Apr 03, 2005 at 01:02:48AM -0700: > >>Sam Roberts wrote: >> > > > I removed my example, and used yours, since it shows the problem with > the reductionist approach so well. > > >>Lets say you work a 10pm - 6am work shift and are allowed >>to eat at 1am - 2am. > > > The example above is a concise example of why both representations are > necessary, simply understood, and model different things. No, it shows that nether is known to be what the Organizer wants some of the time. The real problem is unless they really understand TZ math across time zone changes, the USER can not tell the GUI what they really want. Some implementations generate DURATION all of the time. When they encounter a DTEND, they convert it to a DURATION for display. And in rare cases it does not reflect what the organizer wants. Some implementations generate DTEND all of the time. When they encounter a DURATION, they convert it to a DTEND for display. And in rare cases it does not reflect what the organizer wants. Ether we have to say that GUI's always allow the CU to specify a DURATION or DTEND and always display a DURATION or DTEND depending on what the Organizer generated. I do not think that this is going to happen. And most users will not understand when to use each one. Or we have to define how to correctly say or determine what the Organizer intended. Just looking at the iCal files is easy. However most (any?) GUI's do not generate both. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020708030901050900050706 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020708030901050900050706-- --------------ms000804020902060207020903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDAzMjA0NDUzWjAjBgkqhkiG9w0BCQQxFgQU1TyDPvfs1eUhLgfW107U nNmfjeYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEATVxiHHFQJn2iLFTYv2R/WhUPH7aRMnn0LK0mWZCTtH78FDGTA6zvCC8QuwAXWG2O yHczrCqy5oYqWbsRINrvrOrcOdyd52me4N8nrkT1zxD1AbiTct7zQoYZOV6DFcLVTmb1KRRJ +AO/tfi4vGXlnPMfmx9/GR46XwOxVRVzQQn0KO+GHxz8B9x1FMjQG2fsPO1JGgdn6xFH0xp8 wzkvFd4PpYUCo4ZyCcXGsgY+R2zqF5jcGJZXOn47b9u6Xx6yeLRXlmQK28GQMpIMB1zNjZsK VgGb61eMc0BPlBz0aKLNkmfbNJUIdNgbYSk5ihsVuUndEjDK6ReLGvY+NiJtAQAAAAAAAA== --------------ms000804020902060207020903-- X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from smtp817.mail.sc5.yahoo.com (smtp817.mail.sc5.yahoo.com [66.163.170.3]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j33KbhaZ024910 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 13:37:43 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.113.23 with plain) by smtp817.mail.sc5.yahoo.com with SMTP; 3 Apr 2005 20:37:43 -0000 Message-ID: <42505411.7090302@calconnect.org> Date: Sun, 03 Apr 2005 13:37:37 -0700 From: Dave Thewlis <Dave.Thewlis@calconnect.org> Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cameron Stillion <camerost@exchange.microsoft.com> Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify References: <1198328AFDBF5841B27E40C40C33153702D8693F@df-chewy-msg.exchange.corp.microsoft.com> In-Reply-To: <1198328AFDBF5841B27E40C40C33153702D8693F@df-chewy-msg.exchange.corp.microsoft.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.874 (*) HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY,URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 20:37:44 -0000 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Okay, the questionnaire has been de-niggled in this regard. There's now an "Other" option matched to each Yes/No. So if you can't answer either Yes or No you can answer Other and hopefully tell us why. Or leave the choice completely blank if you haven't already clicked something as Cameron points out.<br> <br> Cameron Stillion wrote: <blockquote cite="mid1198328AFDBF5841B27E40C40C33153702D8693F@df-chewy-msg.exchange.corp.microsoft.com" type="cite"> <pre wrap="">Just one little bug - or rather niggly - is that it is rather difficult in an HTML form to deselect all options in a set of radio buttons, therefore the approach of "don't select either" is somewhat problematic in the cases where you may have already chosen one (for whatever reason) - without completely resetting the form to try again. :) cameron -----Original Message----- From: <a class="moz-txt-link-abbreviated" href="mailto:ietf-calsify-bounces@osafoundation.org">ietf-calsify-bounces@osafoundation.org</a> [<a class="moz-txt-link-freetext" href="mailto:ietf-calsify-bounces@osafoundation.org">mailto:ietf-calsify-bounces@osafoundation.org</a>] On Behalf Of Dave Thewlis Sent: Sunday.03.April.2005 10.37 To: Cyrus Daboo Cc: <a class="moz-txt-link-abbreviated" href="mailto:ietf-calsify@osafoundation.org">ietf-calsify@osafoundation.org</a> Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify Cyrus, Reinhold, Sam, I've added some text to the questionnaire text as a result of the points that have been raised to try and make it clearer. First to make Cyrus' point about production and consumption, and second to say that if you can't reasonably answer either Yes or No, please leave the YES/NO question blank but explain issue in the comment area to help us understand. I hope this helps a bit. We'll still try to answer questions as they arise. Dave Cyrus Daboo wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi Reinhold, --On Sunday, April 03, 2005 06:31:27 PM +0200 Reinhold Kainhofer <a class="moz-txt-link-rfc2396E" href="mailto:reinhold@kainhofer.com"><reinhold@kainhofer.com></a> wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Does yes mean I comply on generation? That I fail on processing if the MUST is violated? If I try to recover from non-compliant calendars during decoding, does that make me a "no"? </pre> </blockquote> </blockquote> <pre wrap="">Strictly speaking the MUST in the specs refers to both consumption and </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">production of the relevant items - to be compliant you have to do both </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">correctly. So for the time being I think you should answer YES only if </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">you produce and consume the item correctly (or if your implementation only does one thing - i.e. just consumes - then answer YES to that if it conforms). Ignore any behaviour for non-compliant data being </pre> </blockquote> <pre wrap=""><!---->consumed. </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Also, I'd think an interesting question would be what FREQ values people have actually implemented. For example, I haven't implemented </pre> </blockquote> </blockquote> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">a FREQ of WEEKLY, or BYHOUR/MINUTE/SECONDS, or BYSETPOS. They are on </pre> </blockquote> </blockquote> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">my todo list, but since I haven't seen a calendar with these yet, </pre> </blockquote> </blockquote> <pre wrap="">FYI the technical committee is working on a second questionnaire that will list each of the syntactical elements for recurrences and ask yes/no questions for separately for 'consume' and 'produce' of those. I'm nor sure when we will have that available - in the meantime please </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">go ahead and fill out the current form if you've not already done so - </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">thanks. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">If nobody supported BYSETPOS it would be a candidate for removal from the update prior to standardization. If its just me, then I better implement it soon! </pre> </blockquote> <pre wrap=""> libkcal and thus all KDE applications also don't implement BYSETPOS </pre> </blockquote> </blockquote> <pre wrap=""><!---->yet. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">It's also on my to-do list, but I don't think I'll have the time to implement it in the short- or midterm future. </pre> </blockquote> <pre wrap=""> FYI my implementation is capable of consuming and producing BYSETPOS, though the UI limits the range that can be produced by the user. Implementing BYSETPOS was probably the hardest part of doing the rules </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">as it meant pretty much having to expand the entire possible set and then picking the ones matched in order to support negative BYSETPOS values. It makes incremental or iterative recurrence expansion hard to </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">do without keeping a lot of state information around. </pre> </blockquote> <pre wrap=""><!----> _______________________________________________ Ietf-calsify mailing list <a class="moz-txt-link-abbreviated" href="mailto:Ietf-calsify@osafoundation.org">Ietf-calsify@osafoundation.org</a> <a class="moz-txt-link-freetext" href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a> </pre> </blockquote> </body> </html> X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33JmsaZ021729 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 12:48:54 -0700 Received: from ensemble.local ([64.229.170.33]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050403194853.XYIP26128.tomts5-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 15:48:53 -0400 Received: by ensemble.local (Postfix, from userid 501) id EB5C142E39A; Sun, 3 Apr 2005 15:48:22 -0400 (EDT) Date: Sun, 3 Apr 2005 15:48:22 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Proposed Charter Message-ID: <20050403194822.GA8370@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> User-Agent: Mutt/1.5.6i X-Spam-Score: 2.429 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 19:48:55 -0000 I like this as a charter. I agree the icalendar extension registration kindof depends on a need for extensions, and that would be a new mechanism. I'd like to see work on clarifying what we have now first, and work on new stuff later. I'd like to clarify - I read this as meaning that we aren't going to start throwing stuff out of iCalendar if it has been implemented interoperably by several independent groups. Am I reading into it what I want to read, or is this what was intended? Cheers, Sam Quoting lisaatosafoundation.org, on Mon, Mar 28, 2005 at 09:55:45PM +0000: > Based on the discussion at the Calsify BOF in Minneapolis, a bunch of > us (those who volunteered at the time) have worked on the draft WG > charter below. > > Some notes: > - The iCalendar revision work, although it may be challenging work, > is at least well understood in terms of scope and deliverables. > - The transition work which I attempted to characterize in a separate > email is not so well scoped out and it's not clear yet what specific > proposals might emerge, if any, so this charter would need to be > revised when the specific proposals become clear or do not appear after > a period. > - The XML work which seemed to be supported in the BOF (but nobody > actually took consensus) was not supported in the group of people > working on this charter, so it appears as "out of scope". > > -- Lisa > > ---- > > Calendaring and Scheduling Standards Simplification (calsify) > > Chair(s): > TBD > > Applications Area Director(s): > > Ted Hardie <hardie@qualcomm.com> > Scott Hollenbeck <sah@428cobrajet.net> > > Mailing Lists: > > General Discussion: ietf-calsify@osafoundation.org > To Subscribe: > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/ > > Description of Working Group: > > The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, > and 2447 were released in November 1998, and further described in RFC > 3283. They were designed to progress the level of interoperability > between dissimilar calendaring and scheduling systems. The Calendaring > and Scheduling Core Object Specification, iCalendar, succeeded in > establishing itself as the common format for exchanging calendaring > information across the Internet. On the other hand, only basic > interoperability as been achieved between different scheduling > systems. > > The Calsify working group is chartered to: > > (1) Publish the interoperability issues that have arisen between > calendaring and scheduling systems, as well as document the usage of > iCalendar by other specifications. > > (2) Revise the Calendaring and Scheduling standards to advance the > state of interoperable calendaring and scheduling by addressing > the published interoperability issues. As far as it is possible, > the working group will ensure backwards compatibility with widely > deployed implementations and other specifications that use it. > > (3) Clarify the registration process for iCalendar extensions (i.e., > the current core object specification only provides a template > to register new properties). > > (4) Advance the Calendaring and Scheduling standards to Draft Standard. > > (5) Work on transition (upgrade or versioning) mechanisms for calendar > data exchange. > > Proposing an XML representation or transformation of iCalendar > objects is out of the scope of this working group. > > Goals and Milestones: > > TBD - Submit "Problems in Calendaring and Scheduling Standards". > TBD - Submit RFC2445bis. > TBD - Submit other revised documents. X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from smtp816.mail.sc5.yahoo.com (smtp816.mail.sc5.yahoo.com [66.163.170.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j33J0vaZ018865 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 12:00:57 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.113.23 with plain) by smtp816.mail.sc5.yahoo.com with SMTP; 3 Apr 2005 19:00:56 -0000 Message-ID: <42503D62.5090405@calconnect.org> Date: Sun, 03 Apr 2005 12:00:50 -0700 From: Dave Thewlis <Dave.Thewlis@calconnect.org> Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cameron Stillion <camerost@exchange.microsoft.com> Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify References: <1198328AFDBF5841B27E40C40C33153702D8693F@df-chewy-msg.exchange.corp.microsoft.com> In-Reply-To: <1198328AFDBF5841B27E40C40C33153702D8693F@df-chewy-msg.exchange.corp.microsoft.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.874 (*) HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY,URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 19:00:58 -0000 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> <br> All true. Maybe I need a "Neither" button. I don't want check boxes. I don't know if you CAN reset a button once selected actually. <br> <br> Cameron Stillion wrote: <blockquote cite="mid1198328AFDBF5841B27E40C40C33153702D8693F@df-chewy-msg.exchange.corp.microsoft.com" type="cite"> <pre wrap="">Just one little bug - or rather niggly - is that it is rather difficult in an HTML form to deselect all options in a set of radio buttons, therefore the approach of "don't select either" is somewhat problematic in the cases where you may have already chosen one (for whatever reason) - without completely resetting the form to try again. :) cameron -----Original Message----- From: <a class="moz-txt-link-abbreviated" href="mailto:ietf-calsify-bounces@osafoundation.org">ietf-calsify-bounces@osafoundation.org</a> [<a class="moz-txt-link-freetext" href="mailto:ietf-calsify-bounces@osafoundation.org">mailto:ietf-calsify-bounces@osafoundation.org</a>] On Behalf Of Dave Thewlis Sent: Sunday.03.April.2005 10.37 To: Cyrus Daboo Cc: <a class="moz-txt-link-abbreviated" href="mailto:ietf-calsify@osafoundation.org">ietf-calsify@osafoundation.org</a> Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify Cyrus, Reinhold, Sam, I've added some text to the questionnaire text as a result of the points that have been raised to try and make it clearer. First to make Cyrus' point about production and consumption, and second to say that if you can't reasonably answer either Yes or No, please leave the YES/NO question blank but explain issue in the comment area to help us understand. I hope this helps a bit. We'll still try to answer questions as they arise. Dave Cyrus Daboo wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi Reinhold, --On Sunday, April 03, 2005 06:31:27 PM +0200 Reinhold Kainhofer <a class="moz-txt-link-rfc2396E" href="mailto:reinhold@kainhofer.com"><reinhold@kainhofer.com></a> wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Does yes mean I comply on generation? That I fail on processing if the MUST is violated? If I try to recover from non-compliant calendars during decoding, does that make me a "no"? </pre> </blockquote> </blockquote> <pre wrap="">Strictly speaking the MUST in the specs refers to both consumption and </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">production of the relevant items - to be compliant you have to do both </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">correctly. So for the time being I think you should answer YES only if </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">you produce and consume the item correctly (or if your implementation only does one thing - i.e. just consumes - then answer YES to that if it conforms). Ignore any behaviour for non-compliant data being </pre> </blockquote> <pre wrap=""><!---->consumed. </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Also, I'd think an interesting question would be what FREQ values people have actually implemented. For example, I haven't implemented </pre> </blockquote> </blockquote> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">a FREQ of WEEKLY, or BYHOUR/MINUTE/SECONDS, or BYSETPOS. They are on </pre> </blockquote> </blockquote> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">my todo list, but since I haven't seen a calendar with these yet, </pre> </blockquote> </blockquote> <pre wrap="">FYI the technical committee is working on a second questionnaire that will list each of the syntactical elements for recurrences and ask yes/no questions for separately for 'consume' and 'produce' of those. I'm nor sure when we will have that available - in the meantime please </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">go ahead and fill out the current form if you've not already done so - </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">thanks. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">If nobody supported BYSETPOS it would be a candidate for removal from the update prior to standardization. If its just me, then I better implement it soon! </pre> </blockquote> <pre wrap=""> libkcal and thus all KDE applications also don't implement BYSETPOS </pre> </blockquote> </blockquote> <pre wrap=""><!---->yet. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">It's also on my to-do list, but I don't think I'll have the time to implement it in the short- or midterm future. </pre> </blockquote> <pre wrap=""> FYI my implementation is capable of consuming and producing BYSETPOS, though the UI limits the range that can be produced by the user. Implementing BYSETPOS was probably the hardest part of doing the rules </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">as it meant pretty much having to expand the entire possible set and then picking the ones matched in order to support negative BYSETPOS values. It makes incremental or iterative recurrence expansion hard to </pre> </blockquote> <pre wrap=""><!----> </pre> <blockquote type="cite"> <pre wrap="">do without keeping a lot of state information around. </pre> </blockquote> <pre wrap=""><!----> _______________________________________________ Ietf-calsify mailing list <a class="moz-txt-link-abbreviated" href="mailto:Ietf-calsify@osafoundation.org">Ietf-calsify@osafoundation.org</a> <a class="moz-txt-link-freetext" href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a> </pre> </blockquote> </body> </html> X-Envelope-From: camerost@exchange.microsoft.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33Iq1aZ018231 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 11:52:01 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Sun, 3 Apr 2005 11:50:43 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 3 Apr 2005 11:50:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7527.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify Date: Sun, 3 Apr 2005 11:50:44 -0700 Message-ID: <1198328AFDBF5841B27E40C40C33153702D8693F@df-chewy-msg.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify Thread-Index: AcU4dC/ZHb15/4vcRhWFmCGpJE38/gACWNRw From: "Cameron Stillion" <camerost@exchange.microsoft.com> To: <Dave.Thewlis@calconnect.org>, "Cyrus Daboo" <daboo@isamet.com> X-OriginalArrivalTime: 03 Apr 2005 18:50:43.0110 (UTC) FILETIME=[09C88C60:01C5387E] X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j33Iq1aZ018231 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 18:52:02 -0000 Just one little bug - or rather niggly - is that it is rather difficult in an HTML form to deselect all options in a set of radio buttons, therefore the approach of "don't select either" is somewhat problematic in the cases where you may have already chosen one (for whatever reason) - without completely resetting the form to try again. :) cameron -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Dave Thewlis Sent: Sunday.03.April.2005 10.37 To: Cyrus Daboo Cc: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify Cyrus, Reinhold, Sam, I've added some text to the questionnaire text as a result of the points that have been raised to try and make it clearer. First to make Cyrus' point about production and consumption, and second to say that if you can't reasonably answer either Yes or No, please leave the YES/NO question blank but explain issue in the comment area to help us understand. I hope this helps a bit. We'll still try to answer questions as they arise. Dave Cyrus Daboo wrote: > Hi Reinhold, > > --On Sunday, April 03, 2005 06:31:27 PM +0200 Reinhold Kainhofer > <reinhold@kainhofer.com> wrote: > >>> Does yes mean I comply on generation? That I fail on processing if >>> the MUST is violated? If I try to recover from non-compliant >>> calendars during decoding, does that make me a "no"? >> > > Strictly speaking the MUST in the specs refers to both consumption and > production of the relevant items - to be compliant you have to do both > correctly. So for the time being I think you should answer YES only if > you produce and consume the item correctly (or if your implementation > only does one thing - i.e. just consumes - then answer YES to that if > it conforms). Ignore any behaviour for non-compliant data being consumed. > >>> Also, I'd think an interesting question would be what FREQ values >>> people have actually implemented. For example, I haven't implemented >>> a FREQ of WEEKLY, or BYHOUR/MINUTE/SECONDS, or BYSETPOS. They are on >>> my todo list, but since I haven't seen a calendar with these yet, >> > > FYI the technical committee is working on a second questionnaire that > will list each of the syntactical elements for recurrences and ask > yes/no questions for separately for 'consume' and 'produce' of those. > I'm nor sure when we will have that available - in the meantime please > go ahead and fill out the current form if you've not already done so - > thanks. > >>> If nobody supported BYSETPOS it would be a candidate for removal >>> from the update prior to standardization. If its just me, then I >>> better implement it soon! >> >> >> libkcal and thus all KDE applications also don't implement BYSETPOS yet. >> It's also on my to-do list, but I don't think I'll have the time to >> implement it in the short- or midterm future. > > > FYI my implementation is capable of consuming and producing BYSETPOS, > though the UI limits the range that can be produced by the user. > Implementing BYSETPOS was probably the hardest part of doing the rules > as it meant pretty much having to expand the entire possible set and > then picking the ones matched in order to support negative BYSETPOS > values. It makes incremental or iterative recurrence expansion hard to > do without keeping a lot of state information around. > _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: camerost@exchange.microsoft.com Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33IlgaZ018038; Sun, 3 Apr 2005 11:47:42 -0700 Received: from df-hub-02.exchange.corp.microsoft.com ([157.54.8.23]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 3 Apr 2005 11:46:02 -0700 Received: from df-chewy-msg.exchange.corp.microsoft.com ([157.54.6.240]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 3 Apr 2005 11:46:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7527.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Ietf-calsify] Proposed Charter Date: Sun, 3 Apr 2005 11:46:13 -0700 Message-ID: <1198328AFDBF5841B27E40C40C33153702D8693E@df-chewy-msg.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-calsify] Proposed Charter Thread-Index: AcU0ArYp5LWhhPVcSqC0WH7WJbWRtAENKjbg From: "Cameron Stillion" <camerost@exchange.microsoft.com> To: "Lisa Dusseault" <lisa@osafoundation.org>, <ietf-calsify@osafoundation.org> X-OriginalArrivalTime: 03 Apr 2005 18:46:12.0526 (UTC) FILETIME=[6880B4E0:01C5387D] X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j33IlgaZ018038 Cc: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 18:47:45 -0000 This is an excellent proposal and a great report! I only wish that I could have been in attendance at the BOF. This is a good practical approach to take to actually make some headway - focusing on tightening up the current practice and avoiding the "more radical approach" which while well-intentioned, is and should be beyond the scope of calsify. It's all about interoperability, and that's why extensions are so important - both to identify, and to clarify the process surrounding them. I'd like to see a questionnaire on extension usage much like the one sent out recently about recurrence rules (yes, I'm still double-checking my answers with current code...) Fairly simple, very practical, ultimately useful. In my mind, that outscores a lot of standards bodies' work... cameron -----Original Message----- From: ietf-calsify-bounces@osafoundation.org [mailto:ietf-calsify-bounces@osafoundation.org] On Behalf Of Lisa Dusseault Sent: Monday.28.March.2005 17.56 To: ietf-calsify@osafoundation.org Subject: [Ietf-calsify] Proposed Charter Based on the discussion at the Calsify BOF in Minneapolis, a bunch of us (those who volunteered at the time) have worked on the draft WG charter below. Some notes: - The iCalendar revision work, although it may be challenging work, is at least well understood in terms of scope and deliverables. - The transition work which I attempted to characterize in a separate email is not so well scoped out and it's not clear yet what specific proposals might emerge, if any, so this charter would need to be revised when the specific proposals become clear or do not appear after a period. - The XML work which seemed to be supported in the BOF (but nobody actually took consensus) was not supported in the group of people working on this charter, so it appears as "out of scope". -- Lisa ---- Calendaring and Scheduling Standards Simplification (calsify) Chair(s): TBD Applications Area Director(s): Ted Hardie <hardie@qualcomm.com> Scott Hollenbeck <sah@428cobrajet.net> Mailing Lists: General Discussion: ietf-calsify@osafoundation.org To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/ Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability as been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Publish the interoperability issues that have arisen between calendaring and scheduling systems, as well as document the usage of iCalendar by other specifications. (2) Revise the Calendaring and Scheduling standards to advance the state of interoperable calendaring and scheduling by addressing the published interoperability issues. As far as it is possible, the working group will ensure backwards compatibility with widely deployed implementations and other specifications that use it. (3) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (4) Advance the Calendaring and Scheduling standards to Draft Standard. (5) Work on transition (upgrade or versioning) mechanisms for calendar data exchange. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Goals and Milestones: TBD - Submit "Problems in Calendaring and Scheduling Standards". TBD - Submit RFC2445bis. TBD - Submit other revised documents. _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify X-Envelope-From: gic-ietf-calsify@gmane.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33IWmaa017292 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 11:32:50 -0700 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DI9ri-00060k-SK for ietf-calsify@osafoundation.org; Sun, 03 Apr 2005 20:30:30 +0200 Received: from lions.xs4all.nl ([213.84.175.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Sun, 03 Apr 2005 20:30:30 +0200 Received: from mvl by lions.xs4all.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-calsify@osafoundation.org>; Sun, 03 Apr 2005 20:30:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-calsify@osafoundation.org From: Michiel van Leeuwen <mvl@exedo.nl> Date: Sun, 03 Apr 2005 20:24:04 +0200 Lines: 12 Message-ID: <d2pc8u$n4h$1@sea.gmane.org> References: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lions.xs4all.nl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050401 In-Reply-To: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> Sender: news <news@sea.gmane.org> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: Proposed Charter X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 18:32:52 -0000 Lisa Dusseault wrote: > (3) Clarify the registration process for iCalendar extensions (i.e., > the current core object specification only provides a template > to register new properties). This looks like it is part of a possible solution, using extensions, instead of a goal in itself. The goal is to solve interop issues, and it might turn out that extensions are a solution. But using extensions should not be the goal, so should not be in the charter imo. (and i don't like the use of extensions, but that's another discussion) Michiel X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts40-srv.bellnexxia.net (tomts40.bellnexxia.net [209.226.175.97]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33ILhaZ016443 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 11:21:43 -0700 Received: from ensemble.local ([64.229.170.33]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050403182143.XWFE27737.tomts40-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 14:21:43 -0400 Received: by ensemble.local (Postfix, from userid 501) id BB58D42E2D6; Sun, 3 Apr 2005 14:21:12 -0400 (EDT) Date: Sun, 3 Apr 2005 14:21:12 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Example RRULEs Message-ID: <20050403182112.GA8230@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <2CE2311C4573512D7C40A9AF@ninevah.local> <20050403164430.GC7997@ensemble.local> <16BF8C3DB64A0EECE90FD542@ninevah.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16BF8C3DB64A0EECE90FD542@ninevah.local> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 18:21:46 -0000 Quoting daboo@isamet.com, on Sun, Apr 03, 2005 at 02:19:31PM -0400: > Hi Sam, > > --On April 3, 2005 12:44:30 -0400 Sam Roberts <sroberts@uniserve.com> wrote: > > >Is this an error in the spec? > > Yes, I believe that is wrong. Also: Thanks. > > Every 3 hours from 9:00 AM to 5:00 PM on a specific day: > > > > DTSTART;TZID=US-Eastern:19970902T090000 > > RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z > > > > ==> (September 2, 1997 EDT)09:00,12:00,15:00 > > This one is wrong too as 19970902T170000Z is before 15:00 US-Eastern, but > after 12:00 US-Eastern, so the correct result ought to be: > > > ==> (September 2, 1997 EDT)09:00,12:00 Thanks, I will notice this when I implement HOURLY frequencies. Sam X-Envelope-From: daboo@isamet.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33IJYaa016188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 11:19:35 -0700 Received: from [10.0.1.4] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j33I3H6g016716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2005 14:03:19 -0400 Date: Sun, 03 Apr 2005 14:19:31 -0400 From: Cyrus Daboo <daboo@isamet.com> To: Sam Roberts <sroberts@uniserve.com>, ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Example RRULEs Message-ID: <16BF8C3DB64A0EECE90FD542@ninevah.local> In-Reply-To: <20050403164430.GC7997@ensemble.local> References: <2CE2311C4573512D7C40A9AF@ninevah.local> <20050403164430.GC7997@ensemble.local> X-Mailer: Mulberry/4.0.0a7 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.3 tests=UPPERCASE_25_50 X-Spam-Score: 0.207 () UPPERCASE_25_50 X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 18:19:36 -0000 Hi Sam, --On April 3, 2005 12:44:30 -0400 Sam Roberts <sroberts@uniserve.com> wrote: ># ># Everyday in January, for 3 years: ># ># DTSTART;TZID=US-Eastern:19980101T090000 ># RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; ># BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA ># or ># RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 ># ># ==> (1998 9:00 AM EDT)January 1-31 ># (1999 9:00 AM EDT)January 1-31 ># (2000 9:00 AM EDT)January 1-31 > > I believe the UNTIL time, being in UTC, is BEFORE (2000 9:00 AM > EDT)January 31 , so the last date in the result vector is not valid. > > Also, January is in EST, not EDT! > > So, when I process the BYDAY variant of the RRULE, I get these dates: > ># ==> (1998 9:00 AM EST)January 1-31 ># (1999 9:00 AM EST)January 1-31 ># (2000 9:00 AM EST)January 1-30 > > Note the EST, and that the last one ends on the 30th. > > Is this an error in the spec? Yes, I believe that is wrong. Also: > Every 3 hours from 9:00 AM to 5:00 PM on a specific day: > > DTSTART;TZID=US-Eastern:19970902T090000 > RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z > > ==> (September 2, 1997 EDT)09:00,12:00,15:00 This one is wrong too as 19970902T170000Z is before 15:00 US-Eastern, but after 12:00 US-Eastern, so the correct result ought to be: > ==> (September 2, 1997 EDT)09:00,12:00 -- Cyrus Daboo X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from smtp803.mail.sc5.yahoo.com (smtp803.mail.sc5.yahoo.com [66.163.168.182]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j33IDgaZ015828 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 11:13:42 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.113.23 with plain) by smtp803.mail.sc5.yahoo.com with SMTP; 3 Apr 2005 18:13:42 -0000 Message-ID: <42503251.2050300@calconnect.org> Date: Sun, 03 Apr 2005 11:13:37 -0700 From: Dave Thewlis <Dave.Thewlis@calconnect.org> Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Example RRULEs References: <2CE2311C4573512D7C40A9AF@ninevah.local> <20050403164430.GC7997@ensemble.local> <DD7BB491BAEFF89E4A197BFA@ninevah.local> In-Reply-To: <DD7BB491BAEFF89E4A197BFA@ninevah.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.462 (*) SARE_TOCC_COMBO1,UNDISC_RECIPS X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 18:13:43 -0000 The example file has also been updated on the Calconnect web site: http://www.calconnect.org/ioptesting.html Dave Thewlis Cyrus Daboo wrote: > Hi Sam, > > --On April 3, 2005 12:44:30 -0400 Sam Roberts <sroberts@uniserve.com> > wrote: > >>> To help with interop testing, I have made the following available: >>> >>> 1) >>> <http://www.mulberrymail.com/davroot/calendars/public/iCalendarTests/244 >>> >>> 5AllExamples.ics> >>> > > FYI When trying to analyze the issues you brought up I discovered an > error in my example .ics - the VTIMEZONE component name did not match > the TZIDs actually being used and the timezone start times were not > far enough into the past to cover the actual times in the example > events. This has now been fixed and the example file updated on my site. > > <http://www.mulberrymail.com/davroot/calendars/public/iCalendarTests/2445AllExamples.ics> > > X-Envelope-From: daboo@isamet.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33I55aa015339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 11:05:07 -0700 Received: from [10.0.1.4] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j33Hmm6g016405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2005 13:48:50 -0400 Date: Sun, 03 Apr 2005 14:05:01 -0400 From: Cyrus Daboo <daboo@isamet.com> To: Sam Roberts <sroberts@uniserve.com>, ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Example RRULEs Message-ID: <DD7BB491BAEFF89E4A197BFA@ninevah.local> In-Reply-To: <20050403164430.GC7997@ensemble.local> References: <2CE2311C4573512D7C40A9AF@ninevah.local> <20050403164430.GC7997@ensemble.local> X-Mailer: Mulberry/4.0.0a7 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 18:05:09 -0000 Hi Sam, --On April 3, 2005 12:44:30 -0400 Sam Roberts <sroberts@uniserve.com> wrote: >> To help with interop testing, I have made the following available: >> >> 1) >> <http://www.mulberrymail.com/davroot/calendars/public/iCalendarTests/244 >> 5AllExamples.ics> >> FYI When trying to analyze the issues you brought up I discovered an error in my example .ics - the VTIMEZONE component name did not match the TZIDs actually being used and the timezone start times were not far enough into the past to cover the actual times in the example events. This has now been fixed and the example file updated on my site. <http://www.mulberrymail.com/davroot/calendars/public/iCalendarTests/2445AllExamples.ics> -- Cyrus Daboo X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33I06aa015045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 11:00:07 -0700 Received: from ip6-localhost (doob.fam.tuwien.ac.at [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j33I05qB017194 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 20:00:05 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (=?iso-8859-1?q?Re=3A=09draft-royer-ical-basic-01=2Etxt_-_sent_to?= IETF) Date: Sun, 3 Apr 2005 20:00:01 +0200 User-Agent: KMail/1.8 References: <41EAD88F.1030601@Royer.com> <200504031803.08287.reinhold@kainhofer.com> <20050403171305.GA8066@ensemble.local> In-Reply-To: <20050403171305.GA8066@ensemble.local> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1147345.Zga2141yH1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504032000.03390.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 18:00:09 -0000 --nextPart1147345.Zga2141yH1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 3. April 2005 19:13 schrieb Sam Roberts: > Quoting reinhold@kainhofer.com, on Sun, Apr 03, 2005 at 06:03:05PM +0200: > > BTW, several weeks ago I argued exactly the same ways as you did. I > > couldn't find any hint in rfc 2445 about how to correctly calculate the > > end date of events. And since the only reference was the due-date > > calculation in rfc I'd like to have a clear section in rfc 2445 about h= ow > > the DTEND is calculated correctly. And if it is really the case, that a= ll > > calculations only use the duration (explicitly or implicitly if a DTEND > > is given), we should make it very clear that the first example (where t= he > > shift always ends at the same time, so it might be one hour shorter or > > longer for the nights when DST changes) is simply not possible with > > iCalendar. > > Ok, I thought about this some more, and looked at 4.5.7.2. > > So, the issue is that in the 2nd occurence, you have applied the RRULE > to the DTSTART, so you know the 2nd start. But now you need to find the > 2nd end. If you do this by calculating an implicit duration from the > first DTSTART and DTEND,=20 Exactly.=20 > it will be wrong over DST, leap years, etc.=20 I wouldn't say it's wrong. Rather it needs to be clearly worded that the DT= END=20 calculation always uses the duration, so the end time is not carved in ston= e.=20 The same problem also appears with Feb 29.=20 Here in Austria you get your yearly payment report sometime mid-february, a= nd=20 you have to submit the tax sheets at the end of May. Now imagine you create= a=20 yearly recurring todo for this, which starts on Feb 15, 2004, and has a due= =20 date of May 31, 2004. In 2005, due to the algorithm described in rfc 2446=20 this event will have a due date of June 1, 2005, and you'll submit your tax= =20 sheet late (and you'll be prosecuted, sentenced to death and executed;-) ) One particular reason why the duration is always used might be recurring=20 events that end on 2:30 am. When the time changes from standard time to=20 summer time (and vice versa) you'll have either two 2:30am or no 2:30am at= =20 all. What shall happen to these events? When will they end? > > BTW, I don't think that this case will never be needed. E.g. take a > > schedule for the heating of a building. During the night the heating wi= ll > > be turned off e.g. from 10 pm to 7am (or the alarm will be set, or the > > door will be locked, or the cleaning crew will work from 10pm to 7am, or > > whatever). When the DST starts/ends, you definitly don't want the > > cleaning crew to be still working or the alarm still engaged when all > > workers come to their office at 7:30am. So these would be examples where > > the duration is irrelevant, but the DTEND is the crucial information. > > I'm not sure what you mean. You say "this case will never be needed", Okay, sorry I used a double negation, which in German (my mother tongue) is= =20 understood as a positive affirmation. I intended to say "I think this is a= =20 case with some real-world cases, so I don't think we can just ignore it". O= r=20 put differently, I wanted to negate the previous arguments by Doug on the=20 list that all workshift-related events will not need a fixed end time. (But= =20 then, life doesn't only consists of work...) Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart1147345.Zga2141yH1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCUC8jTqjEwhXvPN0RAvhuAJ9u9oVhkDNRwhkAGREF2LMKj3qSpgCgmzNw 6BTPlnkNjGHApaHuH1sQFYU= =Csz0 -----END PGP SIGNATURE----- --nextPart1147345.Zga2141yH1-- X-Envelope-From: Dave.Thewlis@calconnect.org X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from smtp802.mail.sc5.yahoo.com (smtp802.mail.sc5.yahoo.com [66.163.168.181]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j33Hb8aZ013960 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 10:37:08 -0700 Received: from unknown (HELO ?192.168.0.101?) (dave.thewlis@sbcglobal.net@69.107.113.23 with plain) by smtp802.mail.sc5.yahoo.com with SMTP; 3 Apr 2005 17:37:08 -0000 Message-ID: <425029BF.4040205@calconnect.org> Date: Sun, 03 Apr 2005 10:37:03 -0700 From: Dave Thewlis <Dave.Thewlis@calconnect.org> Organization: The Calendaring and Scheduling Consortium User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrus Daboo <daboo@isamet.com> Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify References: <424EAC6B.4090001@dcta.com> <20050403162034.GA7997@ensemble.local> <200504031831.29529.reinhold@kainhofer.com> <98B7E45222F36AB8F2F17169@ninevah.cyrusoft.com> In-Reply-To: <98B7E45222F36AB8F2F17169@ninevah.cyrusoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 17:37:10 -0000 Cyrus, Reinhold, Sam, I've added some text to the questionnaire text as a result of the points that have been raised to try and make it clearer. First to make Cyrus' point about production and consumption, and second to say that if you can't reasonably answer either Yes or No, please leave the YES/NO question blank but explain issue in the comment area to help us understand. I hope this helps a bit. We'll still try to answer questions as they arise. Dave Cyrus Daboo wrote: > Hi Reinhold, > > --On Sunday, April 03, 2005 06:31:27 PM +0200 Reinhold Kainhofer > <reinhold@kainhofer.com> wrote: > >>> Does yes mean I comply on generation? That I fail on processing if the >>> MUST is violated? If I try to recover from non-compliant calendars >>> during decoding, does that make me a "no"? >> > > Strictly speaking the MUST in the specs refers to both consumption and > production of the relevant items - to be compliant you have to do both > correctly. So for the time being I think you should answer YES only if > you produce and consume the item correctly (or if your implementation > only does one thing - i.e. just consumes - then answer YES to that if > it conforms). Ignore any behaviour for non-compliant data being consumed. > >>> Also, I'd think an interesting question would be what FREQ values >>> people >>> have actually implemented. For example, I haven't implemented a FREQ of >>> WEEKLY, or BYHOUR/MINUTE/SECONDS, or BYSETPOS. They are on my todo >>> list, >>> but since I haven't seen a calendar with these yet, >> > > FYI the technical committee is working on a second questionnaire that > will list each of the syntactical elements for recurrences and ask > yes/no questions for separately for 'consume' and 'produce' of those. > I'm nor sure when we will have that available - in the meantime please > go ahead and fill out the current form if you've not already done so - > thanks. > >>> If nobody supported BYSETPOS it would be a candidate for removal from >>> the update prior to standardization. If its just me, then I better >>> implement it soon! >> >> >> libkcal and thus all KDE applications also don't implement BYSETPOS yet. >> It's also on my to-do list, but I don't think I'll have the time to >> implement it in the short- or midterm future. > > > FYI my implementation is capable of consuming and producing BYSETPOS, > though the UI limits the range that can be produced by the user. > Implementing BYSETPOS was probably the hardest part of doing the rules > as it meant pretty much having to expand the entire possible set and > then picking the ones matched in order to support negative BYSETPOS > values. It makes incremental or iterative recurrence expansion hard to > do without keeping a lot of state information around. > X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33HRSaZ013499 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 10:27:28 -0700 Received: from ensemble.local ([64.229.170.33]) by tomts5-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050403172727.XAIQ26128.tomts5-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 13:27:27 -0400 Received: by ensemble.local (Postfix, from userid 501) id 0FAFC42E11F; Sun, 3 Apr 2005 13:26:57 -0400 (EDT) Date: Sun, 3 Apr 2005 13:26:57 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify Message-ID: <20050403172657.GA8090@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <424EAC6B.4090001@dcta.com> <20050403162034.GA7997@ensemble.local> <200504031831.29529.reinhold@kainhofer.com> <98B7E45222F36AB8F2F17169@ninevah.cyrusoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98B7E45222F36AB8F2F17169@ninevah.cyrusoft.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 2.429 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 17:27:29 -0000 Quoting daboo@isamet.com, on Sun, Apr 03, 2005 at 12:49:15PM -0400: > Hi Reinhold, > > --On Sunday, April 03, 2005 06:31:27 PM +0200 Reinhold Kainhofer > <reinhold@kainhofer.com> wrote: > > >>Does yes mean I comply on generation? That I fail on processing if the > >>MUST is violated? If I try to recover from non-compliant calendars > >>during decoding, does that make me a "no"? > > Strictly speaking the MUST in the specs refers to both consumption and > production of the relevant items - to be compliant you have to do both > correctly. So for the time being I think you should answer YES only if you > produce and consume the item correctly (or if your implementation only does > one thing - i.e. just consumes - then answer YES to that if it conforms). > Ignore any behaviour for non-compliant data being consumed. Ok, so the FREQ question means "do you generate the FREQ"? > >>Also, I'd think an interesting question would be what FREQ values people > >>have actually implemented. For example, I haven't implemented a FREQ of > >>WEEKLY, or BYHOUR/MINUTE/SECONDS, or BYSETPOS. They are on my todo list, > >>but since I haven't seen a calendar with these yet, > > FYI the technical committee is working on a second questionnaire that will > list each of the syntactical elements for recurrences and ask yes/no > questions for separately for 'consume' and 'produce' of those. I'm nor sure > when we will have that available - in the meantime please go ahead and fill > out the current form if you've not already done so - thanks. I'm not sure if its useful, still. I think its fairly app oriented, not toolkit oriented. You can get a summary from an event with my toolkit, but it doesn't exactly do anything with it, just gives it to you. What is the goal, to get somebody to admit they don't write a FREQ when they generate a calendar? Or to find somebody who encodes multiple SUMMARY fields? And then what, make it allowed in 2445bis, or just publicly chastise them? :-) Sorry for the joke. Seriously, I want to help out, but I don't know what the questionaire is trying to find out. > >>If nobody supported BYSETPOS it would be a candidate for removal from > >>the update prior to standardization. If its just me, then I better > >>implement it soon! > > > >libkcal and thus all KDE applications also don't implement BYSETPOS yet. > >It's also on my to-do list, but I don't think I'll have the time to > >implement it in the short- or midterm future. > > FYI my implementation is capable of consuming and producing BYSETPOS, > though the UI limits the range that can be produced by the user. > Implementing BYSETPOS was probably the hardest part of doing the rules as > it meant pretty much having to expand the entire possible set and then > picking the ones matched in order to support negative BYSETPOS values. It > makes incremental or iterative recurrence expansion hard to do without > keeping a lot of state information around. I think its important, it just dropped down below things like a nice API to help people generate recuring events. Cheers, Sam X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts16-srv.bellnexxia.net (tomts16.bellnexxia.net [209.226.175.4]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33HDaaZ012744 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 10:13:36 -0700 Received: from ensemble.local ([64.229.170.33]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050403171335.TRBU27508.tomts16-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 13:13:35 -0400 Received: by ensemble.local (Postfix, from userid 501) id C982142E080; Sun, 3 Apr 2005 13:13:05 -0400 (EDT) Date: Sun, 3 Apr 2005 13:13:05 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) Message-ID: <20050403171305.GA8066@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <41EAD88F.1030601@Royer.com> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> <200504031803.08287.reinhold@kainhofer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504031803.08287.reinhold@kainhofer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 2.429 (**) DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO, URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 17:13:38 -0000 Quoting reinhold@kainhofer.com, on Sun, Apr 03, 2005 at 06:03:05PM +0200: > Am Sonntag, 3. April 2005 17:25 schrieb Sam Roberts: > However, for recurring to-dos, rfc 2446 is quite clear on the > calculation of the due date of the recurrences. See section 4.5.7.1: > "Calculating due dates in recurring VTODOs" > > It is made clear to me that the calculation of the due date always implicitly > uses the duration, which is either given, or directly calculated from the > given dtstart and dtend (or due) of the very first occurence. I haven't implemented much of iTIP, and section 4.5.7.2 is so bad grammatically I'm not sure what it is supposed to mean. "...the interval of one day which is applied to..." This is either an incomplete sentence, or the "which" should be dropped. > BTW, several weeks ago I argued exactly the same ways as you did. I couldn't > find any hint in rfc 2445 about how to correctly calculate the end date of > events. And since the only reference was the due-date calculation in rfc > I'd like to have a clear section in rfc 2445 about how the DTEND is calculated > correctly. And if it is really the case, that all calculations only use the > duration (explicitly or implicitly if a DTEND is given), we should make it > very clear that the first example (where the shift always ends at the same > time, so it might be one hour shorter or longer for the nights when DST > changes) is simply not possible with iCalendar. Ok, I thought about this some more, and looked at 4.5.7.2. So, the issue is that in the 2nd occurence, you have applied the RRULE to the DTSTART, so you know the 2nd start. But now you need to find the 2nd end. If you do this by calculating an implicit duration from the first DTSTART and DTEND, it will be wrong over DST, leap years, etc. Do I understand your point? That is a serious problem, and if an algorithm can be specified, it should be. Events with a start and end time are probably among the most common types of events. People do things like that, it reflects our lives. iCalendar needs to represent it, its not a corner case, its a common one. I am very concerned that the goal of this RFC244x simplification is to produce the simplest protocol that people can schedule meetings with. I don't use iCalendar for meetings, I use it to represent events in my life, many of which are repeating, and with alarms to notify me of their recurrence - birthdays, holidays (first monday in July, etc.), when I have to be at work, etc. > BTW, I don't think that this case will never be needed. E.g. take a schedule > for the heating of a building. During the night the heating will be turned > off e.g. from 10 pm to 7am (or the alarm will be set, or the door will be > locked, or the cleaning crew will work from 10pm to 7am, or whatever). When > the DST starts/ends, you definitly don't want the cleaning crew to be still > working or the alarm still engaged when all workers come to their office at > 7:30am. So these would be examples where the duration is irrelevant, but the > DTEND is the crucial information. I'm not sure what you mean. You say "this case will never be needed", but then give an example where DTEND is crucial. Whats the unnecessary case? Cheers, Sam X-Envelope-From: daboo@isamet.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from darius.cyrusoft.com (darius.cyrusoft.com [63.163.82.2]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33GnJaa011139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 09:49:20 -0700 Received: from [10.0.1.5] (pool-68-162-179-106.pitt.east.verizon.net [68.162.179.106]) (authenticated bits=0) by darius.cyrusoft.com (8.12.9/8.12.9) with ESMTP id j33GX26g014494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2005 12:33:04 -0400 Date: Sun, 03 Apr 2005 12:49:15 -0400 From: Cyrus Daboo <daboo@isamet.com> To: Reinhold Kainhofer <reinhold@kainhofer.com>, ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify Message-ID: <98B7E45222F36AB8F2F17169@ninevah.cyrusoft.com> In-Reply-To: <200504031831.29529.reinhold@kainhofer.com> References: <424EAC6B.4090001@dcta.com> <20050403162034.GA7997@ensemble.local> <200504031831.29529.reinhold@kainhofer.com> X-Mailer: Mulberry/4.0.0a7 (Linux/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0.0 tests=none X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 16:49:22 -0000 Hi Reinhold, --On Sunday, April 03, 2005 06:31:27 PM +0200 Reinhold Kainhofer <reinhold@kainhofer.com> wrote: >> Does yes mean I comply on generation? That I fail on processing if the >> MUST is violated? If I try to recover from non-compliant calendars >> during decoding, does that make me a "no"? Strictly speaking the MUST in the specs refers to both consumption and production of the relevant items - to be compliant you have to do both correctly. So for the time being I think you should answer YES only if you produce and consume the item correctly (or if your implementation only does one thing - i.e. just consumes - then answer YES to that if it conforms). Ignore any behaviour for non-compliant data being consumed. >> Also, I'd think an interesting question would be what FREQ values people >> have actually implemented. For example, I haven't implemented a FREQ of >> WEEKLY, or BYHOUR/MINUTE/SECONDS, or BYSETPOS. They are on my todo list, >> but since I haven't seen a calendar with these yet, FYI the technical committee is working on a second questionnaire that will list each of the syntactical elements for recurrences and ask yes/no questions for separately for 'consume' and 'produce' of those. I'm nor sure when we will have that available - in the meantime please go ahead and fill out the current form if you've not already done so - thanks. >> If nobody supported BYSETPOS it would be a candidate for removal from >> the update prior to standardization. If its just me, then I better >> implement it soon! > > libkcal and thus all KDE applications also don't implement BYSETPOS yet. > It's also on my to-do list, but I don't think I'll have the time to > implement it in the short- or midterm future. FYI my implementation is capable of consuming and producing BYSETPOS, though the UI limits the range that can be produced by the user. Implementing BYSETPOS was probably the hardest part of doing the rules as it meant pretty much having to expand the entire possible set and then picking the ones matched in order to support negative BYSETPOS values. It makes incremental or iterative recurrence expansion hard to do without keeping a lot of state information around. -- Cyrus Daboo X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts16-srv.bellnexxia.net (tomts16.bellnexxia.net [209.226.175.4]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33Gj1aZ010640 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 09:45:01 -0700 Received: from ensemble.local ([64.229.170.33]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050403164500.TMJM27508.tomts16-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 12:45:00 -0400 Received: by ensemble.local (Postfix, from userid 501) id 8E57042E041; Sun, 3 Apr 2005 12:44:30 -0400 (EDT) Date: Sun, 3 Apr 2005 12:44:30 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Example RRULEs Message-ID: <20050403164430.GC7997@ensemble.local> Mail-Followup-To: ietf-calsify@osafoundation.org References: <2CE2311C4573512D7C40A9AF@ninevah.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2CE2311C4573512D7C40A9AF@ninevah.local> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 16:45:03 -0000 Quoting dabooatisamet.com, on Fri, Feb 11, 2005 at 02:04:04PM +0000: > To help with interop testing, I have made the following available: > > 1) > <http://www.mulberrymail.com/davroot/calendars/public/iCalendarTests/2445AllExamples.ics> > > This contains all the recurrence examples from 2445 Section 4.8.5.4 in one > .ics file. The SUMMARY of each item indicates the example number in order > from that section. The DESCRIPTION is the description from 2445 for each > example. Note that some examples have a couple of variants and these are > indicated by additional letters in the numbering (e.g. 05a 05b etc). Most > of the examples use start dates in 1997, but there are some unbounded > examples that will fill up the calendar display e.g. 'Every 20 minutes from > 9:00 AM to 4:40 PM every day'. I test my RRULE processor against the examples in RFC2445, and I found what I think is an error: # # Everyday in January, for 3 years: # # DTSTART;TZID=US-Eastern:19980101T090000 # RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; # BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA # or # RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 # # ==> (1998 9:00 AM EDT)January 1-31 # (1999 9:00 AM EDT)January 1-31 # (2000 9:00 AM EDT)January 1-31 I believe the UNTIL time, being in UTC, is BEFORE (2000 9:00 AM EDT)January 31 , so the last date in the result vector is not valid. Also, January is in EST, not EDT! So, when I process the BYDAY variant of the RRULE, I get these dates: # ==> (1998 9:00 AM EST)January 1-31 # (1999 9:00 AM EST)January 1-31 # (2000 9:00 AM EST)January 1-30 Note the EST, and that the last one ends on the 30th. Is this an error in the spec? Btw, the RRULE examples have a very regular formatting. Thats quite nice, I feed the example text into a little regexer in my unit tests that spits out an array of times, and confirms that my rrule processor generates the same array, modulo the "...". Sam X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33GVXaa009516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 09:31:35 -0700 Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j33GVV3I013564 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 18:31:32 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify Date: Sun, 3 Apr 2005 18:31:27 +0200 User-Agent: KMail/1.8 References: <424EAC6B.4090001@dcta.com> <20050403162034.GA7997@ensemble.local> In-Reply-To: <20050403162034.GA7997@ensemble.local> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15675927.j9z6cPPI5z"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504031831.29529.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 16:31:37 -0000 --nextPart15675927.j9z6cPPI5z Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 3. April 2005 18:20 schrieb Sam Roberts: > For one thing generate and process (encode/decode) support are seperate > issues, I think. > > Does yes mean I comply on generation? That I fail on processing if the > MUST is violated? If I try to recover from non-compliant calendars > during decoding, does that make me a "no"? I had exactly the same questions. David said he'll ask the technical commit= ee=20 about this. > Also, I'd think an interesting question would be what FREQ values people > have actually implemented. For example, I haven't implemented a FREQ of > WEEKLY, or BYHOUR/MINUTE/SECONDS, or BYSETPOS. They are on my todo list, > but since I haven't seen a calendar with these yet,=20 Weekly is quite commonly used, e.g. for a course each monday and wednesday,= =20 your weekly choir rehersal, gym hours etc. byhour/minute/second is probably hardly ever used in your personal calendar= =20 (but alarm applications like KAlarm make use of minutely or hourly=20 recurrence, e.g. to remind you every hour to get away from your computer fo= r=20 a few minutes). BYSETPOS is needed for recurrences like the last working day of a month. > If nobody supported BYSETPOS it would be a candidate for removal from > the update prior to standardization. If its just me, then I better > implement it soon! libkcal and thus all KDE applications also don't implement BYSETPOS yet. It= 's=20 also on my to-do list, but I don't think I'll have the time to implement it= =20 in the short- or midterm future. Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart15675927.j9z6cPPI5z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCUBphTqjEwhXvPN0RAvryAJ4nDlADJeF7roHHRpACGon+yH8ENgCfUE8B 8zSrn2Ne4aHnSixpuZ7EZVI= =44H0 -----END PGP SIGNATURE----- --nextPart15675927.j9z6cPPI5z-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts22-srv.bellnexxia.net (tomts22.bellnexxia.net [209.226.175.184]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33GL5aZ008215 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 09:21:05 -0700 Received: from ensemble.local ([64.229.170.33]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050403162104.VHJ21470.tomts22-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 12:21:04 -0400 Received: by ensemble.local (Postfix, from userid 501) id 403E742DFDB; Sun, 3 Apr 2005 12:20:34 -0400 (EDT) Date: Sun, 3 Apr 2005 12:20:34 -0400 From: Sam Roberts <sroberts@uniserve.com> To: "David C. Thewlis" <dthewlisatdcta.com@ensemble.local> Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify Message-ID: <20050403162034.GA7997@ensemble.local> Mail-Followup-To: "David C. Thewlis" <dthewlisatdcta.com@ensemble.local>, ietf-calsify@osafoundation.org References: <424EAC6B.4090001@dcta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424EAC6B.4090001@dcta.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 16:21:06 -0000 Quoting dthewlisatdcta.com, on Sat, Apr 02, 2005 at 10:30:03AM +0000: > An HTML attachment was scrubbed... > URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050402/95f848dc/attachment.htm Hi, I'm an implementor of iCalendar support for ruby, and I've implemented recurrence rules. Its a toolkit, not an application (though it comes with some utilities, and I am working towards a number of stand-alone applications that will use the toolkit for calendaring support). Also, the encoding side is regrettably quite raw still, so it allows very definitely non-compliant calendars to be generated. I need better APIs to make it harder for people to generate bad calendars (on my todo list). Anyhow, I'm not sure how to fill out the form. For one thing generate and process (encode/decode) support are seperate issues, I think. Does yes mean I comply on generation? That I fail on processing if the MUST is violated? If I try to recover from non-compliant calendars during decoding, does that make me a "no"? I.e., I might never generate an event where STATUS appears more than once, but accept an event where STATUS occurs twice, and discard the second occurrence. What would I tick in 4.6.1a, yes or no? Another example is for an RRULE, what would I say about 4.3.10b? I don't/can't process an RRULE without a FREQ. I just took a look at the code, though, it appears that I allow multiple FREQ, and will use the last one I see. So, do I tick yes or no? Also, I'd think an interesting question would be what FREQ values people have actually implemented. For example, I haven't implemented a FREQ of WEEKLY, or BYHOUR/MINUTE/SECONDS, or BYSETPOS. They are on my todo list, but since I haven't seen a calendar with these yet, and nobody using vPim has asked for it, they have slipped down the priority list. WEEKLY will take some work, BYHOUR/min/SEC is just a bit of fill-in-the-blanks coding. I think this kind of thing would be worthwhile to document, wouldn't it? If nobody supported BYSETPOS it would be a candidate for removal from the update prior to standardization. If its just me, then I better implement it soon! Thanks, Sam X-Envelope-From: reinhold@kainhofer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33G3Eaa007343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 09:03:16 -0700 Received: from ip6-localhost (doob.fam.tuwien.ac.at [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.3/8.13.3/Debian-6) with ESMTP id j33G3ACo009897 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 18:03:12 +0200 From: Reinhold Kainhofer <reinhold@kainhofer.com> Organization: Vienna University of Technology To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (=?iso-8859-1?q?Re=3A=09draft-royer-ical-basic-01=2Etxt_-_sent_to?= IETF) Date: Sun, 3 Apr 2005 18:03:05 +0200 User-Agent: KMail/1.8 References: <41EAD88F.1030601@Royer.com> <424FA328.8050409@Royer.com> <20050403152514.GA7838@ensemble.local> In-Reply-To: <20050403152514.GA7838@ensemble.local> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1402181.JsIVeZPEU2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504031803.08287.reinhold@kainhofer.com> X-Spam-Score: 0.629 () URIBL_SBL X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 16:03:18 -0000 --nextPart1402181.JsIVeZPEU2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 3. April 2005 17:25 schrieb Sam Roberts: > Hospitals have 3 shifts a day, ending at fixed times, and not > overlapping. > > Offices have 1 shift, starting at 9AM, and we work for 8 hours, no > matter when the end time is after 8 hours. > > RFC2445 allows both to be trivially representable. Really? I looked at rfc 2445 and tried hard to find out how the end date of= =20 the recurrences is really calculated. I couldn't find anything definitive i= n=20 the rfc. However, for recurring to-dos, rfc 2446 is quite clear on the=20 calculation of the due date of the recurrences. See section 4.5.7.1: "Calculating due dates in recurring VTODOs" It is made clear to me that the calculation of the due date always implicit= ly=20 uses the duration, which is either given, or directly calculated from the=20 given dtstart and dtend (or due) of the very first occurence.=20 BTW, several weeks ago I argued exactly the same ways as you did. I couldn'= t=20 find any hint in rfc 2445 about how to correctly calculate the end date of= =20 events. And since the only reference was the due-date calculation in rfc=20 2446, which doesn't allow your Hospital example (and since Doug also gave=20 some sample calculations where he always implicitly used the duration to=20 calculate the DTEND), I simply gave up resistence.=20 I'd like to have a clear section in rfc 2445 about how the DTEND is calcula= ted=20 correctly. And if it is really the case, that all calculations only use the= =20 duration (explicitly or implicitly if a DTEND is given), we should make it= =20 very clear that the first example (where the shift always ends at the same= =20 time, so it might be one hour shorter or longer for the nights when DST=20 changes) is simply not possible with iCalendar. BTW, I don't think that this case will never be needed. E.g. take a schedul= e=20 for the heating of a building. During the night the heating will be turned= =20 off e.g. from 10 pm to 7am (or the alarm will be set, or the door will be=20 locked, or the cleaning crew will work from 10pm to 7am, or whatever). Whe= n=20 the DST starts/ends, you definitly don't want the cleaning crew to be still= =20 working or the alarm still engaged when all workers come to their office at= =20 7:30am. So these would be examples where the duration is irrelevant, but th= e=20 DTEND is the crucial information.=20 But then, I'm not sure if there is really a unique way to calculate the DTE= ND=20 without using the duration... > Your draft makes one trivial, and the other has to be represented as 3 > objects. It's already the same in rfc 2445. Either I'm missing something, or rfc 244= 5=20 is simply lacking this capability (as strange as it may seem considering ho= w=20 over-engineered it is). Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, 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 / KPilot maintain= er --nextPart1402181.JsIVeZPEU2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCUBO8TqjEwhXvPN0RAv9RAJ9ggoQb/IDGbeUqXxNODyJLmgGcIQCgidn6 W58rNwKtU3MKZjH0xZfRSl0= =vqMm -----END PGP SIGNATURE----- --nextPart1402181.JsIVeZPEU2-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33FPjaZ004740 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 08:25:45 -0700 Received: from ensemble.local ([64.229.170.33]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050403152544.XESN26102.tomts10-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 11:25:44 -0400 Received: by ensemble.local (Postfix, from userid 501) id 6F74F42DE7C; Sun, 3 Apr 2005 11:25:14 -0400 (EDT) Date: Sun, 3 Apr 2005 11:25:14 -0400 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) Message-ID: <20050403152514.GA7838@ensemble.local> References: <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> <424FA328.8050409@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424FA328.8050409@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 15:25:49 -0000 Quoting Doug@royer.com, on Sun, Apr 03, 2005 at 01:02:48AM -0700: > Sam Roberts wrote: > I removed my example, and used yours, since it shows the problem with the reductionist approach so well. > Lets say you work a 10pm - 6am work shift and are allowed > to eat at 1am - 2am. The example above is a concise example of why both representations are necessary, simply understood, and model different things. Case a: A shift of work: 10pm - 6am. This is when I work, those times being in my local timezone. Most days my shift will be 8 hours long, on occaisonal days it will be 7, and on others it will 9. Maybe my company will pay me for the 8 hours on days I only work 7, thats an accounting issue, not a scheduling issue. Either way, they don't have two chairs at the security desk that I work at, there is no point me standing there looking over the other guards shoulder. Our shifts do not overlap, on any day. This is an example of when DTEND would be used. DTSTART is when I start work, DTEND is when I end work, very simple, always right. Case b: My lunch break: it is at 1 AM, and I am allowed 1 hour. I don't get more or less. This is an example of when DURATION would be used. You still allow this. To answer your questions: > Even with DTSTART and DTEND do you think your employer will allow you > to take two hours in the rare cases that the TZID changes on those > times? No, breaks have a DURATION, not a start time and end time. Your one size fits-all attitude would cause this problem, not fix it. > Would you accept the fact that on other rare dates you can't > eat at all because the 1am-2am went away? So at 1AM, people set their clocks forward to 2am. But I set DURATION, so 1 hour later is 3AM on this day, and I get the same time to eat I get every other day. The above point would be valid if you had chose to allow only dtstart/dtend. In which case I would be complaining about that, but the above case works fine with DURATION. > Or do you have to be there 9 hours ether way? Or maybe 8 hours on rare > dates, or 10 hours on rare dates. Exactly. > Will you accept the fact that you do not get paid for one of the hours > because the TZID shifted back one hour? I may file a union greviance, but there isn't room for two people to sit at the guard desk, and there must be a guard there every hour of the day, whether there are 23 or 25 hours in the day. How I get payed for this is a problem well outside of the scope of iCalendar! Probably, I don't get paid enough. > >Your choice to prefer duration over dtend appears based on the assumption > >they can represent the same information. > > It can represent the same information. Just perhaps not in > exactly one object. So ether way you have the multiple > TZID across time shift problems. Few CUAs allow the user > to select DTEND or DURATION. You started off wanting to make things simple, and now you've introduced the need for multiple objects, sometimes? You started off by wanting to increase inter-operability, and now state that half the implementations out there are non-compliant? > THE REAL PROBLEM: > > YOUR-BOSS-CUA-WORK generates DURATION. > YOUR-CUA-WORK generates DTEND. > > So your boss tells the company calendar you will be > here 10 hours on that rare day when DURATION is > longer. Saved as 'floating time' appointment. > > You read your company calendar with YOUR-CUA-WORK > which converts a DURATION to a DTEND for display. It notices > the TZID shift and subtracts out the hour to display > the correct time and it uses the end time as the > display time. > > Your fired - you left work early. > > Should your CUA have calculated the shift based on > the start time? End time? Duration? Was your CUA > busted? Your bosses CUA bused? If my boss specified I work for 8 hours his CUA should have encoded it as he specified it (with dtstart/duration) - in which case I better work 8 hours. My CUA will add 8 hours of duration to the dtstart, do it correctly for my timezone, and display when the event ends on that particular day so I quit at the correct time. Anything else is wrong. If my boss specified that I work from 10PM to 6AM, his CUA should have represented it as such, and my CUA better show my shift ending at 6AM. > CALSIFY - lets all do it exactly one way. > With DURATION all calculation have to be done relative > to the start time. It has to, there is no end time. The world doesn't work in one way. Hospitals have 3 shifts a day, ending at fixed times, and not overlapping. Offices have 1 shift, starting at 9AM, and we work for 8 hours, no matter when the end time is after 8 hours. RFC2445 allows both to be trivially representable. Your draft makes one trivial, and the other has to be represented as 3 objects. To generate a shift that goes from 10PM to 6AM, every sunday of the year, I have to notice that timezone changes on some sundays, generate one event with a duration of 8 hours, exclude that event on all days in which timezone changes occur, then put two other events, one with a duration of 7 hours, the other with a duration of 9, that occur on single sundays in the year, the DST adjustment days. > NO CUA I have found says: > "I know you specified an DTEND time, however the time shift occurs > on that night, do you want to adjust it or not?" > > Same problem with DURATION: > "I know you specified an DURATION, however the time shift occurs > on that night, do you want to adjust it or not?" > > Your CUA can not tell why you entered the value. The CUA doesn't have to do this, it should represent it exactly as the BOSS entered it. The problems you describe are all problems in conversion between the two kinds of natural events, those with a fixed end, and those with a fixed duration. Since you propose to allow only one kind of representation, all the problems you describe above occur. If you allow the two representations, they don't occur. This situation is CAUSED by your proposal, not fixed. And a CUA that only allows inputting start and duration is incapable of allowing my boss to input my shift that starts at 10PM and ends at 6AM. This is a problem with that CUA, it is not a problem with RFC2445. Once it's users complain, the CUA will implement events that end at a specific time. If you mention this issue in RFC2445bis, people might implement it correctly the first time. > >Are you sure this is the case? It sure doesn't look like it to me. 1 - > I still think so, again perhaps not in exactly one object. 2 - > I do think we need to reduce the number of ways to do > exactly the same thing to 'one'. Statements 1 and 2 are in direct conflict. One says there will be "one way" to represent an even, the other says that in cases of events crossing timezones the CUA will have to notice, and generate more than one object. This is not "one way". Why are you removing simple things that work well? There are things in RFC2445 that are complicated, this isn't one of them, leave it alone. Sam X-Envelope-From: leifj@it.su.se X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from smtp1.su.se (smtp1.su.se [130.237.162.112]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33ADuaZ006226 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 03:13:57 -0700 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 3B82338012 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 12:13:55 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29502-01-5 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 12:13:55 +0200 (CEST) Received: from [10.0.0.7] (1-1-2-20a.rny.sth.bostream.se [82.182.132.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id A672D38005 for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 12:13:54 +0200 (CEST) Message-ID: <424FC1DF.6090108@it.su.se> Date: Sun, 03 Apr 2005 12:13:51 +0200 From: Leif Johansson <leifj@it.su.se> User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Proposed Charter References: <65713cf8e51cd511c2557fe572a4e581@osafoundation.org> <4248BE91.5070800@Royer.com> In-Reply-To: <4248BE91.5070800@Royer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 10:13:59 -0000 Doug Royer wrote: > > I think this is great and THANKS for the hard work! > I hope the silence from others is an indication that everybody else thinks this is ok aswell. MVH leifj X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j33831aa031952 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 00:03:03 -0800 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j3382res031441 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 00:02:56 -0800 Message-ID: <424FA328.8050409@Royer.com> Date: Sun, 03 Apr 2005 01:02:48 -0700 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) References: <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> <20050403062602.GA7801@ensemble.local> In-Reply-To: <20050403062602.GA7801@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000907010708020608000507" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 08:03:06 -0000 This is a cryptographically signed message in MIME format. --------------ms000907010708020608000507 Content-Type: multipart/mixed; boundary="------------020704050607030706020408" This is a multi-part message in MIME format. --------------020704050607030706020408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Roberts wrote: > >>the math in the TZ and that can product different results across >>time zones for the same instance. You have to convert each instance >>to UTC, then do the math to make it work in all TZ's. Then you will see >>that the all have the same duration. > > > You seem to be talking about the event in different timezones. I'm > talking about the event in one timezone, but with multiple occurences. > > If I have an event from 1AM to 11AM, on Aprils 3rd, it's duration will > be 9 hours, in 2005. > > In 2006, the duration will be 10 hours. > > So, > > DTSTART:20050403T010000 > DURATION:P9H > RDATE:20050403,20060403 > > This year, it will end at 11AM, next year at 10 AM. Your example is a floating time event. So its start and end is relative to the Attendee's (Not Organizer's) time zone. Lets say you use DTEND. What if at 10:01 am in your TZID=UTC+12 you finish the appointment and get on a plane that goes across the international date line in TZID=UTC-12 ? Do you expect your CUA to tell you to attend the same meeting ? :-) The appointment is in 'local time' and not tied to any specific TZID so your CUA would say yes. Floating time events we not meant to be used that way. This entry would only be valid for appointments where the Organizer and the Attendee always were in the same TZID. This can happen, how would a compiled CUA know this in advance? Lets say you work a 10pm - 6am work shift and are allowed to eat at 1am - 2am. Even with DTSTART and DTEND do you think your employer will allow you to take two hours in the rare cases that the TZID changes on those times? Would you accept the fact that on other rare dates you can't eat at all because the 1am-2am went away? Or do you have to be there 9 hours ether way? Or maybe 8 hours on rare dates, or 10 hours on rare dates. Will you accept the fact that you do not get paid for one of the hours because the TZID shifted back one hour ? All are interesting cases of when NOT to use floating times. They do not change the problem no matter which is used. Now lets say you tied it to a UTC (not floating). Your CUA knows the the UTC math. It can easily generate one, two, or more VEVENTs that describe exactly what the CU wants using DURATION. The CU never needs to know the specific iCal details. And in the other rare cases a CUA would have to generate one, two, or more DTEND VEVENTs for similar reason. I do not know of a single CUA that compares multiple Attendee TZID to checks them against time zone changes on optimizes DURATION or DTEND. My testing and examining of objects show that CUAs send one OR the other, and accept both. Duplicate procedure for exactly the same thing. > Your choice to prefer duration over dtend appears based on the assumption > they can represent the same information. It can represent the same information. Just perhaps not in exactly one object. So ether way you have the multiple TZID across time shift problems. Few CUAs allow the user to select DTEND or DURATION. THE REAL PROBLEM: YOUR-BOSS-CUA-WORK generates DURATION. YOUR-CUA-WORK generates DTEND. So your boss tells the company calendar you will be here 10 hours on that rare day when DURATION is longer. Saved as 'floating time' appointment. You read your company calendar with YOUR-CUA-WORK which converts a DURATION to a DTEND for display. It notices the TZID shift and subtracts out the hour to display the correct time and it uses the end time as the display time. Your fired - you left work early. Should your CUA have calculated the shift based on the start time? End time? Duration? Was your CUA busted? Your bosses CUA bused? CALSIFY - lets all do it exactly one way. With DURATION all calculation have to be done relative to the start time. It has to, there is no end time. NO CUA I have found says: "I know you specified an DTEND time, however the time shift occurs on that night, do you want to adjust it or not?" Same problem with DURATION: "I know you specified an DURATION, however the time shift occurs on that night, do you want to adjust it or not?" Your CUA can not tell why you entered the value. > Are you sure this is the case? It sure doesn't look like it to me. I still think so, again perhaps not in exactly one object. I do think we need to reduce the number of ways to do exactly the same thing to 'one'. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------020704050607030706020408 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------020704050607030706020408-- --------------ms000907010708020608000507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDAzMDgwMjQ4WjAjBgkqhkiG9w0BCQQxFgQU5RrTfWkEdcl6yKtEJk/4 8IhEZZUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEATbWRrGLhUJQkZeZf7DN5E/WAJuXexKDUOgWs7vQnou4RWIs8UxRSV1b6xLsb2sTG 7vWua9g0w2Fv8xOgO4K6uy1f8Nf8TE05K1Q4yPiP+X9+P88gY9o6UkzMC6p8xoohWtGduv4a VOsBPB7pIzm1chgkMt8XONtkV47srOLS743vCLRG1696MNh6ciYUUSDiLcPRrwbiImF/IKS3 93SkrbA5jkBt1errDjsIYWflxb6kTio5iI4xYacPjBS+S7Kn2pawFohJyFwuOroEffZnSpWJ XUQSdNbnX8jcn4EZUFJXQKAfrCzczCJnNHbjX1LI/mRpzxRYCpcV4TKFBotsvAAAAAAAAA== --------------ms000907010708020608000507-- X-Envelope-From: sroberts@uniserve.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from tomts25-srv.bellnexxia.net (tomts25-srv.bellnexxia.net [209.226.175.188]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j336QXaZ022816 for <ietf-calsify@osafoundation.org>; Sat, 2 Apr 2005 22:26:33 -0800 Received: from ensemble.local ([64.229.170.33]) by tomts25-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050403062632.LBJV27245.tomts25-srv.bellnexxia.net@ensemble.local> for <ietf-calsify@osafoundation.org>; Sun, 3 Apr 2005 01:26:32 -0500 Received: by ensemble.local (Postfix, from userid 501) id 8C66B42DD92; Sun, 3 Apr 2005 01:26:02 -0500 (EST) Date: Sun, 3 Apr 2005 01:26:02 -0500 From: Sam Roberts <sroberts@uniserve.com> To: ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) Message-ID: <20050403062602.GA7801@ensemble.local> References: <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7609.3070006@Royer.com> <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> <424F7520.4000204@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424F7609.3070006@Royer.com> <424F7520.4000204@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by kahuna.osafoundation.org id j336QXaZ022816 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 06:26:36 -0000 Quoting Doug@royer.com, on Sat, Apr 02, 2005 at 09:46:24PM -0700: > > > Sam Roberts wrote: > >Quoting Doug@royer.com, on Sun, Jan 16, 2005 at 02:11:43PM -0700: > > > >>I send -01 of iCal-Basis to the IETF. It fixed some problems and > >>typos that were sent to me and the lists. It also deprecates DTEND and > >>replaced the examples and ABNF with DURATION. > > > > > >dtstart/dtend and dtstart/duration are equivalent ONLY for single > >non-recurring events. > > > >A yearly event on that starts at april second 3PM, and goes until > >april 3 6PM will have different durations. This year it falls on > >DST. The duration will be different next year. > > It can't as not all time zones change at the same time. Your doing It can't "what"? > the math in the TZ and that can product different results across > time zones for the same instance. You have to convert each instance > to UTC, then do the math to make it work in all TZ's. Then you will see > that the all have the same duration. You seem to be talking about the event in different timezones. I'm talking about the event in one timezone, but with multiple occurences. If I have an event from 1AM to 11AM, on Aprils 3rd, it's duration will be 9 hours, in 2005. In 2006, the duration will be 10 hours. So, DTSTART:20050403T010000 DURATION:P9H RDATE:20050403,20060403 This year, it will end at 11AM, next year at 10 AM. Your choice to prefer duration over dtend appears based on the assumption they can represent the same information. Are you sure this is the case? It sure doesn't look like it to me. Quoting Doug@royer.com, on Sat, Apr 02, 2005 at 09:50:17PM -0700: > >Anything starting on the 25th and going to the "-1th"/last day of the > >month will have a different duration every month. Etc. > > > However, I do not know of any CUA that can set the DTEND to that value. > At the very least it is not in most products. And it is a great example. > In my entire life, I have never needed to set such an end time for > anything. This has nothing to do with DURATION, but you've never had an event that ended on the last day of the month? Thats weird, having things end on the last day of the month is probably almost as common as starting on the first. What about quarter end at your company, not an event? Doesn't end on the last day of a month? Doesn't repeat? Or your pay periods, they don't go from the 15th to the end? > CALSIFY is about what we "NEED", not what we might want to do. Right, so back to the DURATION issue. I need to represent events that start at X o'clock, end at Y o'clock, each time they occur, and I don't think I can with DURATION. > We need it to work with most products. A product that can't calculate dtend from dtstart/duration or duration from dtstart/dtend won't interoperate with anything. A programmer who can't add and subtract times can't implement a calendar spec. Sam X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j334oMaa013285 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sat, 2 Apr 2005 20:50:24 -0800 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j334oI61029669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 2 Apr 2005 20:50:21 -0800 Message-ID: <424F7609.3070006@Royer.com> Date: Sat, 02 Apr 2005 21:50:17 -0700 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org References: <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> In-Reply-To: <20050403022715.GB7536@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020907010802030201050000" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 04:50:25 -0000 This is a cryptographically signed message in MIME format. --------------ms020907010802030201050000 Content-Type: multipart/mixed; boundary="------------070604070905000009080609" This is a multi-part message in MIME format. --------------070604070905000009080609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit oops - hit the send key, I was not done typing... > Anything starting on the 25th and going to the "-1th"/last day of the > month will have a different duration every month. Etc. However, I do not know of any CUA that can set the DTEND to that value. At the very least it is not in most products. And it is a great example. In my entire life, I have never needed to set such an end time for anything. CALSIFY is about what we "NEED", not what we might want to do. We need interoperability. We need it to work with most products. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------070604070905000009080609 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------070604070905000009080609-- --------------ms020907010802030201050000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDAzMDQ1MDE3WjAjBgkqhkiG9w0BCQQxFgQUYSyaz5R+3TwIG8qHN5gb /HxiTzEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAjYodZIJ05kscuSymoDfqWa2/Su1+LxCLPsL2a1fgwl82IFVGTlgzkHnDRendsxzr qRruPX9w5BDMQkfLDCyQSpcrUkUUn/5dTF8t/YGofKYhU+sHys6zjLXP9v5EU5xV0l4vEHQk wUqvPbpNnzykhC3+nDEBxVoG66HITX3//w6m7IsZpmatqyxzX/rL5HDI6MDrZvQCK3cd4wAr IU+BerD9N3kUUk0Tkmkz4H+YQ9UGjLXOe2VWn8zFyONFV0FNw1SoCNGgHLSTZXRWwuskVfA7 7YATtMoUhoAvdmCNfnnEEY+vO7cFAoKUKwbig6YWEfotVBOvtwvBJHSg4AetAwAAAAAAAA== --------------ms020907010802030201050000-- X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j334kVaa013136 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sat, 2 Apr 2005 20:46:32 -0800 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j334kP68029625 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 2 Apr 2005 20:46:28 -0800 Message-ID: <424F7520.4000204@Royer.com> Date: Sat, 02 Apr 2005 21:46:24 -0700 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify@osafoundation.org References: <41EAD88F.1030601@Royer.com> <20050403022715.GB7536@ensemble.local> In-Reply-To: <20050403022715.GB7536@ensemble.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060805020406000609020403" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ietf-calsify@osafoundation.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 04:46:35 -0000 This is a cryptographically signed message in MIME format. --------------ms060805020406000609020403 Content-Type: multipart/mixed; boundary="------------070209010901070608090501" This is a multi-part message in MIME format. --------------070209010901070608090501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sam Roberts wrote: > Quoting Doug@royer.com, on Sun, Jan 16, 2005 at 02:11:43PM -0700: > >>I send -01 of iCal-Basis to the IETF. It fixed some problems and >>typos that were sent to me and the lists. It also deprecates DTEND and >>replaced the examples and ABNF with DURATION. > > > dtstart/dtend and dtstart/duration are equivalent ONLY for single > non-recurring events. > > A yearly event on that starts at april second 3PM, and goes until > april 3 6PM will have different durations. This year it falls on > DST. The duration will be different next year. It can't as not all time zones change at the same time. Your doing the math in the TZ and that can product different results across time zones for the same instance. You have to convert each instance to UTC, then do the math to make it work in all TZ's. Then you will see that the all have the same duration. > Anything starting on the 25th and going to the "-1th"/last day of the > month will have a different duration every month. Etc. That can only be done with a DTEND, not a DURATION. There is no way to say "-1th"/last day of the month in a DURATION. > It's also trivial to support doing the calculation of duration/dtend for > a specific event. > > Do you ever intend to support recurring events again? > > I just hours ago wrote a little server that publishes all the birthdays > in my address book as text/calendar over http, which is handy because my > calendar program now subscribes to it. Those birthdays recur! > > Sam -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------070209010901070608090501 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------070209010901070608090501-- --------------ms060805020406000609020403 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDAzMDQ0NjI0WjAjBgkqhkiG9w0BCQQxFgQUHge6/j/Qo0KGMPfSEFq4 PrmayYYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEArj0FxEk14uKBafbrwfO3SG2rrv4UHoe6GCBH/Tu1Gz0MckXb4Mq0rszC3iGii1uB cCWXC+/GYG2a1nMYBfnHOlBrHAWRUApPnWIqCFA8BVzOyiVLF+oGvaK1/LWQr+9xi5HAue5X aKbKHza+BKNdEVoL+qjls/E54ohuv2xyBEGO1o8nyvRLCHvaowDK1UAwbC4YWNALtq8wQU6C JFZlhjFInWnkCVxOGLHSXwxs6ep+Krv1yKw9TnQJ5jtIThDcP/GyKNGDWrTJycFfgz60OjSm lIK0WFAWxYw0doW+yECpXEb9sfV4aArKH8XRj0bTsx53x5vJqep7y4Nt/YtXYQAAAAAAAA== --------------ms060805020406000609020403-- X-Envelope-From: sroberts@uniserve.com Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j332RkaZ006430; Sat, 2 Apr 2005 18:27:46 -0800 Received: from ensemble.local ([64.229.170.33]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050403022745.VBOS26102.tomts10-srv.bellnexxia.net@ensemble.local>; Sat, 2 Apr 2005 21:27:45 -0500 Received: by ensemble.local (Postfix, from userid 501) id 369AD42D2B0; Sat, 2 Apr 2005 21:27:16 -0500 (EST) Date: Sat, 2 Apr 2005 21:27:15 -0500 From: Sam Roberts <sroberts@uniserve.com> To: Doug Royer <Doug@royer.com> Message-ID: <20050403022715.GB7536@ensemble.local> References: <41EAD88F.1030601@Royer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41EAD88F.1030601@Royer.com> User-Agent: Mutt/1.5.6i X-Spam-Score: 1.8 (*) DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 X-Mailman-Approved-At: Sun, 03 Apr 2005 14:05:02 -0700 Cc: ietf-calsify@osafoundation.org, CalDAV DevList <ietf-caldav@osafoundation.org>, "ietf-calendar@imc.org" <ietf-calendar@imc.org> Subject: [Ietf-calsify] dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF) X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 02:27:49 -0000 Quoting Doug@royer.com, on Sun, Jan 16, 2005 at 02:11:43PM -0700: > I send -01 of iCal-Basis to the IETF. It fixed some problems and > typos that were sent to me and the lists. It also deprecates DTEND and > replaced the examples and ABNF with DURATION. dtstart/dtend and dtstart/duration are equivalent ONLY for single non-recurring events. A yearly event on that starts at april second 3PM, and goes until april 3 6PM will have different durations. This year it falls on DST. The duration will be different next year. Anything starting on the 25th and going to the "-1th"/last day of the month will have a different duration every month. Etc. It's also trivial to support doing the calculation of duration/dtend for a specific event. Do you ever intend to support recurring events again? I just hours ago wrote a little server that publishes all the birthdays in my address book as text/calendar over http, which is handy because my calendar program now subscribes to it. Those birthdays recur! Sam > Copy at: > > http://inet-consulting.com/draft-royer-ical-basic-01.txt > > And HTML version at: > > http://inet-consulting.com/draft-royer-ical-basic-01.html > > -- > > Doug Royer | http://INET-Consulting.com > -------------------------------|----------------------------- > Doug@Royer.com | Office: (208)612-4638 > http://Royer.com | Fax: (866)594-8574 > | Cell: (208)520-4044 > > We Do Standards - You Need Standards > X-Envelope-From: Doug@Royer.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from royer.com (inet-consulting.com [4.23.9.166]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id j330T9aa026306 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for <ietf-calsify@osafoundation.org>; Sat, 2 Apr 2005 16:29:10 -0800 Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j330T010027410 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-calsify@osafoundation.org>; Sat, 2 Apr 2005 16:29:03 -0800 Message-ID: <424F38CC.7070102@Royer.com> Date: Sat, 02 Apr 2005 17:29:00 -0700 From: Doug Royer <Doug@Royer.com> Organization: IntelliCal.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Calsify <ietf-calsify@osafoundation.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020500000401040002050604" Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism) X-INET-Consulting.com-MailScanner-Information: Please contact SiteAdmin@INET-Consulting.com for more information X-INET-Consulting.com-MailScanner: Found to be clean X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] draft-royer-itip-basic-00.txt X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Calsify <ietf-calsify@osafoundation.org> List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sun, 03 Apr 2005 00:29:13 -0000 This is a cryptographically signed message in MIME format. --------------ms020500000401040002050604 Content-Type: multipart/mixed; boundary="------------040902030206040601090705" This is a multi-part message in MIME format. --------------040902030206040601090705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit iTIP-Basic should be making the archives soon. In addition to the removed objects (VJOURNAL, ..) I proposed a method for updating and canceling instances with out having to have RECURRENCE-ID in iCal-Basic. See the sections in CANCEL and REQUEST. See "3.2.5 CANCEL" If this WG thinks it is a bad idea, it is easy to remove. I think it makes iTIP-Basic just as functional as iTIP without having to have RECURRENCE-ID and 'recur' properties. It also makes only one procedure for adding instances: METHOD:ADD. And it clarifies how to use SEQUENCE for each condition. I removed all of the iTIP examples. Once this settles, I think that examples can be released in a separate draft or added to this one. -- Doug Royer | http://INET-Consulting.com -------------------------------|----------------------------- We Do Standards - You Need Standards --------------040902030206040601090705 Content-Type: text/x-vcard; charset=utf-8; name="Doug.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Doug.vcf" begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consuiting.com adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A email;internet:Doug@Royer.com title:CEO tel;work:208-612-4638 tel;fax:866-494-8574 tel;cell:208-520-4044 x-mozilla-html:TRUE url:http://Royer.com version:2.1 end:vcard --------------040902030206040601090705-- --------------ms020500000401040002050604 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3 DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5 jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2 6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53 CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1 YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2 b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ +SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0 +RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNDAzMDAyOTAwWjAjBgkqhkiG9w0BCQQxFgQUv4vEFyjAtt8rs+F89R+V o7dLR3YwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB 4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB BQAEggEAhzU+L4cGlf542cF80mQgvcXRBsKgshJTj1emUBzRIIop6FClylmtU+I5feQOF+f0 sNcZOVnthgC0VAvyQBykULhji1JPbHTcSwDHke1qdV4Kels4jAWzV8k3xHhaA8DY0awP5N3e XXtSD4BxiYzg5/sCDfvDIniCtAmfyZeh/9vyiBT62egb5Bnii6JXgUdQkLZFx6SfHXhnK0Pe U5AVdhOsjjP4vCrChT8GfGM6Qpd7fx89Lb32V4minZcu1m5e+nIFuAiUPfZMVfb4MIg7DjWp JYgSGTyoGsEMkUzbsGiUq/wuUzvc05ry932T3u3fVW8I6lfUAnHZWxcnaDvCkAAAAAAAAA== --------------ms020500000401040002050604-- X-Envelope-From: dthewlis@dcta.com X-Envelope-To: <ietf-calsify@osafoundation.org> Received: from smtp808.mail.sc5.yahoo.com (smtp808.mail.sc5.yahoo.com [66.163.168.187]) by kahuna.osafoundation.org (8.12.8/8.12.8) with SMTP id j32EUJaZ001834 for <ietf-calsify@osafoundation.org>; Sat, 2 Apr 2005 06:30:20 -0800 Received: from unknown (HELO ?192.168.0.100?) (dave.thewlis@sbcglobal.net@69.107.121.36 with plain) by smtp808.mail.sc5.yahoo.com with SMTP; 2 Apr 2005 14:30:19 -0000 Message-ID: <424EAC6B.4090001@dcta.com> Date: Sat, 02 Apr 2005 06:30:03 -0800 From: "David C. Thewlis" <dthewlis@dcta.com> Organization: DCTA Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-calsify list <ietf-calsify@osafoundation.org> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.663 (*) HTML_20_30,HTML_MESSAGE,MIME_HTML_ONLY X-Scanned-By: MIMEDefang 2.48 on 127.0.0.1 Subject: [Ietf-calsify] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.4 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: ietf-calsify.osafoundation.org List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=unsubscribe> List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify> List-Post: <mailto:ietf-calsify@osafoundation.org> List-Help: <mailto:ietf-calsify-request@osafoundation.org?subject=help> List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>, <mailto:ietf-calsify-request@osafoundation.org?subject=subscribe> X-List-Received-Date: Sat, 02 Apr 2005 14:30:21 -0000 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Dear IETF-Calsify:<br> <br> This e-mail is going to IETF-Caldav, IETF-Calsify, IETF-Calendar and www-rdf-calendar. My apologies if you get it more than once (which I'm afraid most people probably will).<br> <br> The Recurrence Technical Committee of Calconnect - The Calendaring and Scheduling Consortium - needs your help. The Committee is collecting specific informationon how C&S implementations have, or have not, <br> implemented the Recurrence Rules of RFCs 2445 and 2446, iCalendar and iTIP, as part of its work to compile actual usage informaton and interoperability issues. <br> <br> The information collected will be analyzed and the results, with specific product identifications eliminated, will be transmitted to the incipient CALSIFY Working Group of the IETF as soon as possible. The results will also be made generally available on the Consortium website, and will be input to Technical Committee recommendations to be formulated once the results are available.<br> <br> If you are willing to help, please fill out the questionnaire linked below. This is <b>absolutely NOT limited</b> <b>to Consortium members</b>; we need responses for as many products and implementations as possible for the <br> results to be of maximum value. The questionnaire may be found at:<br> <br> <a class="moz-txt-link-freetext" href="http://www.calconnect.org/recurrencequestionnaire.html">http://www.calconnect.org/recurrencequestionnaire.html</a><br> <br> Thank you for participating; I'll post again as soon as results are available.<br> <br> Dave Thewlis, Executive Director<br> CalConnect - The Calendaring and Scheduling Consortium<br> <br> <br> </body> </html>
- [Ietf-calsify] General Notification -- June Inter… Dave Thewlis