Discussion list for revising the IETF's iCal specifications.

headers David C. Thewlis | 2 Apr 2005 16:30

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

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

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Quoting Doug <at> royer.com, on Sun, Jan 16, 2005 at 02:11:43PM -0700:
> I send -01 of iCal-Basis to the IETF. It fixed some problems and
> typos that were sent to me and the lists. It also deprecates DTEND and
> replaced the examples and ABNF with DURATION.

dtstart/dtend and dtstart/duration are equivalent ONLY for single
non-recurring events.

A yearly event on that starts at april second   3PM, and goes until
april 3 6PM will have different durations. This year it falls on
DST. The duration will be different next year.

Anything starting on the 25th and going to the "-1th"/last day of the
month will have a different duration every month. Etc.

It's also trivial to support doing the calculation of duration/dtend for
a specific event.

Do you ever intend to support recurring events again?

I just hours ago wrote a little server that publishes all the birthdays
in my address book as text/calendar over http, which is handy because my
calendar program now subscribes to it. Those birthdays recur!

Sam

> Copy at:
> 
> 	http://inet-consulting.com/draft-royer-ical-basic-01.txt
> 
> And HTML version at:
> 
> 	http://inet-consulting.com/draft-royer-ical-basic-01.html
> 	
> -- 
> 
> Doug Royer                     | http://INET-Consulting.com
> -------------------------------|-----------------------------
> Doug <at> Royer.com                 | Office: (208)612-4638
> http://Royer.com               | Fax:    (866)594-8574
>                                | Cell:   (208)520-4044
> 
>               We Do Standards - You Need Standards
> 

Sam Roberts wrote:
> Quoting Doug <at> royer.com, on Sun, Jan 16, 2005 at 02:11:43PM -0700:
> 
>>I send -01 of iCal-Basis to the IETF. It fixed some problems and
>>typos that were sent to me and the lists. It also deprecates DTEND and
>>replaced the examples and ABNF with DURATION.
> 
> 
> dtstart/dtend and dtstart/duration are equivalent ONLY for single
> non-recurring events.
> 
> A yearly event on that starts at april second   3PM, and goes until
> april 3 6PM will have different durations. This year it falls on
> DST. The duration will be different next year.

It can't as not all time zones change at the same time. Your doing
the math in the TZ and that can product different results across
time zones for the same instance. You have to convert each instance
to UTC, then do the math to make it work in all TZ's. Then you will see
that the all have the same duration.

> Anything starting on the 25th and going to the "-1th"/last day of the
> month will have a different duration every month. Etc.

That can only be done with a DTEND, not a DURATION. There is no
way to say "-1th"/last day of the month in a DURATION.

> It's also trivial to support doing the calculation of duration/dtend for
> a specific event.
> 
> Do you ever intend to support recurring events again?
> 
> I just hours ago wrote a little server that publishes all the birthdays
> in my address book as text/calendar over http, which is handy because my
> calendar program now subscribes to it. Those birthdays recur!
> 
> Sam

--

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

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

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Quoting Doug <at> royer.com, on Sat, Apr 02, 2005 at 09:46:24PM -0700:
> 
> 
> Sam Roberts wrote:
> >Quoting Doug <at> royer.com, on Sun, Jan 16, 2005 at 02:11:43PM -0700:
> >
> >>I send -01 of iCal-Basis to the IETF. It fixed some problems and
> >>typos that were sent to me and the lists. It also deprecates DTEND and
> >>replaced the examples and ABNF with DURATION.
> >
> >
> >dtstart/dtend and dtstart/duration are equivalent ONLY for single
> >non-recurring events.
> >
> >A yearly event on that starts at april second   3PM, and goes until
> >april 3 6PM will have different durations. This year it falls on
> >DST. The duration will be different next year.
> 
> It can't as not all time zones change at the same time. Your doing
It can't "what"?
> the math in the TZ and that can product different results across
> time zones for the same instance. You have to convert each instance
> to UTC, then do the math to make it work in all TZ's. Then you will see
> that the all have the same duration.

You seem to be talking about the event in different timezones. I'm
talking about the event in one timezone, but with multiple occurences.

If I have an event from 1AM to 11AM, on Aprils 3rd, it's duration will
be 9 hours, in 2005.

In 2006, the duration will be 10 hours.

So,

  DTSTART:20050403T010000
  DURATION:P9H
  RDATE:20050403,20060403

This year, it will end at 11AM, next year at 10 AM.

Your choice to prefer duration over dtend appears based on the assumption
they can represent the same information.

Are you sure this is the case? It sure doesn't look like it to me.

Quoting Doug <at> royer.com, on Sat, Apr 02, 2005 at 09:50:17PM -0700:
> >Anything starting on the 25th and going to the "-1th"/last day of the
> >month will have a different duration every month. Etc.
> 
> 
> However, I do not know of any CUA that can set the DTEND to that value.
> At the very least it is not in most products. And it is a great example.
> In my entire life, I have never needed to set such an end time for
> anything.

This has nothing to do with DURATION, but you've never had an event that
ended on the last day of the month? Thats weird, having things end on
the last day of the month is probably almost as common as starting on
the first. What about quarter end at your company, not an event? Doesn't
end on the last day of a month? Doesn't repeat? Or your pay periods,
they don't go from the 15th to the end?

> CALSIFY is about what we "NEED", not what we might want to do.

Right, so back to the DURATION issue.

I need to represent events that start at X o'clock, end at Y o'clock,
each time they occur, and I don't think I can with DURATION.

> We need it to work with most products.

A product that can't calculate dtend from dtstart/duration or duration
from dtstart/dtend won't interoperate with anything.

A programmer who can't add and subtract times can't implement a calendar
spec.

Sam

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

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

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

Quoting Doug <at> royer.com, on Sun, Apr 03, 2005 at 01:02:48AM -0700:
> Sam Roberts wrote:
> 

I removed my example, and used yours, since it shows the problem with
the reductionist approach so well.

> Lets say you work a 10pm - 6am work shift and are allowed
> to eat at 1am - 2am.

The example above is a concise example of why both representations are
necessary, simply understood, and model different things.

Case a:

  A shift of work: 10pm - 6am. This is when I work, those times being in
  my local timezone. Most days my shift will be 8 hours long, on
  occaisonal days it will be 7, and on others it will 9.

Maybe my company will pay me for the 8 hours on days I only work 7,
thats an accounting issue, not a scheduling issue. Either way, they
don't have two chairs at the security desk that I work at, there is no
point me standing there looking over the other guards shoulder. Our
shifts do not overlap, on any day.

This is an example of when DTEND would be used. DTSTART is when I start
work, DTEND is when I end work, very simple, always right.

Case b:

  My lunch break: it is at 1 AM, and I am allowed 1 hour. I don't get
  more or less.

This is an example of when DURATION would be used. You still allow this.

To answer your questions:

> Even with DTSTART and DTEND do you think your employer will allow you
> to take two hours in the rare cases that the TZID changes on those
> times?

No, breaks have a DURATION, not a start time and end time.

Your one size fits-all attitude would cause this problem, not fix it.

> Would you accept the fact that on other rare dates you can't
> eat at all because the 1am-2am went away?

So at 1AM, people set their clocks forward to 2am. But I set DURATION,
so 1 hour later is 3AM on this day, and I get the same time to eat
I get every other day.

The above point would be valid if you had chose to allow only
dtstart/dtend. In which case I would be complaining about that, but the
above case works fine with DURATION.

> Or do you have to be there 9 hours ether way? Or maybe 8 hours on rare
> dates, or 10 hours on rare dates.

Exactly.

> Will you accept the fact that you do not get paid for one of the hours
> because the TZID shifted back one hour?

I may file a union greviance, but there isn't room for two people to sit
at the guard desk, and there must be a guard there every hour of the
day, whether there are 23 or 25 hours in the day.

How I get payed for this is a problem well outside of the scope of
iCalendar! Probably, I don't get paid enough.

> >Your choice to prefer duration over dtend appears based on the assumption
> >they can represent the same information.
> 
> It can represent the same information. Just perhaps not in
> exactly one object. So ether way you have the multiple
> TZID across time shift problems. Few CUAs allow the user
> to select DTEND or DURATION.

You started off wanting to make things simple, and now you've introduced
the need for multiple objects, sometimes?

You started off by wanting to increase inter-operability, and now state
that half the implementations out there are non-compliant?

> THE REAL PROBLEM:
> 
> 	YOUR-BOSS-CUA-WORK generates DURATION.
> 	YOUR-CUA-WORK generates DTEND.
> 	
> 	So your boss tells the company calendar you will be
>         here 10 hours on that rare day when DURATION is
>         longer. Saved as 'floating time' appointment.
> 
> 	You read your company calendar with YOUR-CUA-WORK
>         which converts a DURATION to a DTEND for display. It notices
>         the TZID shift and subtracts out the hour to display
>         the correct time and it uses the end time as the
>         display time.
> 
> 	Your fired - you left work early.
> 
>         Should your CUA have calculated the shift based on
>         the start time? End time? Duration? Was your CUA
>         busted? Your bosses CUA bused?

If my boss specified I work for 8 hours his CUA should have encoded it
as he specified it (with dtstart/duration) - in which case I better work
8 hours.  My CUA will add 8 hours of duration to the dtstart, do it
correctly for my timezone, and display when the event ends on that
particular day so I quit at the correct time. Anything else is wrong.

If my boss specified that I work from 10PM to 6AM, his CUA should have
represented it as such, and my CUA better show my shift ending at 6AM.

> CALSIFY - lets all do it exactly one way.
> With DURATION all calculation have to be done relative
> to the start time. It has to, there is no end time.

The world doesn't work in one way.

Hospitals have 3 shifts a day, ending at fixed times, and not
overlapping.

Offices have 1 shift, starting at 9AM, and we work for 8 hours, no
matter when the end time is after 8 hours.

RFC2445 allows both to be trivially representable.

Your draft makes one trivial, and the other has to be represented as 3
objects.

To generate a shift that goes from 10PM to 6AM, every sunday of the
year, I have to notice that timezone changes on some sundays, generate
one event with a duration of 8 hours, exclude that event on all days in
which timezone changes occur, then put two other events, one with a
duration of 7 hours, the other with a duration of 9, that occur on
single sundays in the year, the DST adjustment days.

> NO CUA I have found says:
>  "I know you specified an DTEND time, however the time shift occurs
>   on that night, do you want to adjust it or not?"
> 
> Same problem with DURATION:
>  "I know you specified an DURATION, however the time shift occurs
>   on that night, do you want to adjust it or not?"
> 
> Your CUA can not tell why you entered the value.

The CUA doesn't have to do this, it should represent it exactly as the
BOSS entered it.

The problems you describe are all problems in conversion between the two
kinds of natural events, those with a fixed end, and those with a fixed
duration.

Since you propose to allow only one kind of representation, all the
problems you describe above occur. If you allow the two representations,
they don't occur.

This situation is CAUSED by your proposal, not fixed.

And a CUA that only allows inputting start and duration is incapable of
allowing my boss to input my shift that starts at 10PM and ends at 6AM.

This is a problem with that CUA, it is not a problem with RFC2445. Once
it's users complain, the CUA will implement events that end at a
specific time.

If you mention this issue in RFC2445bis, people might implement it
correctly the first time.

> >Are you sure this is the case? It sure doesn't look like it to me.

1 -

> I still think so, again perhaps not in exactly one object.

2 -

> I do think we need to reduce the number of ways to do
> exactly the same thing to 'one'.

Statements 1 and 2 are in direct conflict. One says there will be "one
way" to represent an even, the other says that in cases of events crossing
timezones the CUA will have to notice, and generate more than one
object. This is not "one way".

Why are you removing simple things that work well?

There are things in RFC2445 that are complicated, this isn't one of
them, leave it alone.

Sam

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 
the recurrences is really calculated. I couldn't find anything definitive in 
the rfc. 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. 

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 
2446, which doesn't allow your Hospital example (and since Doug also gave 
some sample calculations where he always implicitly used the duration to 
calculate the DTEND), I simply gave up resistence. 

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.

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. 
But then, I'm not sure if there is really a unique way to calculate the DTEND 
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 2445 
is simply lacking this capability (as strange as it may seem considering how 
over-engineered it is).

Cheers,
Reinhold

--

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold <at> kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

9	May 2013
2	April 2013
1	March 2013
6	February 2013
5	January 2013
1	December 2012
6	November 2012
1	September 2012
5	August 2012
1	July 2012
3	June 2012
1	April 2012
1	March 2012
2	December 2011
5	November 2011
1	October 2011
2	September 2011
6	August 2011
1	June 2011
2	May 2011
12	April 2011
6	March 2011
1	January 2011
8	December 2010
2	November 2010
9	September 2010
4	August 2010
8	July 2010
3	June 2010
9	May 2010
2	April 2010
5	March 2010
7	February 2010
8	January 2010
5	December 2009
6	November 2009
15	October 2009
12	September 2009
3	August 2009
3	July 2009
9	June 2009
6	May 2009
8	April 2009
1	March 2009
3	February 2009
34	January 2009
9	December 2008
32	November 2008
37	October 2008
16	September 2008
17	August 2008
31	July 2008
23	June 2008
8	May 2008
3	April 2008
21	March 2008
11	February 2008
24	January 2008
14	December 2007
20	November 2007
22	October 2007
50	September 2007
18	August 2007
31	July 2007
38	June 2007
28	May 2007
18	April 2007
83	March 2007
97	February 2007
48	January 2007
20	December 2006
75	November 2006
103	October 2006
96	September 2006
96	August 2006
34	July 2006
26	June 2006
53	May 2006
14	April 2006
9	March 2006
16	February 2006
6	January 2006
3	December 2005
32	November 2005
51	October 2005
32	September 2005
63	August 2005
51	July 2005
14	June 2005
16	May 2005
141	April 2005
16	March 2005
110	February 2005
14	January 2005
15	December 2004
9	November 2004
77	October 2004
101	September 2004
11	August 2004

Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify

draft-royer-itip-basic-00.txt

dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)

Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)

Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)

Re: Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)

Re: Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)

Re: Proposed Charter

Re: Re: dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)

Re: Re: dtend removed? (=?iso-8859-1?q?Re=3A=09draft-royer-ical-basic-01=2Etxt_-_sent_to?= IETF)