Subject: [Ietf-calsify] iCal-Basic - draft 00

From: Doug at Royer.com (Doug Royer)
Date: Sat Jan 8 09:39:17 2005

I know that there was a large debate on having both DURATION
and DTEND years ago that resulted in 2445. Now that we are trying
to simplify down to  the basics. Can we pick just one?

	DTSTART and optionally DURATION (no  DTEND in spec)

or

	DTSTART and optionally DTEND. (no DURATION in spec)

This is an data format for exchanging calendar information, it has
nothing to do with how any implementation stores the data. Is the
reason that both existed because the WG could not decide? Or
was there another reason?

-- 

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050108/6ada965c/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sat Jan 8 10:28:47 2005

>  DTSTART and optionally DTEND. (no DURATION in spec)

There's a small difference between these two. They are identical most of the 
time, except for those two times a year when DST switches occur. If you have 
a recurring event that falls on these switch times, you can easily see the 
difference:

1) You have nightshifts from 22:00 until 06:00 every day, so when the DST 
switch happens, your nightshift will be one hour longer/shorter than the 
usual 8 hours. => DTSTART and DTEND needed

2) On the other hand, if you need to operate a machine or some other 
mechanical process for, say, 15 hours over night, then the date end needs to 
differ for the night when the DST switch occurs. => DTSTART and DURATION 
needed

Cheers,
Reinhold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050108/4255717f/attachment.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Jan 8 14:46:47 2005

There are two effects - I agree.

Does anyone really need the first one (#1 below)? Or did they really
want a DURATION ? Having worked 3rd shift in he past, I still
only worked 8 hours, no more, no less. Do people have their 3rd
shift work one hour shorter/longer? I'll bet they still work
DTSTART + DURATION and just make sure everyone knows what time
the clock will say at the end.

In addition - iCal-Basic does not have recurring rules, so
would DURATION be sufficient?

Reinhold Kainhofer wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050108/854c2eed/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sat Jan 8 16:58:31 2005

Am Samstag, 8. Januar 2005 23:46 schrieb Doug Royer:
> Does anyone really need the first one (#1 below)? 

Sure, why not? The example I gave was really just meant as an example where 
it's easy to see the difference. I'm sure there are lots of events that are 
defined by their end date, not their duration. E.g. if you need to catch the 
train every morning, and you enter your sleeping time as a recurring event in 
your calendar (because during that time you want your f/b list to show you as 
busy, or for some other reason). 

> would DURATION be sufficient?

Yes, that's a good argument. I also had a long discussion over this with Helge 
Hess (from OpenGroupware.org).
As long as no recurrences are involved, DTSTART and DURATION is the right 
solution in our eyes. In particular, if you move an event, you only have to 
adjust the DTSTART and the end date will be correct. If you used DTSTART and 
DTEND, you'll have to adjust both if you want to move the event. 
Additionally, if you just use the same offset to the DTSTART and the DTEND, 
you'll again run into the same problems when the time zone shift appears 
between these two times...

I think it's really best to have DTSTART+DURATION in iCal-Basic, and in 
iCal-Extended we need to allow DTSTART+DTEND (since it makes a difference 
with recurring event). 

Cheers,
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050109/b93226be/attachment.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Jan 8 17:19:58 2005

> busy, or for some other reason). 

Your GUI might do that for you, however I can still calculate one
from the other - so I am not convinced that when we send an iCalendar
object to another CUA, that it cares why we elected to select that 
length of time or end time. The chances are that it will convert it to 
its favorite way (DURATION or LENGTH) anyway.

> between these two times...

Unless someone comes up with a reason iCal-Basic-01 will drop DTEND.

> iCal-Extended we need to allow DTSTART+DTEND (since it makes a difference 

I am still not convinced that it results in any different block of time 
to the ATTENDEEs that got your iCalendar object. Everyone would still 
show up at the same time and expect to leave at the same time relative 
to each other.

If your talking about an appointment for which there is never going to 
be a  PUBLISH or REQUEST sent, then the point is moot as you are always 
free to store your data that is not going to be sent to someone else any 
way you wish.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050108/d3ebf245/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sat Jan 8 19:01:26 2005

> show up at the same time and expect to leave at the same time relative

No, it makes a difference. See my two examples. The group which uses 
DTSTART+DURATION+recurrence would expect that the event ends one hour 
earlier/later than the group that uses DTSTART+DURATION+recurrence. Of course 
only if a DST shift happens while the event takes place (yes, that's a 
borderline case, but a standard that works only in 99% of all cases is 
useless. So ical-extended needs to specify it).

> free to store your data that is not going to be sent to someone else any

Ahm, are we talking about a revision of RFC 2445 or only of 2446? 

iCalendar (2445) is not only a format for group scheduling, but a general 
format for calendar data exchange. In particular, lots of calendaring 
applications use iCalendar as their standardized storage format (actually, 
all larger free/open source software packages, like KOrganizer, Evolution, 
Mozilla sunbird; and also Apple's iCal), which is very important for 
interopability and data im/export! 

Also note that RFC 2445 does explicitly say that it is meant not only as a 
format for scheduling, but for general calendar data interopability. In 
particular, from the Introduction of rfc2445:

   The iCalendar format is suitable as an exchange format between
   applications or systems. The format is defined in terms of a MIME
   content type. This will enable the object to be exchanged using
   several transports, including but not limited to SMTP, HTTP, a file
   system, desktop interactive protocols such as the use of a memory-
   based clipboard or drag/drop interactions, point-to-point
   asynchronous communication, wired-network transport, or some form of
   unwired transport such as infrared might also be used.

   The memo also provides for the definition of iCalendar object methods
   that will map this content type to a set of messages for supporting
   calendaring and scheduling operations such as requesting, replying

So, in other words, rfc2445 defines a general calendar format that can and 
should be used for moving calendar data across applications systems  
(im-/export, or only drag'n'dropping calendar data, or simply storing 
calendar data).
The second paragraph states that it also provides the definitions for 
scheduling, but the wording implies for me that the rfc is mainly meant to be 
used as a calendar storage format. rfc 2446 talks about how the storage 
format defined in 2445 can be used for scheduling.

The same wording can also be found in your draft. So, in your draft you say 
that ical-Basic is meant as a format to exchange data (not necessarily 
scheduling) between apps or systems (which means it's meant also for example 
to copy your whole calendar to another computer and just use that file there.

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Jan 8 20:41:11 2005

> useless. So ical-extended needs to specify it).

( it has been a long day for me, so pleas double check this!!)

To see this you have to compare instances in UTC and you will
see they always match this:

   end-time-UTC - start-time-UTC always == DURATION.

Assuming they did the RECURRENCE-ID per iTIP and you are given
the DTSTART and DTEND and the TZID parameter is "TZ-X'.

   start_tzoffset for DTEND is (-7 per TZ-X)
   end_tzoffset for DTSTART is (-7 per TZ-X)

   recurrence_id_tzoffset for RECURRENCE-ID is (-6 per TZ-X)
   (because the instance time is across a time zone DST change).

   orignal_end_time_utc = DTEND +  end_tzoffset.

   original_start_time_utc = DTSTART + start_tzoffset.

   recurr_id_start_time_utc = RECURRENCE-ID + recurrence_id_tzoffset.

   Then,

     event_duration = original_end_time_utc - original_start_time_utc

   Now as the RECURRENCE-ID is the start time of the instance, so

   instance_start_time_utc = recur_id_start_time_utc

   instance_end_time_utc = instance_start_time_utc + event_duration.

   If the duration  of the ORIGINAL instance is computed in UTC
   and you use iTIP RECURRENCE-ID values, the above math always
   works and dtend - dtstart == duration even when to the casual
   observer the values to the right of the COLON for DTSTART and
   DTEND do not.

   They always equal!

Now if you do what a couple of vendors do and ALWAYS set the 
RECURRENCE-ID value equal to the DTSTART value (not per iTIP), then
the following math will show they are always equal.

Often they do the math only with the instance and not the original iTIP 
object, so that is how I will do the math.

   start_tzoffset for DTSTART is (-7 per TZ-X)
   (They toss the original DTSTART and replace it with the
   instance start time.)

   end_tzoffset for DTEND is (-6 per TZ-X)
   (They toss the original DTEND and replace it with the
   computed end time of the instance.)

   And recurrence_id_tzoffset for RECURRENCE-ID exactly the same
   as the start_tzoffset (because they always set RECURRENCE-ID
   equal to DTSTART).

   instance_end_time_utc = DTEND +  end_tzoffset.

   instance_start_time_utc = DTSTART + start_tzoffset.

   recurr_id_start_time_utc = instance_start_time_utc
   (Because they always set it to the DTSTART value).

   Then event_duration = instance_end_time_utc - instance_start_time_utc

   So is always true that (because the live above this is the same
   formula.)

     instance_end_time_utc - instance_start_time_utc == event_duration.

A GUI has to do the correct thing and stretch the GUI, show two 2-AM's
or drop 2-AM (or whenever your time zone change). However the data
when compared in UTC always matches.

It appears to fail because:

   instance_DTEND_in_tz_X - instance_DTSTART_in_tz_X  !=  DURATION

   (4am - 1am == 3 hours,  EXCEPT on nights when the time changes)

However the following is always true:

   instance_DTEND_in_utc - instance_DTSTART_in_utc == DURATION

> Ahm, are we talking about a revision of RFC 2445 or only of 2446? 

There is no document, draft, or RFC that I am aware of that talks
about how to exchange non-iTIP (2446) iCalendar objects.

> interopability and data im/export! 

It may be used that way. It is not per spec. That is why some
implementations use the ABNF in 2445 and create objects with
property and parameter values that can not be exchanged without error.
The core specification (2445) specifies many of the permutations of
objects, not how to put them together to exchange calendaring information.

2446 is the 'iCalendar Transport-Independent Interoperability Protocol'.

> (im-/export, or only drag'n'dropping calendar data, or simply storing 

No, 2445 specifies the data format, not the exchange protocol.
If you look you can find many objects that you can create with 2445
that are bogus. It is not meant as a specification for exchanging data
between vendors, that is iTIP's job. Your talking about iTIP PUBLISH
which is the non-scheduling way to transport an object and say 'here it 
is', use it or not.

> format defined in 2445 can be used for scheduling.

There has not been a draft or RFC that talks about storage format.
That was specifically off-topic.

> From your draft: "allows for the capture and exchange of information normally 
> stored within a calendaring and scheduling application; such as a Personal 
> Information Manager (PIM)"), while in your mail you state it's only about 
> scheduling. 

Much of the text comes from 2445. And yes iCal-Basic is meant to find
and fix the holes in the usage. I'll add that one to the list.

> If iCal-Basic is just about scheduling, wouldn't this also run counter to the 
> introduction, where you (and the original rfc) talk about enhancing 
> interopability? 
> 

iCal-Basic is not about scheduling at all.
That will be iTIP-Basic - that where the fun starts.

iCal-Basic is about tossing 2445 core objects in the trash that are
miss used, busted, or never used.

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050108/00ab92b5/smime.bin