Subject: [Ietf-calsify] Further about the Calconnect Recurrence Questionnaire - status, thanks, and future developments

From: Dave.Thewlis at calconnect.org (Dave Thewlis)
Date: Mon Apr 25 10:33:24 2005

An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050425/480609ec/attachment.htm

Date: Mon, 25 Apr 2005 10:31:05 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Further about the Calconnect Recurrence Questionnaire - status, thanks, and future developments
Reply-To: [email-masked]

<!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.&nbsp; 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.&nbsp; 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.&nbsp; We hope to have our analysis done and a report issued in
the next few weeks.&nbsp; The report will be posted on the Calconnect web
site and will be announced publicly to these discussion lists.&nbsp; 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.&nbsp; 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.&nbsp; We
hope to announce it within the next two-three weeks. &nbsp;<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.&nbsp; 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&nbsp; 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>

Date: Mon, 18 Apr 2005 09:33:58 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] General Notification -- June Interop Tests and Roundtable III -- Calconnect:  The Calendaring and Scheduling Consortium
Reply-To: [email-masked]

<!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>&nbsp;Date:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;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>&nbsp;From:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;David C. Thewlis<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;To:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Copy:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"Robert Tolmach - WellGood Group" <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Subject:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;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:[email-masked]">&lt;[email-masked]&gt;</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:[email-masked]">&lt;[email-masked]&gt;</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:[email-masked]">[email-masked]</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
&lt;20041202154833.YTO5357.fed1rmmtao04.cox.net@davet23&gt; Thu, 2 Dec
2004 10:48:33 -0500<br>
Message-ID: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
References: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</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:[email-masked]">[email-masked]</a><br>
From: "David C. Thewlis" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
To: "calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF
CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
Cc: "Robert Tolmach - WellGood Group" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</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:[email-masked]">[email-masked]</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:[email-masked]">&lt;[email-masked]&gt;</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.&nbsp; Our apologies if you
receive multiple copies.</em></div>
<div><em></em>&nbsp;</div>
<div>&nbsp;</div>
<div><strong>CALL FOR PARTICIPATION -- THIRD INTEROP TESTING EVENT -&nbsp;
1-2 June 2005<br>
<br>
CONSORTIUM ROUNDTABLE III MEMBER MEETINGS 1-3 June 2005<br>
</strong></div>
<div>&nbsp;</div>
<div>The third Interop of The Calendaring and Scheduling Consortium
(CALCONNECT.ORG) will take place Wednesday and Thursday, June 1-2,
2005.&nbsp; It will be hosted by Duke University in Durham, North Carolina.</div>
<div>&nbsp;</div>
<div>This event will feature multiple Interop testing scenarios.&nbsp;
Participating organizations are welcome to test against multiple
scenarios.&nbsp; These scenarios will be going on
simultaneously so you will probably need a person for each scenario you
participate in.</div>
<div>&nbsp;<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&nbsp;limited to 40 paticipants in both the Roundtable and
Interop so early&nbsp;notification and registration is advised.</div>
<div>&nbsp;</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.&nbsp; 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&lt;--&gt;RDF<br>
  </li>
</ul>
&nbsp;
<div><strong>WHO MAY PARTICIPATE IN THE INTEROPS</strong></div>
<div>&nbsp;</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.&nbsp; Consortium members receive a
substantial discount on their Interop participation fee (see below).</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><strong>CONSORTIUM ROUNDTABLE III</strong></div>
<div>&nbsp;</div>
<div>Technical committee meetings&nbsp;of the Calendaring and Scheduling
Consortium are planned for&nbsp;1-2 June at the same location, followed by
an all-hands&nbsp;Consortium Roundtable on Friday 3 June.&nbsp; Interop
participants who are not&nbsp;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).&nbsp; 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>&nbsp;</div>
<div>&nbsp;</div>
<div><strong>REGISTRATION FEE</strong></div>
<div>&nbsp;</div>
<div><b>Interop:</b> $1500 for Consortium
members and $2500 for non-members.&nbsp; The registration fee covers two
individuals; additional individuals are $275 each for members or
non-members.&nbsp; (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>&nbsp;</div>
<div><strong></strong>The Interop
Registration Fee also covers participation in the&nbsp;Consortium Roundtable
for members or declared observers.</div>
<div>&nbsp;<br>
<b>Roundtable:</b>&nbsp; $275 per individual until 15
May and $325 thereafter.&nbsp; Registration for the Roundtable does <b>not</b>
include Interop participation.<br>
</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><strong>HOW TO REGISTER AND FURTHER INFORMATION</strong></div>
<div>&nbsp;</div>
<div>Logistics, registration and other information may be found on the
Consortium Website:&nbsp; 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>&nbsp;</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.&nbsp; Plan
to register as soon as possible to ensure we will have room.<br>
<br>
</div>
<div>&nbsp;</div>
<div>Best Regards,</div>
<div>&nbsp;</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:[email-masked]">[email-masked]</a></div>
<div><a href="http://www.calconnect.org">www.calconnect.org</a></div>
</div>
.
</body>
</html>

To: Calsify <[email-masked]>
From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[email-masked]>
Date: Sun, 17 Apr 2005 02:05:17 -0700
Subject: [Ietf-calsify] Lawmakers pass bill switching Indiana to DST

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.
[email-masked]
--------------------------------------------------------------

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."

Date: Sat, 16 Apr 2005 13:43:46 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

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:[email-masked]
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

--------------ms090109010108080207020501--

From: Jonathan Lennox <[email-masked]>
Date: Sat, 16 Apr 2005 15:13:53 -0400
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal

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

Date: Fri, 15 Apr 2005 17:52:07 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

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
> [email-masked]
> 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:[email-masked]
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

--------------ms050607000107040207010204--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
Date: Sat, 16 Apr 2005 01:11:06 +0200

--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: [email-masked], 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

--nextPart3848868.K4LTYAAvLg--

Date: Fri, 15 Apr 2005 16:44:05 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

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:[email-masked]
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

--------------ms020504060809040707030604--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
Date: Fri, 15 Apr 2005 23:32:35 +0200

--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: [email-masked], 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

--nextPart1933131.6x2V84qrrv--

Date: Fri, 15 Apr 2005 14:40:51 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

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:[email-masked]
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

--------------ms050800060408060104050001--

Date: Fri, 15 Apr 2005 14:33:26 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms090606000704060607060902--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
Date: Fri, 15 Apr 2005 21:29:10 +0200

--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: [email-masked], 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

--nextPart1323657.Ar5Lr5Gax4--

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Fri, 15 Apr 2005 21:17:47 +0200
Lines: 24
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: DURATION and PERIOD - proposal

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Fri, 15 Apr 2005 12:59:20 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>, Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: 
Subject: [Ietf-calsify] Document Action: 'Calendar Access Protocol (CAP)' to Experimental RFC 
Reply-To: "[email-masked]" <[email-masked]>

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 <[email-masked]>
To: IETF-Announce <[email-masked]>
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
[email-masked]
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:[email-masked]
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

--------------ms050803010100090309050007--

Date: Fri, 15 Apr 2005 12:55:24 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

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:[email-masked]
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

--------------ms040305080007040508040008--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
Date: Fri, 15 Apr 2005 20:47:19 +0200

--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: [email-masked], 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

--nextPart2665327.SZcoyjWxIq--

Date: Fri, 15 Apr 2005 12:30:53 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms040502040509080308070409--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
Date: Fri, 15 Apr 2005 20:25:09 +0200

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: [email-masked], 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

Date: Fri, 15 Apr 2005 12:01:31 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms040800010000090906020705--

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Fri, 15 Apr 2005 19:47:01 +0200
Lines: 12
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: DURATION and PERIOD - proposal

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

Date: Fri, 15 Apr 2005 11:43:36 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: DURATION and PERIOD - proposal
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms060906000405080108060501--

Date: Fri, 15 Apr 2005 08:28:20 -0700
From: Bruce Atherton <[email-masked]>
Subject: Re: [Ietf-calsify] PERIOD types
To: [email-masked]

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?

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Date: Fri, 15 Apr 2005 10:32:06 +0200

--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: [email-masked], 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

--nextPart3097795.HoQvly9dmg--

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Fri, 15 Apr 2005 09:25:53 +0200
Lines: 11
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: DURATION and PERIOD - proposal

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

Date: Thu, 14 Apr 2005 17:02:40 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] DURATION and PERIOD - proposal
Reply-To: Calsify <[email-masked]>

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:[email-masked]
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

--------------ms010608050500070406040203--

Date: Thu, 14 Apr 2005 11:29:31 -0700
From: Bruce Atherton <[email-masked]>
Subject: Re: [Ietf-calsify] PERIOD types
To: [email-masked]

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?

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Date: Thu, 14 Apr 2005 10:14:50 +0200

--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: [email-masked], 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

--nextPart3543096.UUetT17n2Y--

Date: Wed, 13 Apr 2005 11:51:48 -0700
From: Bruce Atherton <[email-masked]>
Subject: Re: [Ietf-calsify] PERIOD types
To: Sam Roberts <[email-masked]>
Cc: [email-masked]

Sam Roberts wrote:

>Quoting [email-masked], 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.

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Date: Wed, 13 Apr 2005 10:52:59 +0200

--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: [email-masked], 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

--nextPart17958621.B25AvhtcKJ--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
Date: Wed, 13 Apr 2005 10:51:01 +0200

--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: [email-masked], 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

--nextPart4820677.hT3GqovNy6--

Date: Wed, 13 Apr 2005 00:00:44 -0400
From: Cyrus Daboo <[email-masked]>
To: Sam Roberts <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Cc: 

Hi Sam,

--On April 11, 2005 10:29:35 PM -0400 Sam Roberts <[email-masked]> 
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

Date: Tue, 12 Apr 2005 20:47:00 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked], [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean

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:[email-masked]
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

--------------ms040702040102030409090701--

Date: Tue, 12 Apr 2005 18:23:33 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Mail-Followup-To: [email-masked]

Quoting [email-masked], on Mon, Apr 11, 2005 at 09:46:46PM -0600:
> 
> 
> Sam Roberts wrote:
> >Quoting [email-masked], 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

Date: Tue, 12 Apr 2005 18:20:20 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
Mail-Followup-To: [email-masked]

Quoting [email-masked], on Tue, Apr 12, 2005 at 11:14:37AM +0200:
> On Tuesday 12 April 2005 04:16, Sam Roberts wrote:
> > Quoting [email-masked], 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

Date: Tue, 12 Apr 2005 12:56:51 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms020105000901080401030605--

From: Jonathan Lennox <[email-masked]>
Date: Tue, 12 Apr 2005 08:58:00 -0400
To: Sam Roberts <[email-masked]>
Subject: Re: [Ietf-calsify] PERIOD types
Cc: [email-masked]

On Monday, April 11 2005, "Sam Roberts" wrote to "[email-masked]" 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

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Date: Tue, 12 Apr 2005 11:24:54 +0200

--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: [email-masked], 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

--nextPart1576497.RUokho6vrg--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
Date: Tue, 12 Apr 2005 11:24:19 +0200

--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: [email-masked], 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

--nextPart17131702.r7eHWp1T2v--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
Date: Tue, 12 Apr 2005 11:14:37 +0200

--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 [email-masked], 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
> >
> > "[email-masked]" 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: [email-masked], 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

--nextPart7233246.ZOxQ5Sm3gs--

Date: Mon, 11 Apr 2005 21:46:46 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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 [email-masked], 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:[email-masked]
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

--------------ms080804060507040004090506--

Date: Mon, 11 Apr 2005 21:41:58 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms050503080407030300090109--

Date: Mon, 11 Apr 2005 23:00:51 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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

Date: Mon, 11 Apr 2005 22:50:25 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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

Date: Mon, 11 Apr 2005 20:32:38 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms010907010302040409070502--

Date: Mon, 11 Apr 2005 22:29:35 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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

Date: Mon, 11 Apr 2005 20:22:50 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms080204020107030803040506--

Date: Mon, 11 Apr 2005 22:21:55 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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

Date: Mon, 11 Apr 2005 22:16:50 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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 
> "[email-masked]" 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

Date: Mon, 11 Apr 2005 22:10:44 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
Mail-Followup-To: [email-masked]

Quoting [email-masked], on Mon, Apr 11, 2005 at 05:44:47PM -0400:
> On Monday, April 11 2005, "Reinhold Kainhofer" wrote to "[email-masked]" 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

Date: Mon, 11 Apr 2005 21:51:19 -0400
To: [email-masked]
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Re: PERIOD types

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
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

Date: Mon, 11 Apr 2005 17:15:16 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms070306000703060003090602--

Date: Mon, 11 Apr 2005 17:09:22 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms030307050108010509030808--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Date: Tue, 12 Apr 2005 00:28:18 +0200

--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: [email-masked], 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

--nextPart23200271.ihL2WUrhVG--

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Tue, 12 Apr 2005 00:19:38 +0200
Lines: 12
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: PERIOD types

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

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
Date: Tue, 12 Apr 2005 00:08:00 +0200

--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
"[email-masked]" 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: [email-masked], 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

--nextPart4955196.fdbWMrTMAE--

Date: Mon, 11 Apr 2005 16:03:21 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms090603070801020608060806--

From: Jonathan Lennox <[email-masked]>
Date: Mon, 11 Apr 2005 17:44:47 -0400
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types

On Monday, April 11 2005, "Reinhold Kainhofer" wrote to "[email-masked]" 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

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
Date: Mon, 11 Apr 2005 23:30:46 +0200

--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: [email-masked], 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

--nextPart1483851.jQRzh01Qk0--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
Date: Mon, 11 Apr 2005 23:28:26 +0200

--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: [email-masked], 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

--nextPart3310813.57JFOgyxlo--

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Mon, 11 Apr 2005 23:05:02 +0200
Lines: 10
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: PERIOD types

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

Date: Mon, 11 Apr 2005 15:04:23 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean

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:[email-masked]
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

--------------ms030302070407050608050805--

From: Jonathan Lennox <[email-masked]>
Date: Mon, 11 Apr 2005 16:47:28 -0400
To: Michiel van Leeuwen <[email-masked]>
Subject: Re: [Ietf-calsify] Re: PERIOD types
Cc: [email-masked]

On Monday, April 11 2005, "Michiel van Leeuwen" wrote to "[email-masked]" 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

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Mon, 11 Apr 2005 22:42:09 +0200
Lines: 15
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: PERIOD types

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

Date: Mon, 11 Apr 2005 14:43:43 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms000207030902050108050909--

From: Jonathan Lennox <[email-masked]>
Date: Mon, 11 Apr 2005 16:36:33 -0400
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types

On Monday, April 11 2005, "Jonathan Lennox" wrote to "[email-masked]" 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

From: Jonathan Lennox <[email-masked]>
Date: Mon, 11 Apr 2005 16:14:18 -0400
To: [email-masked]
Subject: Re: [Ietf-calsify] PERIOD types

On Monday, April 11 2005, "Doug Royer" wrote to "[email-masked]" 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

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Mon, 11 Apr 2005 21:21:53 +0200
Lines: 14
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: PERIOD types

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

Date: Mon, 11 Apr 2005 13:13:43 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: PERIOD types
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms080305040808060708030205--

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Mon, 11 Apr 2005 21:06:09 +0200
Lines: 8
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: PERIOD types

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

Date: Mon, 11 Apr 2005 12:52:09 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] PERIOD types
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms060301090807070507090702--

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Mon, 11 Apr 2005 20:38:03 +0200
Lines: 15
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: 2nd and higher instance busted across time zone changes.

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

From: Jonathan Lennox <[email-masked]>
Date: Mon, 11 Apr 2005 13:46:50 -0400
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: 2nd and higher instance busted across time zone changes.

On Monday, April 11 2005, "Michiel van Leeuwen" wrote to "[email-masked]" 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

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Mon, 11 Apr 2005 19:16:35 +0200
Lines: 13
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: 2nd and higher instance busted across time zone changes.

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

Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
From: Martijn van Beers <[email-masked]>
To: [email-masked]
Date: Mon, 11 Apr 2005 12:44:04 +0200

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

Date: Sun, 10 Apr 2005 21:31:14 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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 "[email-masked]" 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:[email-masked]
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

--------------ms060504050009070108000309--

Date: Sun, 10 Apr 2005 21:14:30 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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 [email-masked], on Sat, Apr 09, 2005 at 11:14:35PM -0400:
> 
>>On Saturday, April 9 2005, "Doug Royer" wrote to "[email-masked]" 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:[email-masked]
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

--------------ms070303020108030209080607--

From: Jonathan Lennox <[email-masked]>
Date: Sun, 10 Apr 2005 22:56:46 -0400
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.

On Sunday, April 10 2005, "Sam Roberts" wrote to "[email-masked]" 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

Date: Sun, 10 Apr 2005 21:49:52 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
Mail-Followup-To: [email-masked]

Quoting [email-masked], on Sat, Apr 09, 2005 at 11:14:35PM -0400:
> On Saturday, April 9 2005, "Doug Royer" wrote to "[email-masked]" 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

Date: Sun, 10 Apr 2005 21:24:06 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Cyrus Daboo <[email-masked]>, [email-masked]
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
Cc: 

--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
>
> <[email-masked]> 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: [email-masked], 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

--nextPart1127370.KXCXXn4jE4--

Date: Sun, 10 Apr 2005 09:42:27 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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

Date: Sat, 09 Apr 2005 23:03:36 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked], [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean

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 "[email-masked]" 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:[email-masked]
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

--------------ms050809070808000302020304--

From: Jonathan Lennox <[email-masked]>
Date: Sat, 9 Apr 2005 23:14:35 -0400
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.

On Saturday, April 9 2005, "Doug Royer" wrote to "[email-masked]" 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

Date: Sat, 09 Apr 2005 20:22:01 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms020809010403090000030105--

Date: Sat, 09 Apr 2005 21:59:50 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone	changes.
Cc: 

Hi Reinhold,

--On Sunday, April 10, 2005 02:15:52 AM +0200 Reinhold Kainhofer 
<[email-masked]> 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

Date: Sat, 09 Apr 2005 19:51:13 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms080306090601080306080103--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
Date: Sun, 10 Apr 2005 02:15:52 +0200

--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: [email-masked], 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

--nextPart18254046.VJxPLOjJF2--

Date: Sat, 09 Apr 2005 16:54:34 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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
> [email-masked]
> 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:[email-masked]
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

--------------ms010305070403080805080201--

Date: Sat, 09 Apr 2005 15:46:05 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms080809050602060908010200--

Date: Sat, 9 Apr 2005 12:10:22 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
Mail-Followup-To: [email-masked]

Wrote Doug Royer <[email-masked]>, 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 <[email-masked]>

Subject: Re: [Ietf-calsify] Re: Comments on radical simplification and bumping	the version
To: [email-masked]
Date: Fri, 8 Apr 2005 15:43:30 -0400
From: [email-masked]

In trying to get caught up, I didn't see where this thread left off.  Maybe
there was no consensus...?
-CS

Date: Thu, 07 Apr 2005 21:51:03 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] 2nd and higher instance busted across time zone changes.
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms030107090700010605020009--

Date: Thu, 7 Apr 2005 23:24:50 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed?
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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.

Date: Thu, 07 Apr 2005 16:49:50 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed?
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms090901050904040003000307--

From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[email-masked]>
Subject: Re: [Ietf-calsify] Re: dtend removed?
Date: Thu, 7 Apr 2005 13:58:20 -0700
To: [email-masked]

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

Date: Thu, 07 Apr 2005 13:36:22 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed?
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms080104010707040000060707--

Date: Wed, 06 Apr 2005 09:36:10 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Calconnect Questionnaire on Recurrence - request responses by 11 April
Reply-To: [email-masked]

<!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.&nbsp; 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.&nbsp; <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:[email-masked]">[email-masked]</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.calconnnect.org">www.calconnnect.org</a><br>
<br>
</body>
</html>

Date: Wed, 6 Apr 2005 00:05:34 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed?
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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

Date: Tue, 05 Apr 2005 15:17:21 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re:	dtend	removed?	(Re:	draft-royer-ical-basic-01.txt - sent to IETF)
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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 
> <[email-masked]> 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:[email-masked]
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

--------------ms060300020404040802080703--

Date: Mon, 04 Apr 2005 22:50:08 -0400
To: [email-masked]
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Re: dtend removed?

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, [email-masked] 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
>
>
>[email-masked] 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 [email-masked], 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
> > > [email-masked]
> > > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> >
> >
> > _______________________________________________
> > Ietf-calsify mailing list
> > [email-masked]
> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

Subject: Re: [Ietf-calsify] Re: dtend removed?
Date: Mon, 4 Apr 2005 13:39:24 -0400
To: [email-masked]
From: [email-masked]
Cc: [email-masked], [email-masked]

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

[email-masked] 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 [email-masked], 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
> > [email-masked]
> > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Mon, 04 Apr 2005 10:28:30 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, Sam Roberts <[email-masked]>
Subject: Re: [Ietf-calsify] Re: dtend	removed?	(Re:	draft-royer-ical-basic-01.txt - sent to IETF)
Cc: [email-masked]

Hi Lisa,

--On April 3, 2005 22:26:16 -0700 Lisa Dusseault <[email-masked]> 
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

Date: Mon, 04 Apr 2005 01:05:03 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend	removed?	(Re:	draft-royer-ical-basic-01.txt - sent to IETF)
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms010702010301070707060309--

From: Lisa Dusseault <[email-masked]>
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 <[email-masked]>
Cc: [email-masked]

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 [email-masked], 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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Sun, 03 Apr 2005 22:13:22 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] Re: dtend	removed?	(Re:	draft-royer-ical-basic-01.txt - sent to IETF)
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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 [email-masked], 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:[email-masked]
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

--------------ms030505050907070005020003--

Date: Sun, 3 Apr 2005 23:18:13 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed?	(Re:	draft-royer-ical-basic-01.txt - sent to IETF)
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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

Date: Sun, 03 Apr 2005 19:02:15 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed?	(Re:	draft-royer-ical-basic-01.txt - sent to IETF)
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

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:[email-masked]
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

--------------ms010202000106030808030005--

From: =?ISO-8859-1?Q?Tantek_=C7elik?= <[email-masked]>
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 <[email-masked]>
Cc: [email-masked]

+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 [email-masked], 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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

Date: Sun, 03 Apr 2005 15:50:06 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify
Cc: Cameron Stillion <[email-masked]>, [email-masked]
Reply-To: [email-masked]

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 
> <[email-masked]> 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).
>

Date: Sun, 03 Apr 2005 18:46:32 -0400
From: Cyrus Daboo <[email-masked]>
To: Cameron Stillion <[email-masked]>, [email-masked]
Subject: RE: [Ietf-calsify] Help needed -- questionnaire on implementationof	Recurrence Rules -- Calconnect and Calsify
Cc: [email-masked]

Hi Cameron,

--On April 3, 2005 11:50:44 -0700 Cameron Stillion 
<[email-masked]> 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

Date: Sun, 03 Apr 2005 15:17:05 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Sam Roberts <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: [email-masked], CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Re: [Ietf-caldav] dtend removed? (Re: draft-royer-ical-basic-01.txt -	sent to IETF)
Reply-To: [email-masked]

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 [email-masked], 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
>>-------------------------------|-----------------------------
>>[email-masked]                 | 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 -- [email-masked]
> 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:[email-masked]
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

--------------ms010102060608050004010305--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-calsify] Re: Proposed Charter
Date: Sun, 3 Apr 2005 14:09:32 -0700
To: Michiel van Leeuwen <[email-masked]>
Cc: [email-masked]

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
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Sun, 03 Apr 2005 14:44:53 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed?	(Re:	draft-royer-ical-basic-01.txt - sent to IETF)
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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 [email-masked], 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:[email-masked]
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

--------------ms000804020902060207020903--

Date: Sun, 03 Apr 2005 13:37:37 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: Cameron Stillion <[email-masked]>
Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify
Cc: [email-masked]
Reply-To: [email-masked]

<!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.&nbsp; There's
now an "Other" option matched to each Yes/No.&nbsp; So if you can't answer
either Yes or No you can answer Other and hopefully tell us why.&nbsp; Or
leave the choice completely blank if you haven't already clicked
something as Cameron points out.<br>
<br>
Cameron Stillion wrote:
<blockquote
 cite="[email-masked]"
 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:[email-masked]">[email-masked]</a>
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</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:[email-masked]">[email-masked]</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:[email-masked]">&lt;[email-masked]&gt;</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:[email-masked]">[email-masked]</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>

Date: Sun, 3 Apr 2005 15:48:22 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Proposed Charter
Mail-Followup-To: [email-masked]

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 <[email-masked]>
> Scott Hollenbeck <[email-masked]>
> 
> Mailing Lists:
> 
> General Discussion: [email-masked]
> 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.

Date: Sun, 03 Apr 2005 12:00:50 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: Cameron Stillion <[email-masked]>
Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementationof Recurrence Rules -- Calconnect and Calsify
Cc: [email-masked]
Reply-To: [email-masked]

<!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.&nbsp; Maybe I need a "Neither" button.&nbsp; I don't want check boxes.&nbsp;
I don't know if you CAN reset a button once selected actually.&nbsp; <br>
<br>
Cameron Stillion wrote:
<blockquote
 cite="[email-masked]"
 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:[email-masked]">[email-masked]</a>
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</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:[email-masked]">[email-masked]</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:[email-masked]">&lt;[email-masked]&gt;</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:[email-masked]">[email-masked]</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>

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Help needed -- questionnaire on implementationof	Recurrence Rules -- Calconnect and Calsify
Date: Sun, 3 Apr 2005 11:50:44 -0700
From: "Cameron Stillion" <[email-masked]>
To: <[email-masked]>, "Cyrus Daboo" <[email-masked]>
Cc: [email-masked]

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave
Thewlis
Sent: Sunday.03.April.2005 10.37
To: Cyrus Daboo
Cc: [email-masked]
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 
> <[email-masked]> 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
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Content-class: urn:content-classes:message
Subject: RE: [Ietf-calsify] Proposed Charter
Date: Sun, 3 Apr 2005 11:46:13 -0700
From: "Cameron Stillion" <[email-masked]>
To: "Lisa Dusseault" <[email-masked]>, <[email-masked]>
Cc: 

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Lisa
Dusseault
Sent: Monday.28.March.2005 17.56
To: [email-masked]
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 <[email-masked]>
Scott Hollenbeck <[email-masked]>

Mailing Lists:

General Discussion: [email-masked] 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
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

To: [email-masked]
From: Michiel van Leeuwen <[email-masked]>
Date: Sun, 03 Apr 2005 20:24:04 +0200
Lines: 12
Sender: news <[email-masked]>
Subject: [Ietf-calsify] Re: Proposed Charter

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

Date: Sun, 3 Apr 2005 14:21:12 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Example RRULEs
Mail-Followup-To: [email-masked]

Quoting [email-masked], on Sun, Apr 03, 2005 at 02:19:31PM -0400:
> Hi Sam,
> 
> --On April 3, 2005 12:44:30 -0400 Sam Roberts <[email-masked]> 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

Date: Sun, 03 Apr 2005 14:19:31 -0400
From: Cyrus Daboo <[email-masked]>
To: Sam Roberts <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Example RRULEs
Cc: 

Hi Sam,

--On April 3, 2005 12:44:30 -0400 Sam Roberts <[email-masked]> 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

Date: Sun, 03 Apr 2005 11:13:37 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
CC: [email-masked]
Subject: Re: [Ietf-calsify] Example RRULEs
Reply-To: [email-masked]

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 <[email-masked]> 
> 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> 
>
>

Date: Sun, 03 Apr 2005 14:05:01 -0400
From: Cyrus Daboo <[email-masked]>
To: Sam Roberts <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Example RRULEs
Cc: 

Hi Sam,

--On April 3, 2005 12:44:30 -0400 Sam Roberts <[email-masked]> 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

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
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

--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 [email-masked], 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: [email-masked], 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

--nextPart1147345.Zga2141yH1--

Date: Sun, 03 Apr 2005 10:37:03 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementation of	Recurrence Rules -- Calconnect and Calsify
Cc: [email-masked]
Reply-To: [email-masked]

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 
> <[email-masked]> 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.
>

Date: Sun, 3 Apr 2005 13:26:57 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementation of	Recurrence Rules -- Calconnect and Calsify
Mail-Followup-To: [email-masked]

Quoting [email-masked], on Sun, Apr 03, 2005 at 12:49:15PM -0400:
> Hi Reinhold,
> 
> --On Sunday, April 03, 2005 06:31:27 PM +0200 Reinhold Kainhofer 
> <[email-masked]> 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

Date: Sun, 3 Apr 2005 13:13:05 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed? (Re:	draft-royer-ical-basic-01.txt - sent to IETF)
Mail-Followup-To: [email-masked]

Quoting [email-masked], 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

Date: Sun, 03 Apr 2005 12:49:15 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementation of	Recurrence Rules -- Calconnect and Calsify
Cc: 

Hi Reinhold,

--On Sunday, April 03, 2005 06:31:27 PM +0200 Reinhold Kainhofer 
<[email-masked]> 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

Date: Sun, 3 Apr 2005 12:44:30 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Example RRULEs
Mail-Followup-To: [email-masked]

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

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify
Date: Sun, 3 Apr 2005 18:31:27 +0200

--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: [email-masked], 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

--nextPart15675927.j9z6cPPI5z--

Date: Sun, 3 Apr 2005 12:20:34 -0400
From: Sam Roberts <[email-masked]>
To: "David C. Thewlis" <[email-masked]>
Subject: Re: [Ietf-calsify] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify
Mail-Followup-To: "David C. Thewlis" <[email-masked]>, [email-masked]
Cc: [email-masked]

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

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
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

--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: [email-masked], 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

--nextPart1402181.JsIVeZPEU2--

Date: Sun, 3 Apr 2005 11:25:14 -0400
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed? (Re:	draft-royer-ical-basic-01.txt - sent to IETF)

Quoting [email-masked], 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

Date: Sun, 03 Apr 2005 12:13:51 +0200
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Proposed Charter

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

Date: Sun, 03 Apr 2005 01:02:48 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed? (Re:	draft-royer-ical-basic-01.txt - sent to IETF)
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms000907010708020608000507--

Date: Sun, 3 Apr 2005 01:26:02 -0500
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)

Quoting [email-masked], on Sat, Apr 02, 2005 at 09:46:24PM -0700:
> 
> 
> Sam Roberts wrote:
> >Quoting [email-masked], 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 [email-masked], 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

Date: Sat, 02 Apr 2005 21:50:17 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)
Reply-To: [email-masked]

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:[email-masked]
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

--------------ms020907010802030201050000--

Date: Sat, 02 Apr 2005 21:46:24 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)
Reply-To: [email-masked]

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 [email-masked], 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:[email-masked]
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

--------------ms060805020406000609020403--

Date: Sat, 2 Apr 2005 21:27:15 -0500
From: Sam Roberts <[email-masked]>
To: Doug Royer <[email-masked]>
Cc: [email-masked], CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)

Quoting [email-masked], 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
> -------------------------------|-----------------------------
> [email-masked]                 | Office: (208)612-4638
> http://Royer.com               | Fax:    (866)594-8574
>                                | Cell:   (208)520-4044
> 
>               We Do Standards - You Need Standards
> 

Date: Sat, 02 Apr 2005 17:29:00 -0700
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-calsify] draft-royer-itip-basic-00.txt
Reply-To: Calsify <[email-masked]>

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:[email-masked]
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

--------------ms020500000401040002050604--

Date: Sat, 02 Apr 2005 06:30:03 -0800
From: "David C. Thewlis" <[email-masked]>
Organization: DCTA Inc.
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify
Reply-To: [email-masked]

<!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.&nbsp; 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.&nbsp; The Committee is collecting
specific informationon how C&amp;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.&nbsp; 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.&nbsp; 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.&nbsp; The questionnaire may be found at:<br>
<br>
&nbsp;<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>