Subject: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time

From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud)
Date: Thu Mar 29 02:48:38 2007

The Calsify draft now clarifies in the DTEND definition that:
<<
The value type
   of this property MUST be the same as the "DTSTART" property, and
   the value of this property MUST be later in time than the value of
   the "DTSTART" property.
(See http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001519.html).

Nevertheless the value type just allows us to distinguish between DATE and DATETIME.

Shouldn't we go one step further and say that if the DTSTART value type is FORM #1: DATE WITH LOCAL TIME (See http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-06.html#VALUE.DATE-TIME), DTEND should also be of the same form.
Otherwise, if we allow a mix of floating time + utc time (or time with tz), one can create an event which is valid in some timezones but invalid in some others (you may end up with DTEND < DTSTART).

Arnaud Q

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Mar 29 07:00:30 2007

[ Note to the chairs: This issue is related to issue 65. ]

This is currently specified as a SHOULD in section 6 Recommended
Practices of RFC 2445:

 > 3.  When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
 >     "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
 >     "VTODO" calendar components, have the same value data type (e.g.,
 >     DATE-TIME), they SHOULD specify values in the same time format
 >     (e.g., UTC time format).

I wouldn't mind adding a requirement to specify that if DTSTART is
specified as a "DATE WITH LOCAL TIME" (FORM #1) then DTEND/DUE MUST
also be specified as a "DATE WITH LOCAL TIME" (FORM #1).

That being said, I think we could accept DTSTART and DTEND/DUE to mix
"DATE WITH UTC TIME" (FORM #2) with "DATE WITH LOCAL TIME AND TIME
ZONE REFERENCE" (FORM #3).

Finally, as was already clarified for issue 65, if DTSTART and DTEND/DUE
are both specified as "DATE WITH LOCAL TIME AND TIME ZONE REFERENCE"
(FORM #3) a different time zone MAY be used for each property.

Cheers,
Bernard

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

---

From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud)
Date: Thu Mar 29 08:15:15 2007

> -----Original Message-----
> From: Bernard Desruisseaux [mailto:[email-masked]]
> Sent: Thursday, March 29, 2007 4:59 PM
> To: Arnaud Quillaud
> Cc: [email-masked]
> Subject: Issue 65: Re: [Ietf-calsify] dtstart in tz or utc time and
> dtend in floating time
> 
> 

Yes. I was talking only about the first case.

Thanks,

Arnaud Q
> > (See 
> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-Feb
ruary/001519.html).

---

From: tomasek at etf.cuni.cz (Petr Tomasek)
Date: Thu Mar 29 13:10:01 2007

> Shouldn't we go one step further and say that if the DTSTART value type is FORM #1: DATE WITH LOCAL TIME (See http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc24…

But You would have no way to express events like:
"event X starts on friday xy at 18:00 and ends on sunday xy".

If You force both DTSTART and DTEND to be the same type, then
this event would be transformed into:
"event X starts on friday xy at 18:00 and ends on sunday xy 24:00",
which is not the same!

In other words it seems to me, that there are real
cases of events where either the beginning or the end
can be defined with time granularity while the other
one cannot.

P.T.

-- 
Petr Tomasek <http://www.etf.cuni.cz/~tomasek>

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Mar 29 13:43:23 2007

Am Donnerstag, 29. M?rz 2007 schrieb Petr Tomasek:
> > Shouldn't we go one step further and say that if the DTSTART value type
> > is FORM #1: DATE WITH LOCAL TIME (See
> > http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf
> >-calsify-rfc2445bis-06.html#VALUE.DATE-TIME), DTEND should also be of the
> > same form.
>

Frank Dawson, one of the authors of rfc 2445, says in the following mail that 
it was the intention of rfc 2445 that DTSTART, DTEND, UNTIL, etc. have the 
same value type. It was just not stated clear enough (yeah, that's a 
euphemism for "not at all") in the original RFC:

http://www.imc.org/ietf-calendar/archive1/msg03648.html

See also the summary of the whole discussion on
http://tipi.sourceforge.net/doc/recur/apa.html

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
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.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

---

From: mikesamuel at gmail.com (Mike Samuel)
Date: Thu Mar 29 15:24:09 2007

If I understand the questions, Arnaud is not asking about different
value types, but about start and ends that are both date-times but
where one is in a timezone and one is floating, so:

  DTSTART;TZID=America/Los_Angeles:20060329T161900
  DTEND:20060329T164900

I don't think this introduces problems with start dates after end
dates that you can't already run into when both DTSTART and DTEND have
TZIDs.

mike

On 29/03/07, Reinhold Kainhofer <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGDDK4TqjEwhXvPN0RAjhPAKCkdCt53lYsK5XNAg6aeyO9jt4RAACfZY/E
> wxDHhSQwsTPP3RZOpzBQLDs=
> =IKwK
> -----END PGP SIGNATURE-----

---

From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud)
Date: Thu Mar 29 23:34:15 2007

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of 
> Mike Samuel
> Sent: Friday, March 30, 2007 1:23 AM
> To: Reinhold Kainhofer
> Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in
> floating time
> 
> 

I think it is a different scenario, especially when you start to think in terms of iTIP workflow or CalDAV calendar-query.

When both DTSTART and DTEND have TZIDs, the event (or at least a single instance of an event) can be translated into the same UTC time start/end pair by the Organizer and Invitees without ambiguity. If the event is valid on the Organizer's side (end must be after start), it will be valid for all attendees, wherever they might be in terms of their local timezone.

When the DTSTART has TZID (or UTC) and the DTEND is floating (could be the opposite as well), the event might be absolutely valid on the Organizer side (end must be after start) but it might be invalid on the attendee side. For example, if you (in the US, PST) invite me (in France, CET) with the dates mentioned above, the event is valid from your perspective but invalid for me.

Same for CalDAV calendar-query where you can choose in which timezone you want to represent floating times.

Arnaud Q

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Mar 30 05:45:25 2007

Hi Mike,

> dates that you can't already run into when both DTSTART and DTEND have

That's not true. With TZIDs you can convert the date-times to UTC and 
compare them and make sure that DTEND > DTSTART, irrespective of any other 
properties of the event or user's view of it.

With one of them floating, the actual UTC time of the floating part depends 
on the "observer" - i.e. what display timezone a user has set in their 
client. In that case it is impossible to verify DTEND > DTSTART when the 
times are within ~24 hours of each other due to the possible range of 
timezone shift from one corner of the earth to the other.

Plus users will experience the odd behavior that if they change their 
display timezone, the duration of the event also changes.

I think someone needs to come up with a very real and concrete example of 
why you would want to have one of DTSTART, DTEND floating and the other 
not. Though strictly speaking this issue was closed in the WG so the chairs 
may want to say its too late to change now...

-- 
Cyrus Daboo

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Mar 30 05:50:34 2007

Hi Arnaud,

--On March 30, 2007 9:35:25 AM +0200 Arnaud Quillaud 
<[email-masked]> wrote:

> I think it is a different scenario, especially when you start to think in
> terms of iTIP workflow or CalDAV calendar-query.
>
> When both DTSTART and DTEND have TZIDs, the event (or at least a single
> instance of an event) can be translated into the same UTC time start/end
> pair by the Organizer and Invitees without ambiguity. If the event is
> valid on the Organizer's side (end must be after start), it will be valid
> for all attendees, wherever they might be in terms of their local
> timezone.
>
> When the DTSTART has TZID (or UTC) and the DTEND is floating (could be
> the opposite as well), the event might be absolutely valid on the
> Organizer side (end must be after start) but it might be invalid on the
> attendee side. For example, if you (in the US, PST) invite me (in France,
> CET) with the dates mentioned above, the event is valid from your
> perspective but invalid for me.
>

In respect to iTIP, I am also tempted to say that floating times should not 
be allowed in iTIP at all (even if both DTSTART/DTEND are specified that 
way). Its hard to see why anyone would send out a floating meeting unless 
they could be absolutely 100% sure that all attendees were viewing it in 
the same "display" timezone. If that were not the case then some attendees 
would see it at a different UTC time than others - so they would miss the 
meeting.

-- 
Cyrus Daboo

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Mar 30 06:20:58 2007

Am Freitag, 30. M?rz 2007 schrieb Mike Samuel:
> value types, 

Nope, but Petr was.

> but about start and ends that are both date-times but 

Actually, in Europe/Vienna (CEST) that floating time would be before 16:19 EDT 
and thus invalid with the new text, while in EDT it is after the DTSTART and 
it would be valid... As a consequence the validity of an iCalendar file would 
then depend on the view's timezone!

Cheers,
Reinhold

-- 
------------------------------------------------------------------

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Mar 30 06:52:07 2007

Hi Reinhold,

--On March 30, 2007 4:19:55 PM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

> Actually, in Europe/Vienna (CEST) that floating time would be before
> 16:19 EDT  and thus invalid with the new text, while in EDT it is after
> the DTSTART and  it would be valid... As a consequence the validity of an
> iCalendar file would  then depend on the view's timezone!

Exactly and that would violate my "timezone special relativity principal" 
which states that all meetings should "look" the same no matter what the 
timezone of the observer is. i.e. the event duration should be a constant. 
If one were to violate that then we would have "time dilation effects" 
(inclduing the possible of negative duration where DTEND<DTSTART) and maybe 
I would have to formulate my "timezone general relativity principal"...

:-) with apologies to Albert Einstein.

-- 
Cyrus Daboo

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Mar 30 08:33:47 2007

Am Freitag, 30. M?rz 2007 schrieben Sie:
> Its hard to see why anyone would send out a floating meeting unless

It's not so much about in person-meetings.

I can think of
-) A boss sending out the working hours (or their allowed breaks) to his 
employees. They are relative to the timezone the corresponding person is.
Okay, working hours are negotiated once and don't have to be the same for all 
employess. But imagine the boss sending out the reminder that on Christmas 
eve, all employees are allowed to go home at noon. That can be best expressed 
in floating time.
-) Prayers: a religious teacher or leader sending out prayer hours (e.g. for 
catholic monks at 6, 9, 12, etc. local time, or the prayer times for islamic 
believers).
-) Organizing protests, e.g. at 14:00 local time people all over the world 
meet somewhere to protest against something or to celebrate something.

Actually, all these events are not METHOD:REQUEST, but rather METHOD:PUBLISH 
events.

Cheers,
Reinhold

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend =?iso-8859-1?q?in=09floating=09time?=
Date: Fri, 30 Mar 2007 18:32:40 +0200

Am Freitag, 30. M=E4rz 2007 schrieben Sie:
> Its hard to see why anyone would send out a floating meeting unless

It's not so much about in person-meetings.

I can think of
=2D) A boss sending out the working hours (or their allowed breaks) to his=
=20
employees. They are relative to the timezone the corresponding person is.
Okay, working hours are negotiated once and don't have to be the same for a=
ll=20
employess. But imagine the boss sending out the reminder that on Christmas=
=20
eve, all employees are allowed to go home at noon. That can be best express=
ed=20
in floating time.
=2D) Prayers: a religious teacher or leader sending out prayer hours (e.g. =
for=20
catholic monks at 6, 9, 12, etc. local time, or the prayer times for islami=
c=20
believers).
=2D) Organizing protests, e.g. at 14:00 local time people all over the worl=
d=20
meet somewhere to protest against something or to celebrate something.

Actually, all these events are not METHOD:REQUEST, but rather METHOD:PUBLIS=
H=20
events.

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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Fri, 30 Mar 2007 10:50:45 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating	time

Hi Reinhold,

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
Date: Fri, 30 Mar 2007 16:19:55 +0200

Am Freitag, 30. M=E4rz 2007 schrieb Mike Samuel:
> value types,=20

Nope, but Petr was.

> but about start and ends that are both date-times but=20
>   DTSTART;TZID=3DAmerica/Los_Angeles:20060329T161900
>   DTEND:20060329T164900
>

Actually, in Europe/Vienna (CEST) that floating time would be before 16:19 =
EDT=20
and thus invalid with the new text, while in EDT it is after the DTSTART an=
d=20
it would be valid... As a consequence the validity of an iCalendar file wou=
ld=20
then depend on the view's timezone!

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 maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Fri, 30 Mar 2007 10:04:59 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] iTIP and overridden instances

Hi folks,
Here's a question about iTIP and overridden instances. Example, an 
organizer sends out a weekly recurring meeting to a set of attendees, using 
SEQUENCE:0. At some later point the organizer decides to add another 
attendee to one instance of that meeting only. What does the organizer now 
do in terms of iTIP messaging? Clearly the organizer would send a copy of 
that single overridden instance in an iTIP REQUEST to the new attendee. But 
what should the SEQUENCE be on that? Should the other attendees be notified 
of the change by also sending a new REQUEST to them, and if so what is the 
SEQUENCE number?

I am going to pose some more questions about SEQUENCE number with other 
scheduling scenarios to try and get a better understanding of what people 
believe it is meant to do, so that it can better be defined in the spec.

-- 
Cyrus Daboo

Date: Fri, 30 Mar 2007 09:49:18 -0400
From: Cyrus Daboo <[email-masked]>
To: Arnaud Quillaud <[email-masked]>, [email-masked], Reinhold Kainhofer <[email-masked]>
Subject: RE: [Ietf-calsify] dtstart in tz or utc time and dtend in	floating	time
Cc: [email-masked]

Hi Arnaud,

-- 
Cyrus Daboo

Date: Fri, 30 Mar 2007 09:44:02 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked], Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating	time
Cc: [email-masked]

Hi Mike,

-- 
Cyrus Daboo

Content-return: prohibited
Date: Fri, 30 Mar 2007 09:35:25 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE: [Ietf-calsify] dtstart in tz or utc time and dtend in floating	time
Sender: [email-masked]
To: [email-masked], Reinhold Kainhofer <[email-masked]>
Cc: [email-masked]

> [mailto:[email-masked]]On Behalf Of=20
> Mike Samuel
>=20
>=20
>=20
>   DTSTART;TZID=3DAmerica/Los_Angeles:20060329T161900
>   DTEND:20060329T164900
>=20
> dates that you can't already run into when both DTSTART and DTEND h=
ave
> TZIDs.

I think it is a different scenario, especially when you start to thin=
k in terms of iTIP workflow or CalDAV calendar-query.

When both DTSTART and DTEND have TZIDs, the event (or at least a sing=
le instance of an event) can be translated into the same UTC time sta=
rt/end pair by the Organizer and Invitees without ambiguity. If the e=
vent is valid on the Organizer's side (end must be after start), it w=
ill be valid for all attendees, wherever they might be in terms of th=
eir local timezone.

When the DTSTART has TZID (or UTC) and the DTEND is floating (could b=
e the opposite as well), the event might be absolutely valid on the O=
rganizer side (end must be after start) but it might be invalid on th=
e attendee side. For example, if you (in the US, PST) invite me (in F=
rance, CET) with the dates mentioned above, the event is valid from y=
our perspective but invalid for me.

Same for CalDAV calendar-query where you can choose in which timezone=
 you want to represent floating times.

Arnaud Q

>=20
>=20
>=20
>=20
> > Am Donnerstag, 29. M=E4rz 2007 schrieb Petr Tomasek:
> > > > Shouldn't we go one step further and say that if the=20
> DTSTART value type
> > > >=20
> > > >-calsify-rfc2445bis-06.html#VALUE.DATE-TIME), DTEND=20
> should also be of the
> > > > same form.
> > >
> > > "event X starts on friday xy at 18:00 and ends on sunday=20
> xy 24:00",
> > > which is not the same!
> >
> > Frank Dawson, one of the authors of rfc 2445, says in the=20
> following mail that
> > it was the intention of rfc 2445 that DTSTART, DTEND,=20
> UNTIL, etc. have the
> > same value type. It was just not stated clear enough (yeah, that'=
s a
> > - ---------------------------------------------------------------=
---
> >  * Financial and Actuarial Mathematics, TU Wien,=20
http://www.fam.tuwien.ac.at/
> wxDHhSQwsTPP3RZOpzBQLDs=3D
> =3DIKwK

Date: Thu, 29 Mar 2007 16:23:01 -0700
From: "Mike Samuel" <[email-masked]>
To: "Reinhold Kainhofer" <[email-masked]>
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
Cc: [email-masked]
Reply-To: [email-masked]

  DTSTART;TZID=3DAmerica/Los_Angeles:20060329T161900
  DTEND:20060329T164900

mike

On 29/03/07, Reinhold Kainhofer <[email-masked]> wrote:
> Am Donnerstag, 29. M=E4rz 2007 schrieb Petr Tomasek:
> > > Shouldn't we go one step further and say that if the DTSTART value ty=
pe
> > > http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-=
ietf
> > >-calsify-rfc2445bis-06.html#VALUE.DATE-TIME), DTEND should also be of =
the
> Frank Dawson, one of the authors of rfc 2445, says in the following mail =
that
> it was the intention of rfc 2445 that DTSTART, DTEND, UNTIL, etc. have th=
e
>  * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac=
.at/
> wxDHhSQwsTPP3RZOpzBQLDs=3D
> =3DIKwK

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
Date: Thu, 29 Mar 2007 23:42:14 +0200

Cheers,
Reinhold

- -- 

Date: Thu, 29 Mar 2007 23:10:36 +0200
From: Petr Tomasek <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time

P.T.

Content-return: prohibited
Date: Thu, 29 Mar 2007 18:16:27 +0200
From: Arnaud Quillaud <[email-masked]>
Subject: RE: Issue 65: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
Sender: [email-masked]
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

Thanks,

Arnaud Q
ruary/001519.html).
> Otherwise, if we allow a mix of floating time + utc time (or time with tz), one can create an event which is valid in some timezones but invalid in some others (you may end up with DTEND < DTSTART).

Date: Thu, 29 Mar 2007 10:58:53 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Subject: Issue 65: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
Cc: [email-masked]

Cheers,
Bernard

> Otherwise, if we allow a mix of floating time + utc time (or time with tz), one can create an event which is valid in some timezones but invalid in some others (you may end up with DTEND < DTSTART).

Content-return: prohibited
Date: Thu, 29 Mar 2007 12:49:42 +0200
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time

Arnaud Q

Date: Tue, 27 Mar 2007 14:24:55 -0700
From: "Mike Samuel" <[email-masked]>
To: "Bill Kearney" <[email-masked]>
Subject: Re: [Ietf-calsify] definitive references for UTC
Cc: [email-masked]
Reply-To: [email-masked]

Most existing date libraries ignore leap seconds, so it's unlikely
that systems built on these will handle them.

I don't think that 2445 uses a <units-since-epoch> representation of
dates, so the only place where UTC enters the picture is in durations
-- subtracting dates, and adding durations to dates.  One alternative
to specifying a different interpretation of UTC, would be to mandate
that PT60S == PT1M.

Here's a quick survey of leap second support in common platforms/libraries:

http://www.mail-archive.com/[email-masked]/msg00109.html
    Distributing leap second tables and requiring hosts to be "on-line"
    to receive them in those days (when UUCP over slow baud modems was
    common) was not considered realistic.  It was felt expect vendors
    and/or system administrators to maintain a complete leap second table
    (including leap seconds announced in advance) was also considered
    unrealistic.

    The POSIX decision was to preserve existing practice.  That the
    vast majority of time-stamp calculation methods ignored leap seconds .
    The decision was to to continue to use a trivial seconds since the
    Epoch" calculation that ignored leap seconds.

http://joda-time.sourceforge.net/faq.html#leapseconds
    Joda-Time does not support leap seconds. Leap seconds can be supported by
    writing a new, specialized chronology, ...

http://docs.python.org/lib/datetime-date.html
    Note that on non-POSIX systems that include leap seconds in their
notion of a
    timestamp, leap seconds are ignored by fromtimestamp().

Similarly java.util.Date only supports leap seconds if the underlying
hardware does.

cheers,
mike

On 26/03/07, Bill Kearney <[email-masked]> wrote:
>
> > Although it's tempting to make one
> > protocol shoe fit multiple application feet, the result is rarely
> > satsifactory and usually is a wretched compromise that serves nobody.
>
> +1

Date: Tue, 27 Mar 2007 10:46:46 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] TZID property/parameter value inconsistency

Hi,
I've noted an inconsistency between the TZID property and parameter value 
definitions. In 2445bis we current have:

property:

    tzid       = "TZID" tzidpropparam ":" [tzidprefix] text CRLF

parameter:

    tzidparam  = "TZID" "=" [tzidprefix] paramtext

Note that "paramtext" is defined this way:

    paramtext     = *SAFE-CHAR

    SAFE-CHAR     = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
                    / NON-US-ASCII
      ; Any character except CONTROL, DQUOTE, ";", ":", ","

Thus, as currently defined, a TZID parameter cannot be quoted and cannot 
contain ";", ":" and ",". But the property value is defined as just "text" 
which of course can contain any of those characters.

I believe the proper behaviour here is to have the TZID parameter defined 
as:

    tzidparam  = "TZID" "=" tzidparamvalue

    tzidparamvalue = tzidparamtext / tzidquoted-string

    tzidparamtext = [tzidprefix] paramtext

    tzidquoted-string = DQUOTE [tzidprefix] *QSAFE-CHAR DQUOTE

This is obviously complicated by trying to indicate that the tzidprefix 
character can appear at the start of the tzid name.

One option to simplfy would be to do away with the format tzidprefix item, 
and instead just add notes in the syntax that a name starting with a "/" is 
treated as being special (with appropriate text for that). If we did that, 
the parameter syntax would simply be:

    tzidparam  = "TZID" "=" paramvalue

BTW I have seen TZID parameter values that are quoted in real iCal data.

-- 
Cyrus Daboo

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 40b8e56bf9c0286b87c12b483ae58acd
X-Spam-Score-Summary: 50, 0, 0, bc4cdb841249fc5f, afc90f00e596c9e6, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:601:945:960:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2525:2551:2560:2563:2682:2685:2828:2857:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3353:3657:3865:3866:3867:3868:3869:3870:3871:3872:3874:3934:3936:3938:3941:4250:4605:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Subject: [Ietf-calsify] BYDAY integers with other BY* rules (was: BYSETPOS and contracting BY* rules)
Date: Mon, 26 Mar 2007 19:20:51 +0100

> I've always agreed with your second interpretation of RFC 2445: the 
> numbers
> in the BYDAY rule refer to the period of time described by the FREQ. 
> "-1FR"
> means the last Friday of the month in a MONTHLY rule, and the last Friday 
> of
> the year in a YEARLY rule.

<snip>

> Unfortunately, this interpretation is directly contradicted by RFC 2445's
> VTIMEZONE example, which describes US-Eastern DST transitions as
>
>         RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
>
> I've always interpreted this VTIMEZONE example as a bug in the spec, but I
> see how it can make sense if BYDAY integers are interpreted as being like
> BYSETPOS.

Recommendations detailed in 
http://www.calconnect.org/publications/icalendarrecurrenceproblemsandrecommendationsv1.0.pdf 
in appendix A say that FREQ Yearly with BYDAY means read note 3.  Note 3 
says:

 Limit if BYYEARDAY or BYMONTHDAY is present,
 otherwise special expand for WEEKLY if BYWEEKNO present,
 otherwise special expand for MONTHLY if BYMONTH present,
 otherwise special expand for YEARLY.

 A BYDAY rule part cannot have a numeric value in a
 FREQ=YEARLY rule (i.e. 'MO', 'TU' etc is allowed, but
 '1MO', '2TU' is not allowed), if BYWEEKNO is specified.

 The numeric value in a BYDAY rule part in a FREQ=YEARLY
 rule with a BYMONTH present corresponds to an offset with
 the month.

 The numeric value in a BYDAY rule part in a FREQ=YEARLY
 rule without BYWEEKNO or BYMONTH

So BYMONTH present means special expand for MONTHLY, and special expand for 
MONTHLY means  "The numeric value in a BYDAY rule part in a FREQ=YEARLY rule 
with a BYMONTH present corresponds to an offset with the month".  Thus that 
makes the example not nice, but not buggy either?

Are we wanting to abandon those recommentations?  The very fact that BYDAY 
needed three special notes, the only special notes in the whole table make 
me wonder if somethings wrong :o/

Nigel 

From: "Bill Kearney" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [Ietf-calsify] definitive references for UTC
Date: Mon, 26 Mar 2007 09:50:59 -0700

> Although it's tempting to make one 
> protocol shoe fit multiple application feet, the result is rarely 
> satsifactory and usually is a wretched compromise that serves nobody.

+1

Date: Mon, 26 Mar 2007 13:06:07 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] 2445bis Abstract

Hi,
I really don't like the current abstract - in particular its use of "MIME 
media type". The current abstract is:

>    This document defines a MIME media type for representing and
>    exchanging calendaring and scheduling information such as events, to-
>    dos, journal entries and free/busy information.  The definition of
>    the text/calendar media type, known as iCalendar, is independent of
>    any particular calendar service or protocol.

MIME RFC2045 states this:

> 5.  Content-Type Header Field
>
>    The purpose of the Content-Type field is to describe the data
>    contained in the body fully enough that the receiving user agent can
>    pick an appropriate agent or mechanism to present the data to the
>    user, or otherwise deal with the data in an appropriate manner. The
>    value in this field is called a media type.

i.e. the term "media type" refers to the value of a Content-Type header, 
not to the actual data that uses that content type. 2445 is primarily 
defining the data format not the MIME type/subtype value (even though it 
does define text/calendar).

I would prefer something like the following:

   This document defines the iCalendar data format for representing and
   exchanging calendaring and scheduling information such as events, to-
   dos, journal entries and free/busy information, independent of any
   particular calendar service or protocol.

-- 
Cyrus Daboo

Date: Mon, 26 Mar 2007 09:31:18 -0700 (PDT)
From: Mark Crispin <[email-masked]>
Sender: [email-masked]
To: Jonathan Lennox <[email-masked]>
Subject: Re: [Ietf-calsify] definitive references for UTC
Cc: [email-masked]

On Mon, 26 Mar 2007, Jonathan Lennox wrote:
> At the Prague meeting, there was consensus that iCalendar should ignore
> leapseconds, i.e. act in all respects as if they didn't exist.  I still
> think this is both least-surprise for users, and the mode that's almost
> certainly implemented by 100% of current iCalendar implementations.

That sounds right to me.  For most people, leap seconds are nothing more 
than a form of clock drift correction, and we can (should!) stay out of 
The Great Leap Second Debate.

[Summary of TGLSD: which is more important, keeping time matching the 
earth's rotation, or having a clock which is predictable in the future? 
Personally, I feel that the people who desire the latter would be better 
served by a monotonically incrementing value (a 72 bit nanosecond value 
will last over 500 years!); and those of us who think in terms of yyyy mm 
dd hh mm ss should stay synchronized with the planet since "years", 
"months", and "days" are fundamentally planetary concepts.  But there are 
many reasonable and educated people who feel otherwise.]

> The defining characteristic of UTC, however (as opposed to the other
> flavors of Universal Time, or to TAI), is the fact that it has leap
> seconds.

Too bad we can't say "just use TAI".  ;-)

> Getting this right will require some somewhat tricky wordsmithing in the
> document.

True.  My suggestion is something to the effect that the basic time is 
UTC.  To the extent that any implementation handles leap seconds, they are 
to be treated as a clock drift correction, e.g., 23:59:59 lasts for two 
seconds rather than there being a 23:59:60.

For the purposes of calendaring, an interval lasting for an extra second 
than intended is probably alright, since that is how humans respond to 
leap seconds.  We're not doing precision timekeeping; we're trying to 
synchronize human activities.

I think that we should resist any attempt to make calendaring be a 
precision timekeeping mechanism, since those people have fundamentally 
different needs than calendaring.  Although it's tempting to make one 
protocol shoe fit multiple application feet, the result is rarely 
satsifactory and usually is a wretched compromise that serves nobody.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Mon, 26 Mar 2007 10:35:05 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Minor issues in 2445bis

Hi,
Some issues with -06 draft:

1) It would be nice if the VTIMEZONE example on page 63/64 had its 
sub-components ordered by DTSTART so as to match the table on page 61 for 
ease of understanding. If we do that, the example text description should 
include a statement to the effect that the actual ordering of 
STANDARD/DAYLIGHT sub-components is arbitrary.

2) The description for the example at the top of page 66 is wrong. The "on 
or later than" time is wrong - it uses 2007 - but the VTIMEZONE is 
1997/1998.

3) In the "fictitious" examples starting at the bottom of page 66 until 
page 68, they are described as being "for the Eastern United States". I 
would rather prefer " for a locality with a standard time offset of -0500".

4) The example text description at the bottom of page 66 should indicate it 
is "fictitious".

5) There is an extraneous space before the period at the end of the 
paragraph immediately after the list on page 64. There were a couple of 
other like that in the document - do a search for " .", and also " ," and " 
:" while you are at it.

-- 
Cyrus Daboo

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 7ecd5687cd2c089efe864b67832613d4
X-Spam-Score-Summary: 2, 0, 0, 623485aa5792b0c3, 72151a5f3763fbbc, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1541:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2525:2553:2559:2563:2682:2685:2693:2731:2828:2857:2859:2890:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3353:3865:3866:3867:3868:3869:3870:3871:3872:3874:3934:3936:3938:3941:4042:4250:4699:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Jonathan Lennox" <[email-masked]>
Subject: Re: [Ietf-calsify] definitive references for UTC
Date: Mon, 26 Mar 2007 15:35:26 +0100
Cc: [email-masked]

> I'm fine with adding the reference, but it comes with a caveat.
>=20
> At the Prague meeting, there was consensus that iCalendar should =
ignore
> leapseconds, i.e. act in all respects as if they didn't exist.  I =
still
> think this is both least-surprise for users, and the mode that's =
almost
> certainly implemented by 100% of current iCalendar implementations.
>=20
> The defining characteristic of UTC, however (as opposed to the other
> flavors of Universal Time, or to TAI), is the fact that it has leap
> seconds.
>=20
> Getting this right will require some somewhat tricky wordsmithing in =
the
> document.

In case anyone doesn't know what I researched recently:
http://www.meinberg.de/english/info/leap-second.htm

"The Windows system clock does not know about leap seconds, either. =
However, there is a precompiled version of ntpd for Windows available =
which is capable of slewing the Windows system time quickly in order to =
account for the insertion of a leap second, without affecting the clock =
synchronization loop provided by ntpd. "

So in the end I had little choice but to ignore leap seconds as the OS =
didn't make me aware of them, and without the patch didn't even know =
about them.

Perhaps an option would be to change the phrasing to describe that =
support for leap seconds is dependant on support from the clock =
subsystem and therefore the system may never report their existance.  =
Then go on to describe how to cope with iCalendar data when your OS =
doesn't report the leap second.

Equally I'm totally happy with iCalendar ignoring leap seconds too.

Nigel

Date: Mon, 26 Mar 2007 16:12:37 +0200
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Draft minutes from IETF68 available

Hi,

We've posted the minutes here:

http://www3.ietf.org/proceedings/07mar/minutes/calsify.txt

If you have comments, please send a note to the chairs.

Cheers,
Aki

From: Jonathan Lennox <[email-masked]>
Date: Mon, 26 Mar 2007 10:05:51 -0400
To: [email-masked]
Subject: Re: [Ietf-calsify] definitive references for UTC

On Friday, March 23 2007, "Steve Allen" wrote to "[email-masked]" saying:

> I find it somewhat strange that the term "UTC" is used throughout
>    draft-ietf-calsify-rfc2445bis-06.txt
> without being defined anywhere in the document.
> 
> I can't suggest exactly where it would best fit in the rfc,
> but a minimal text which defines what UTC is and why it is
> used internationally would be something like this:
> 
> 	Coordinated Universal Time (UTC) is defined by ITU-R TF.460.
> 	Under the auspices of the Metre Convention of 1865, in 1975
> 	the CGPM strongly endorsed the use of UTC as the basis for
> 	civil time.

I'm fine with adding the reference, but it comes with a caveat.

At the Prague meeting, there was consensus that iCalendar should ignore
leapseconds, i.e. act in all respects as if they didn't exist.  I still
think this is both least-surprise for users, and the mode that's almost
certainly implemented by 100% of current iCalendar implementations.

The defining characteristic of UTC, however (as opposed to the other
flavors of Universal Time, or to TAI), is the fact that it has leap
seconds.

Getting this right will require some somewhat tricky wordsmithing in the
document.

-- 
Jonathan Lennox
[email-masked]

Date: Mon, 26 Mar 2007 15:06:34 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Calsify next steps

Dear all,

We had a very productive meeting in Prague.  The chairs would like to 
thank those who participated and assisted in the meeting's success.  
While we will post the official minutes soon, those who were not present 
can review the jabber log at 
http://www3.ietf.org/meetings/ietf-logs/calsify/2007-03-19.html.  The 
chairs have requested an update on the milestones to more reflect 
reality.  That update should come through this week.

In the meantime, there are two new old issues in the tracker.  Please 
see Issues 81 and 82 for details around BYSETPOS and a proposal for a 
more straightforward reading of BYDAY.  Thanks to Jonathan Lennox for 
pointing out these discrepencies.

Also, we have begun work on RFC2446bis.  NOW is the time to consider 
issues you may wish to raise with the document.  We are aware of, and 
will open issues in the tracker for, several issues around ADD and 
CANCEL methods.  These were discussed in brief by Cyrus, who remotely 
presented to us via a Mac and Ted Hardy ;-)   They involve recurring 
events.  Please take the time now to find open issues to this document.  
We will in the coming weeks enter last call for new issues.

Finally, we will resume jabber sessions to resolve remaining issues.  
However, before we do so, we will hold a teleconference to discuss open 
issues.  A date has not been set but we would like it to occur within 
two weeks.  Please feel free to email me with your availability, as we 
probably do not have access to your CALDAV server ;-)

Warmest regards,

Aki Niemi
Eliot Lear
The Chairs

Date: Mon, 26 Mar 2007 10:08:36 +0200
From: Eliot Lear <[email-masked]>
To: Petr Tomasek <[email-masked]>
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?
Cc: [email-masked]

Petr Tomasek wrote:
>> However, if you believe there is a need 
>> for such a calendar, perhaps it would be worth investigating an 
>> experimental version.
>>     
>
> Do You mean investigating how would the change affect existing
> implementations?
>   

While I personally don't believe that the iCalendar standard will serve 
you well for your purposes, I see nothing wrong with attempting to 
develop either a new timescale or other changes in an experimental way.  
Mark Crispin is correct that there is some difficulty going backwards in 
time with regard to calendaring (past 1970 causes problems).  Those 
problems will be non-trivial.  For adoption as a standard you would 
clearly need to address concerns about existing implementations, and 
those too would likely be non-trivial.

Date: Mon, 26 Mar 2007 07:58:22 +0200
From: Petr Tomasek <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?

On Sun, Mar 25, 2007 at 07:21:48PM +0200, Eliot Lear wrote:
> ...
>
> 9990).  I am concerned that making a change to the date format would 
> cause massive interoperability problems, requiring a version bump, which 
> itself would cause problems.

Well, I didn't want to say, You must change the standard immediately ;).

I'm just trying to find a solution that could be adopted in
some future (major?) version of the standard.

Beside, bounding the date/time format to the CALSCALE
property would seem to me the right way that would IMHO not
cause compatibility probles and would make the standard
more clean/extensible for the future.

> However, if you believe there is a need 
> for such a calendar, perhaps it would be worth investigating an 
> experimental version.

Do You mean investigating how would the change affect existing
implementations?

> And so on a related topic, I believe we should make it clear to 
> implementors that they ignore VERSION at their peril.
> 
> Warmest regards,
> 
> Eliot

Best regards,
Petr Tomasek

Date: Mon, 26 Mar 2007 07:44:16 +0200
From: Petr Tomasek <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?

On Sun, Mar 25, 2007 at 10:22:08AM -0400, Paul B. Hill wrote:
> Please see section 4.7.1. of RFC 2445:
> 
> ---------------------------------
> 4.7.1 Calendar Scale
> 
>    Property Name: CALSCALE
> 
>    Purpose: This property defines the calendar scale used for the
>    calendar information specified in the iCalendar object.
> 
>    Value Type: TEXT
> 
> .... 
>      CALSCALE:GREGORIAN
> ---------------------

Thank you for pointing that out! It seems to me, that the misconception
of iCalendar is in that it makes possible to use 'CALSCALE', but
the definition of date/date-time format is not bound to the 'CALSCALE'
property.

Consider e.g. if one would use "CALSCALE:JEWISH" in specialized
application (it wouldn't be understood by other apps anyway),
but wouldn't be able to use it in compliance with the RFC,
because the jewish calendar can have 13 months which is not allowed.

So I would propose (for a future version) of iCalendar to:

 a) define what characters date/time can use in general (so that
parsers can validate the document). I would suggest something
like this (in regexp syntax): "[0-9A-Z.+-]+".

 b) state that the date/time format depends on the CALSCALE property
and define it for "CALSCALE:GREGORIAN" exactly like it is defined
today (so it won't break anything for iCalendar files that use
"CALSCALE:GREGORIAN").

 c) perhaps define some other date/time formats (in terms of "client
MAY implement") for "CALSCALE:JULIAN" and "CALSCALE:ASTRONOMIC" (I would
suggest to use here the so-called "Julian date number") where exact
algorithms for converting to/from "CALSCALE:GREGORIAN" would be described.

One may also define something like "CALSCALE:REAL_JULIAN" for dates
before 12 AD where the exact correlation between the julian calendar
and the "astronomic date" is unsure[*].

> However, I am not aware of any implementations of an iCalendar based 
> system that implements a non-gregorian CALSCALE. I assume that this is 
> because there is no market demand.

But anyway, it would be nice, if the iCalendar allowed for iCalendar
with CALSCALE other than GREGORIAN to be used correctly.

Petr Tomasek

[*] See http://en.wikipedia.org/wiki/Julian_calendar#Leap_year_error

Date: Mon, 26 Mar 2007 07:04:04 +0200
From: Petr Tomasek <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?

On Sun, Mar 25, 2007 at 11:17:49AM -0700, Mark Crispin wrote:
> Leaving aside the small matter that there was no year 0, BCE predates the 
> current calendar by several centuries.  Due to the complexity of the 
> conversions between contemporary calendars and the modern calendar, any 
> reported dates in that timeline need to be taken with a grain of salt.

I agree, but there may be need to actualy represent such dates in
iCalendar even if their exact distance from today's date may
not be accurate/sure (I mentioned the idea of some sort of timeline application
that could use iCalendar for storing historical events).

> Long before we get to Y10K, matters will come up that will necessitate the 
> modification of the modern calendar.  At around Y3.3K, the modern calendar 

Well, I was thinking more of "Y10K BCE", than about the future ;-).

> 
> The bottom line is that any attempt to represent BCE or far future dates 
> in a calendaring system based upon our current calendar is doomed to 
> failure.

I disagree. Historicians do represent BCE dates in their publications
quite often. 

Date: Sun, 25 Mar 2007 11:17:49 -0700
From: Mark Crispin <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?
Organization: Networks & Distributed Computing
Sender: [email-masked]
Cc: [email-masked]

Leaving aside the small matter that there was no year 0, BCE predates the 
current calendar by several centuries.  Due to the complexity of the 
conversions between contemporary calendars and the modern calendar, any 
reported dates in that timeline need to be taken with a grain of salt.

Long before we get to Y10K, matters will come up that will necessitate the 
modification of the modern calendar.  At around Y3.3K, the modern calendar 
goes slow by a day.  Current thinking is to make Y4K and other years 
evenly divisible by 4000 not be leap years; however this will only patch 
things up until about Y20K.

The Eastern Orthodox church has its own modifications to the modern 
calendar; in their calendar, century years module 900 must result in a 
value of 200 or 600 to be considered leap years.  This makes a difference 
starting in 2800, where the two diverge until 2900; and again between 3200 
and 3300; and then at increasing intervals.  Although more accurate, the 
Eastern Orthodox calendar falls apart at about Y43K.

On top of that, there are perturbances in the Earth's rotation and orbit 
that none of these systems handle, including some that we don't know about 
yet.

Last but not least, there is quite a debate between those who advocate the 
UTC continue in the spirit of the old GMT (adjust the time with leap 
seconds as needed so that 12:00:00 UTC represents noon at 0 degrees 
longitude); and those who want a timebase that follows makes it easy to do 
arithmetic between times.  Most people ignore leap seconds entirely, a 
rational position given that their clocks have much greater drift than a 
leap second.  That is not an option for people in the precise timing 
community.

If you want to read more, look at:
 	http://staff.washington.edu/mrc/calendar.html

The bottom line is that any attempt to represent BCE or far future dates 
in a calendaring system based upon our current calendar is doomed to 
failure.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Sun, 25 Mar 2007 19:24:01 +0200
From: Eliot Lear <[email-masked]>
To: Steve Allen <[email-masked]>
Subject: Re: [Ietf-calsify] definitive references for UTC
Cc: "[email-masked]" <[email-masked]>

<chair hat off>

Steve,

> I find it somewhat strange that the term "UTC" is used throughout
>    draft-ietf-calsify-rfc2445bis-06.txt
> without being defined anywhere in the document.
>
> I can't suggest exactly where it would best fit in the rfc,
> but a minimal text which defines what UTC is and why it is
> used internationally would be something like this:
>
> 	Coordinated Universal Time (UTC) is defined by ITU-R TF.460.
> 	Under the auspices of the Metre Convention of 1865, in 1975
> 	the CGPM strongly endorsed the use of UTC as the basis for
> 	civil time.
>
> This implies adding these to the section of Informative References
>
> International Telecommunications Union,
> "Standard-frequency and time-signal emissions",
> ITU-R TF.460,
> http://www.itu.int/rec/R-REC-TF.460/en
>
> General Conference on Weights and Measures,
> Resolution 5 of the 15th CGPM,
> Comptes Rendus de la 15e CGPM, 1976
> http://www1.bipm.org/jsp/en/ViewCGPMResolution.jsp?CGPM=15&RES=5
>
>   

+1.

Thanks for pointing this out.

Eliot

Date: Sun, 25 Mar 2007 19:21:48 +0200
From: Eliot Lear <[email-masked]>
To: Petr Tomasek <[email-masked]>
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?
Cc: [email-masked]

<chair hat off>

Petr,

Thanks for your email.  To your first point about BCE, while I 
understand the desire to develop perhaps calendars of timelines, I am 
afraid that it is difficult enough to get calendaring to interoperate 
for events in this year, no less this century.  Regarding dates greater 
than 9999, if man survives that long I would hope that someone could 
revise the standard, some years prior to that time (like maybe in 
9990).  I am concerned that making a change to the date format would 
cause massive interoperability problems, requiring a version bump, which 
itself would cause problems.  However, if you believe there is a need 
for such a calendar, perhaps it would be worth investigating an 
experimental version.

And so on a related topic, I believe we should make it clear to 
implementors that they ignore VERSION at their peril.

Warmest regards,

Eliot

Date: Sun, 25 Mar 2007 15:30:03 +0200
From: Petr Tomasek <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?

Hello!

(I hope this is the right mailinglist and my quostion
isn't disturbing here anyone.  Also, I'm not english
native-speaker, so, please, sorry for my formulations).

I'd like to ask, why doesn't the iCalendar allow
for dates B.C.E and/or where abs(Year)>9999?

As far as I understand (according to the latest draft)
the year (in DTSTART and DTEND) must in 4-digits
format although the ISO 8601 would allow for extended
representation (ISO 8601:2004, 4.1.2.4).

For the iCalendar, being general format for calendar information it
would make sense to use it e.g. for informations about
historical events (consider for example a timeline application
that would be able to download sources from various webpages,
just like today's calendar apps do with "webcal" calendars...)

So my quoestion is: wouldn't it be possible to extend (in some
future version of the standard) the format of iCalendar to
support?

Thanks!
Petr Tomasek

Date: Fri, 23 Mar 2007 22:16:49 -0700
From: Steve Allen <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] definitive references for UTC

I find it somewhat strange that the term "UTC" is used throughout
   draft-ietf-calsify-rfc2445bis-06.txt
without being defined anywhere in the document.

I can't suggest exactly where it would best fit in the rfc,
but a minimal text which defines what UTC is and why it is
used internationally would be something like this:

	Coordinated Universal Time (UTC) is defined by ITU-R TF.460.
	Under the auspices of the Metre Convention of 1865, in 1975
	the CGPM strongly endorsed the use of UTC as the basis for
	civil time.

This implies adding these to the section of Informative References

International Telecommunications Union,
"Standard-frequency and time-signal emissions",
ITU-R TF.460,
http://www.itu.int/rec/R-REC-TF.460/en

General Conference on Weights and Measures,
Resolution 5 of the 15th CGPM,
Comptes Rendus de la 15e CGPM, 1976
http://www1.bipm.org/jsp/en/ViewCGPMResolution.jsp?CGPM=15&RES=5

--
Steve Allen                 <[email-masked]>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99845
University of California    Voice: +1 831 459 3046           Lng -122.06025
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

Date: Wed, 21 Mar 2007 22:13:09 -0400
From: Cyrus Daboo <[email-masked]>
To: Nigel Swinson <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Interpretation of the UNTIL part of RRULEs in	Timezones

Hi Nigel,

--On March 21, 2007 5:28:51 PM +0000 Nigel Swinson 
<[email-masked]> wrote:

> BEGIN:DAYLIGHT
> DTSTART:19180331T020000
> RRULE:FREQ=YEARLY;UNTIL=19190330T060000Z;BYDAY=-1SU;BYMONTH=3
> TZNAME:EDT
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> END:DAYLIGHT
>
> First instance is
> 19180331T020000 = 19180331T070000Z
> Last instance is
> 19190330T010000 = 19190330T060000Z
>
> And therefore according to the standard, the TZ decl is wrong as
> 19190330T010000 is not in the recurrence set and is therefore not the
> last instance generated by the recurrence pattern.  Unless of course
> UNTIL is meant to convert to UTC using OFFSETTO in which case it would be
> T020000 and the decl is right.  Were that to be the case I'd sure like to
> see it clarified in the standard.

It seems at first glance the DAYLIGHT component is not valid as UNTIL is 
not the last instance. i.e. the tool doing the conversion got it wrong.

-- 
Cyrus Daboo

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 12ae79e199a05b7c75429e25638c5d00
X-Spam-Score-Summary: 2, 0, 0, 046a475d25d27149, 77946e9d9e053620, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:945:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1543:1587:1593:1594:1605:1711:1730:1747:1766:1792:2073:2075:2078:2194:2198:2199:2200:2393:2525:2559:2565:2570:2682:2685:2693:2703:2741:2828:2857:2859:2909:2933:2937:2939:2942:2945:2947:2951:2954:3022:3636:3770:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:4250:4321:4605:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Date: Wed, 21 Mar 2007 17:28:51 -0000
Subject: [Ietf-calsify] Interpretation of the UNTIL part of RRULEs in Timezones

I'm hoping you can confirm my understanding of the timezone RRULE 
processing:

DTStart has to be interpreted as local time:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.6.5
      The mandatory "DTSTART" property gives the effective onset date
      and local time for the time zone sub-component definition.
      "DTSTART" in this usage MUST be specified as a local DATE-TIME
      value.

Until has to be interpreted as Utc:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.3.10

      value type as the "DTSTART" property.  If specified as a DATE-TIME
      value, then it MUST be specified in a UTC time format.  If not
      present, and the COUNT rule part is also not present, the "RRULE"
      is considered to repeat forever.

And restated and refined further for timezones:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.6.5

      *  If observance is known to have an effective end date, the
         "UNTIL" recurrence rule parameter MUST be used to specify the
         last valid onset of this observance (i.e., the UNTIL date-time
         will be equal to the last instance generated by the recurrence
         pattern).  It MUST be specified in UTC time.

Should RRULE have ByHour components, then I can only assume these follow 
DTSTART and therefore apply to local time, not UTC.  So this means to expand 
the recurring rule, we have to essentially use "floating time", as we can't 
really use localtime as that's what we are in the process of defining.  ie 
we use a fixed UTC offset (TZOFFSETFROM) to go from UTC to local time for 
the purposes of the expansion.

The first instance comes from DTSTART, yet the upper bound is in UTC which 
means presumably that we have to adjust the UNTIL date also using 
TZOFFSETFROM so that it is also in the same timesystem as our recurrence 
instances so that we can compare them.

So for example, consider this relatively arbitrary daylightc derived by an 
online tool (tziCal) from olson

BEGIN:DAYLIGHT
DTSTART:19180331T020000
RRULE:FREQ=YEARLY;UNTIL=19190330T060000Z;BYDAY=-1SU;BYMONTH=3
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
END:DAYLIGHT

First instance is
19180331T020000 = 19180331T070000Z
Last instance is
19190330T010000 = 19190330T060000Z

And therefore according to the standard, the TZ decl is wrong as 
19190330T010000 is not in the recurrence set and is therefore not the last 
instance generated by the recurrence pattern.  Unless of course UNTIL is 
meant to convert to UTC using OFFSETTO in which case it would be T020000 and 
the decl is right.  Were that to be the case I'd sure like to see it 
clarified in the standard.

This certainly seems overly complex with a lot of unnecessary switching 
between UTC and mysterious floating times.  I also find the below comment 
decidedly unhelpful.  Why can't it say how we are meant to use TZOFFSETFROM 
rather than just that we should?  I'd suggest alternative language, but I 
would first want to be sufficiently sure that I am understanding this 
correctly, and that I am not yet again discussing issues that aren't on the 
"blessed" list.

      *  The "DTSTART" and the "TZOFFSETFROM" properties MUST be used
         when generating the onset date-time values (instances) from the
         "RRULE".

I'd also like to remind you of my suggestions WRT to RRules in timezones. 
These would mean expanding RRules for timezones dont care about times only 
dates and much of these grey areas dissapear:
- Limit to yearly
- prohibit byhour, byminute, bysecond,

I would like to add to the list that for RRules we put DTStart and Until in 
the same timesytem, ie both in UTC or both in localtime.  In fact if UNTIL 
specified a DATE rather than a DATE-TIME that would be even clearer and less 
to process.

Nigel 

From: Jonathan Lennox <[email-masked]>
Date: Mon, 19 Mar 2007 11:18:05 -0400
To: Eliot Lear <[email-masked]>
Cc: [email-masked]
Subject: [Ietf-calsify] Overlooked issues for the tracker

Eliot -- as requested, here are the open issues that I don't think made it
to the issues list.  Actually there were two of them.  (Both of them were
right at the deadline, I think, during/after the November meeting.)

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001383.html
(What's the scope of BYSETPOS in the presence of contrating BY* rules?)

http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001386.html
(What's the defintion of BYDAY integers in the presence of other BY* rules?)

-jonathan

Content-return: prohibited
Date: Sat, 17 Mar 2007 13:48:56 +0100
From: Arnaud Quillaud <[email-masked]>
Subject: RE : RE : [Ietf-calsify] rfc 2446 - Cancel and sequence number
Sender: [email-masked]
To: Eliot Lear <[email-masked]>
Cc: [email-masked]

> -----Message d'origine-----
> De : Eliot Lear [mailto:[email-masked]]=20
> Envoy=E9 : samedi 17 mars 2007 13:22
> =C0 : Arnaud Quillaud
> Cc : Cyrus Daboo; Robert Ransdell; [email-masked]
> Objet : Re: RE : [Ietf-calsify] rfc 2446 - Cancel and sequence numb=
er
>=20
>=20
> Arnaud Quillaud wrote:
> > The rules for incrementing the SEQUENCE are still defined in the=
=20
> > calsify draft at=20
> >=20
> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section=
-3.
> > 8.7.4
> >
> > Shouldn't those be removed from there (if it is not too late)
>=20
> This sounds right to me, and no it's not too late.  The one group o=
f=20
> changes we said we would allow to RFC 2445bis would be those arisin=
g=20
> from changes to the other documents, and in particular iTIP.
>=20
> > Arnaud Quillaud
> >
> > PS: the current Sun Calendar Server is probably not a good=20
> example in=20
> > terms of implementation as it bumps up the seq number for=20
> pretty much any change.
> >  =20
>=20
> Does it present a change to a user?  If so, that must be frustratin=
g.
>=20

In most cases it does not.

Arnaud

Date: Sat, 17 Mar 2007 13:21:43 +0100
From: Eliot Lear <[email-masked]>
To: Arnaud Quillaud <[email-masked]>
Subject: Re: RE : [Ietf-calsify] rfc 2446 - Cancel and sequence number
Cc: [email-masked]

Arnaud Quillaud wrote:
> The rules for incrementing the SEQUENCE are still defined in the calsify draft at http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.8.7.4
>
> Shouldn't those be removed from there (if it is not too late) 

This sounds right to me, and no it's not too late.  The one group of 
changes we said we would allow to RFC 2445bis would be those arising 
from changes to the other documents, and in particular iTIP.

> Arnaud Quillaud
>
> PS: the current Sun Calendar Server is probably not a good example in terms of implementation as it bumps up the seq number for pretty much any change.
>   

Does it present a change to a user?  If so, that must be frustrating.

Eliot

Content-return: prohibited
Date: Sat, 17 Mar 2007 10:06:04 +0100
From: Arnaud Quillaud <[email-masked]>
Subject: RE : [Ietf-calsify] rfc 2446 - Cancel and sequence number
Sender: [email-masked]
To: Cyrus Daboo <[email-masked]>, Robert Ransdell <[email-masked]>, [email-masked]

> -----Message d'origine-----
> De : [email-masked]=20
> [mailto:[email-masked]] De la part de=20
> Cyrus Daboo
> Envoy=E9 : vendredi 16 mars 2007 19:02
> =C0 : Robert Ransdell; [email-masked]
> Objet : Re: [Ietf-calsify] rfc 2446 - Cancel and sequence number
>=20
>=20
> Hi Robert,
>=20
> --On March 16, 2007 1:39:20 PM -0400 Robert Ransdell=20
> <[email-masked]> wrote:
>=20
> > This has been discussed before but worth bringing up again.
> >
> > section 3.2.5 says that when you cancel a meeting you must bump t=
he
> > sequence number.   This works for a real cancel but when=20
> chair is just
> > removing a single attendee.
> >
> > When rfc 2446 was first being designed there was a method=20
> for removing=20
> > a person and a different method for canceling the meeting. When y=
ou=20
> > remove a person you can not bump the sequence number,=20
> because doing so=20
> > does not allow the chair to re-invite that person without=20
> rescheduling=20
> > to all.
>=20
> I am not sure I understand why there is a problem with always=20
> bumping the=20
> sequence number for a CANCEL. The chair does not have to send=20
> out an update=20
> to everyone if they later decide to re-invite the cancelled attende=
e.
>=20
> However, arguably the correct thing for the chair to do is:
>=20
> 1) Bump SEQUENCE
> 2) Send CANCEL to the attendee being removed
> 3) Send REQUEST to other attendees with the cancelled=20
> attendee no longer=20
> listed (this informs the other attendees that someone is no longer=
=20
> attending)
>=20
> Then to re-invite:
>=20
> 1) Bump SEQUENCE
> 2) Send REQUEST to all attendees (including the re-invited one)
>=20
> However, I suspect this all boils down to how you interpret=20
> the SEQUENCE=20
> behavior. I think that is one area where people have=20
> different views. For=20
> example, should the organizer always bump the sequence for=20
> every change to=20
> the event? Or should it only be bumped when it is something that wi=
ll=20
> likely change other attendees participation status? In=20
> reality, who gets to=20
> decide the later? An attendee may choose to participate or=20
> not based on=20
> some criteria that the organizer may not be able to fathom.
>=20
> As part of the iTIP revision process I want to pin down the=20
> semantics of=20
> SEQUENCE precisely. To that end I would like to ask existing=20
> implementer to=20
> describe their own interpretation

The rules for incrementing the SEQUENCE are still defined in the cals=
ify draft at http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis=
-06#section-3.8.7.4

Shouldn't those be removed from there (if it is not too late) ?

Arnaud Quillaud

PS: the current Sun Calendar Server is probably not a good example in=
 terms of implementation as it bumps up the seq number for pretty muc=
h any change.

>=20
> --=20
>=20
> [email-masked]=20
>=20

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 7d9a83b71c1bcc41093c079f1eb50ccd
X-Spam-Score-Summary: 2, 0, 0, 921ffa70e94e0dd2, 2ca01a0416685845, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:960:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1543:1587:1593:1594:1605:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2526:2552:2553:2559:2562:2828:3027:3484:3636:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4321:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Jonathan Lennox" <[email-masked]>
Subject: Re: [Ietf-calsify] Issues 8, 68, 69, 70
Date: Fri, 16 Mar 2007 19:20:35 -0000
Cc: [email-masked]

> The one problem with it is the following:
> DTSTART;TZID=America/New_York:20070311T023000
> DTEND;TZID=America/New_York:20070311T031500
>
> The DTSTART is non-existent, falling during the spring-forward period; the
> DTEND is well-defined.
>
> Under your proposal, this event's end time would end up before its start
> time.   Its start time evaluates as 2007-03-11 02:30:00 "EST" (UTC-5) =
> 2007-03-11 07:30:00 UTC = 2007-03-11 03:30:00 EDT, but its end time is
> 2007-03-11 03:15:00 EDT, 15 minutes earlier.
>
> (This is analogous to the problem you discovered with your operator+.)
>
> Do we care about this corner case of a corner case?  Should we just define
> such odd outcomes as zero-duration events?

I think it falls into the category of "the client should make every effort 
not to create events with date-times that land in the leap forward period" 
and then go on to recommend how we handle them.  I think we handle the above 
event just like any other event that has a DTEND before the DTSTART. 
Surprisingly I can't find existing recommendation on this subject, but I 
suggest we "fix" DTEND by moving it to match DTSTART, or by ignoring DTEND 
as invalid, which would have the same effect.  ie yes, define them as 
zero-duration events. :o)

> The other "corner-case squared" we have to worry about is
>    DTSTART;TZID=Pacific/Kiritimati:19950101T090000
>    DURATION:P1D
> In the 90s, the Pacific nation of Kiribati (the Gilbert Islands, before
> independence) decided it was tired of having the International Date Line
> split the country in two.  Thus, its eastern island groups switched from
> UTC-11/UTC-10 to UTC+13/UTC+14, skipping January 1, 1995.  (These are the
> Olsen zones Pacific/Enderbury and Pacific/Kiritimati, respectively.)
>
> In this case, a P1D nominal duration would presumably last zero time, and 
> a
> DAILY recurrence would have two simultaneous occurences.  A similar odd
> VTIMEZONE definition could potentially result in nominal durations coming
> out as negative elapsed time.  Again, do we care?

I guess +1D would land you on a date that existed in the gigantic leap 
forward period between -11/-10 and +13/+14.  We'd then convert to UTC 
using -11/-10, and then back to local time using +13/+14.  After adding the 
next +1D, we'd have left the leap forward period, and entered +13/+14 proper 
and now Adjust() would become a noop again.

So 19941231 had -10, and they jumped to +14, therefore the clock went from:
DTSTART;TZID=Pacific/Kiritimati:19941231T235959 => DTSTART;19950101T095959Z
DTSTART;TZID=Pacific/Kiritimati:19950102T000000 <= DTSTART;19950101T100000Z

So with
DTSTART;TZID=Pacific/Kiritimati:19941230T090000
DURATION:P1D
RECUR:FREQ=DAILY

Instance 1)
19941230T090000-19941231T090000

Instance 2)
Start:19941231T090000
End:
Adjust(19941231T090000 + 1D)
Adjust(19950101T090000)
FromUtc(19950101T190000Z) (In leap forward period, so ToUtc uses UTC -10)
19950102T090000 (After TZ switch, so now use UTC +14)

Gives:
19941231T090000-19950102T090000

Instance 3)
Start:
19941231T090000 + 1D = 19950102T090000
End
19941231T090000 + 2D
19950102T090000

Gives:
19950102T090000-19950102T090000

Instance 4)
19950102T090000-19950103T090000

The set is therefore:
19941230T090000-19941231T090000
19941231T090000-19950102T090000  - Appears to span two days
19950102T090000-19950102T090000  - The oddity which describes an instant 
rather than a day.
19950102T090000-19950103T090000

I'd be happy enough with these rules.  Seems to work ok?  Remembering again 
they could have used P24H instead of 1D, or specified the rule in UTC to get 
a differerent potentially more desirable effect.

Nigel 

Date: Fri, 16 Mar 2007 12:04:05 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Announcing CalConnect Roundtable IX and Interoperability Test Event - May 7-11, Seattle, Washington
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------060906050502040504030405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

*The Calendaring and Scheduling Consortium announces Roundtable IX and  
Interoperability Test Event

*CalConnect would like to invite you to our Roundtable IX and the 
associated CalConnect Interoperability Test Event, the week of May 7-11, 
2007, in Seattle, Washington, hosted by The Boeing Company.  
Registration is now open for the Roundtable and/or the IOP test event.  
Logistics and registration information may be found at 
http://www.calconnect.org/roundtable9.shtml and at 
http://www.calconnect.org/iopmay2007.shtml.

General schedule:  The IOP test will begin at noon Monday and run 
through noon Wednesday.  The Roundtable will begin at lunch on Wednesday 
and run through lunch on Friday.  Possible optional Roundtable sessions 
may be held Wednesday morning prior to lunch. 

The IOP test event will involve both CalDAV and regular iCalendar, iMIP 
and iTIP interoperability testing scenarios.  In addition, plans and 
preliminary work for a Mobile Calendar IOP Test Event, and the scenarios 
associated with that event, will be covered.

Roundtables are largely comprised of technical committee sessions, which 
generally include reports on work accomplished or in progress, working 
sessions in a "committee of the whole" environment for all interested 
parties, and discussions about work to be undertaken.

Scheduling BOFs at the January events proved extremely valuable to the 
attendees.  Therefore, the Roundtable and IOP test event schedules in 
May have been adjusted to allow time for BOFs during both events.  BOFs 
may be scheduled in advance by request, or on an ad hoc basis at the 
events.

If you are not currently a member of the Consortium, you may attend a 
single Roundtable, or a single IOP test event, as an observer; see 
http://www.calconnect.org/observer.shtml for more information.

Both members and non-members may participate in the IOP test events.

We hope to see you in Seattle!

Dave Thewlis

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) � +1 707 498 2238 (mobile)
http://www.calconnect.org � [email-masked] 
<mailto:[email-masked]>

--------------060906050502040504030405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!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">
<b>The Calendaring and Scheduling Consortium announces Roundtable IX
and&nbsp; Interoperability Test Event<br>
<br>
</b>CalConnect would like to invite you to our Roundtable IX and the
associated CalConnect Interoperability Test Event, the week of May
7-11, 2007, in Seattle, Washington, hosted by The Boeing Company.&nbsp;
Registration is now open for the Roundtable and/or the IOP test event.&nbsp;
Logistics and registration information may be found at <a
 href="http://www.calconnect.org/roundtable9.shtml">http://www.calconnect.org/roundtable9.shtml</a>
and at <a href="http://www.calconnect.org/iopmay2007.shtml">http://www.calconnect.org/iopmay2007.shtml</a>.<br>
<br>
General schedule:&nbsp; The IOP test will begin at noon Monday and run
through noon Wednesday.&nbsp; The Roundtable will begin at lunch on
Wednesday and run through lunch on Friday.&nbsp; Possible optional
Roundtable sessions may be held Wednesday morning prior to lunch.&nbsp; <br>
<br>
The IOP test event will involve both CalDAV and regular iCalendar, iMIP
and iTIP interoperability testing scenarios.&nbsp; In addition, plans and
preliminary work for a Mobile Calendar IOP Test Event, and the
scenarios associated with that event, will be covered.<br>
<br>
Roundtables are largely comprised of technical committee sessions,
which generally include reports on work accomplished or in progress,
working sessions in a "committee of the whole" environment for all
interested parties, and discussions about work to be undertaken. <br>
<br>
Scheduling BOFs at the January events proved extremely valuable to the
attendees.&nbsp; Therefore, the Roundtable and IOP test event schedules in
May have been adjusted to allow time for BOFs during both events.&nbsp; BOFs
may be scheduled in advance by request, or on an ad hoc basis at
the events. <br>
<br>
If you are not currently a member of the Consortium, you may attend a
single Roundtable, or a single IOP test event, as an observer; see <a
 href="http://www.calconnect.org/observer.shtml">http://www.calconnect.org/observer.shtml</a>
for more information.<br>
<br>
Both members and non-members may participate in the IOP test events.<br>
<br>
We hope to see you in Seattle!<br>
<br>
Dave Thewlis<br>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------060906050502040504030405--

Date: Fri, 16 Mar 2007 14:02:18 -0400
From: Cyrus Daboo <[email-masked]>
To: Robert Ransdell <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] rfc 2446 - Cancel and sequence number

Hi Robert,

--On March 16, 2007 1:39:20 PM -0400 Robert Ransdell 
<[email-masked]> wrote:

> This has been discussed before but worth bringing up again.
>
> section 3.2.5 says that when you cancel a meeting you must bump the
> sequence number.   This works for a real cancel but when chair is just
> removing a single attendee.
>
> When rfc 2446 was first being designed there was a method for removing a
> person and a different method for canceling the meeting.
> When you remove a person you can not bump the sequence number, because
> doing so does not allow the chair to re-invite that person without
> rescheduling to all.

I am not sure I understand why there is a problem with always bumping the 
sequence number for a CANCEL. The chair does not have to send out an update 
to everyone if they later decide to re-invite the cancelled attendee.

However, arguably the correct thing for the chair to do is:

1) Bump SEQUENCE
2) Send CANCEL to the attendee being removed
3) Send REQUEST to other attendees with the cancelled attendee no longer 
listed (this informs the other attendees that someone is no longer 
attending)

Then to re-invite:

1) Bump SEQUENCE
2) Send REQUEST to all attendees (including the re-invited one)

However, I suspect this all boils down to how you interpret the SEQUENCE 
behavior. I think that is one area where people have different views. For 
example, should the organizer always bump the sequence for every change to 
the event? Or should it only be bumped when it is something that will 
likely change other attendees participation status? In reality, who gets to 
decide the later? An attendee may choose to participate or not based on 
some criteria that the organizer may not be able to fathom.

As part of the iTIP revision process I want to pin down the semantics of 
SEQUENCE precisely. To that end I would like to ask existing implementer to 
describe their own interpretation.

-- 
Cyrus Daboo

From: Jonathan Lennox <[email-masked]>
Date: Fri, 16 Mar 2007 13:50:48 -0400
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] Issues 8, 68, 69, 70
Cc: [email-masked]

On Friday, March 16 2007, "Nigel Swinson" wrote to "Jonathan Lennox, <[email-masked]>" saying:

> I propose we deal with this as follows:
> - A date-time landing in a spring forward period uses the utc-offset in 
> effect before the TZ change
> - A date-time landing in a fall back period uses the utc-offset in effect 
> before the TZ change.

This is probably the simplest fully-specified definition for
discontinuities.

The one problem with it is the following:
DTSTART;TZID=America/New_York:20070311T023000
DTEND;TZID=America/New_York:20070311T031500

The DTSTART is non-existent, falling during the spring-forward period; the
DTEND is well-defined.

Under your proposal, this event's end time would end up before its start
time.   Its start time evaluates as 2007-03-11 02:30:00 "EST" (UTC-5) =
2007-03-11 07:30:00 UTC = 2007-03-11 03:30:00 EDT, but its end time is
2007-03-11 03:15:00 EDT, 15 minutes earlier.

(This is analogous to the problem you discovered with your operator+.)

Do we care about this corner case of a corner case?  Should we just define
such odd outcomes as zero-duration events?

The other "corner-case squared" we have to worry about is
    DTSTART;TZID=Pacific/Kiritimati:19950101T090000
    DURATION:P1D
In the 90s, the Pacific nation of Kiribati (the Gilbert Islands, before
independence) decided it was tired of having the International Date Line
split the country in two.  Thus, its eastern island groups switched from
UTC-11/UTC-10 to UTC+13/UTC+14, skipping January 1, 1995.  (These are the
Olsen zones Pacific/Enderbury and Pacific/Kiritimati, respectively.)

In this case, a P1D nominal duration would presumably last zero time, and a 
DAILY recurrence would have two simultaneous occurences.  A similar odd
VTIMEZONE definition could potentially result in nominal durations coming
out as negative elapsed time.  Again, do we care?

-- 
Jonathan Lennox
[email-masked]

To: [email-masked]
Date: Fri, 16 Mar 2007 13:39:20 -0400
From: "Robert Ransdell" <[email-masked]>
Subject: [Ietf-calsify] rfc 2446 - Cancel and sequence number

--=_alternative 0060FC1A852572A0_=
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

This has been discussed before but worth bringing up again.

section 3.2.5 says that when you cancel a meeting you must bump the=20
sequence number.   This works for a real cancel but when chair is just=20
removing a single attendee.

When rfc 2446 was first being designed there was a method for removing a=20
person and a different method for canceling the meeting.
When you remove a person you can not bump the sequence number, because=20
doing so does not allow the chair to re-invite that person without=20
rescheduling to all.
=20

--=_alternative 0060FC1A852572A0_=
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<br><font size=3D2 face=3D"sans-serif">This has been discussed before but w=
orth
bringing up again.</font><br><br><font size=3D2 face=3D"sans-serif">section=
 3.2.5 says that when you cancel
a meeting you must bump the sequence number. &nbsp; This works for a real
cancel but when chair is just removing a single attendee.</font><br><br><fo=
nt size=3D2 face=3D"sans-serif">When rfc 2446 was first being designed
there was a method for removing a person and a different method for canceli=
ng
the meeting.</font><br><font size=3D2 face=3D"sans-serif">When you remove a=
 person you can not
bump the sequence number, because doing so does not allow the chair to
re-invite that person without rescheduling to all.</font><br><font size=3D2=
 face=3D"sans-serif">&nbsp; &nbsp;</font><BR>
--=_alternative 0060FC1A852572A0_=--

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 7729710623e7b6fd4af3adea5491fd5a
X-Spam-Score-Summary: 2, 0, 0, a359772ed984727c, 2ca01a0416685845, [email-masked], , RULES_HIT:1:355:379:539:540:541:542:543:567:599:601:945:973:980:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1587:1593:1594:1605:1730:1747:1766:1792:2073:2075:2078:2194:2198:2199:2200:2379:2393:2526:2552:2553:2559:2562:2637:2689:2692:2693:2736:2828:2917:3027:3636:3834:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:4321:4470:4560:4605:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Jonathan Lennox" <[email-masked]>, <[email-masked]>
Subject: Re: [Ietf-calsify] Issues 8, 68, 69, 70
Date: Fri, 16 Mar 2007 16:21:07 -0000

>> As the jabber session clearly indicates we are having difficulty with
>> the many corner cases presented when a local time either occurs twice or
>> doesn't occur at all.
>> This will be a topic for the working group meeting.  Please have your
>> proposals to the mailing list BEFORE the meeting.
>
> For the sake of the working group meeting, here's a taxonomy of possible
> solutions for local time discontinuities.  I don't have a single concrete
> proposal at this point, but I think this will help move our discussion of
> possible solutions forward.

I propose we deal with this as follows:
- A date-time landing in a spring forward period uses the utc-offset in 
effect before the TZ change
- A date-time landing in a fall back period uses the utc-offset in effect 
before the TZ change.
- If you want to distinguish between the two date-times resulting from a 
fall-back period, you should write your rule WRT to a TZ that doesn't use 
DST like in plain UTC.  (Vent poisionous gasses every hour etc)
- local date-times can and should be validated before storage, and during 
recurrence expansion such that times in the spring forward period are always 
corrected.

A commentary of Jonathan's helpful discussion to see how this works out in 
practice.

======================================
> Repeated times: local wall-clock values that occur more than once.
>         E.g.: 2007-11-04 01:30:00 America/New_York.
>
> Possible solutions:
> R1.  Repeated time values are interpreted as the first occurence of the
> repeated time.
>         E.g.: 2007-11-04 01:30:00 EDT = 2007-11-04 05:30:00 UTC

This one, as this 1:30 EDT always turns into 5:30 UTC, never 6:30 UTC.

> R2.  Repeated time values are interpreted as the final occurence of the
> repeated time.
>         E.g.: 2007-11-04 01:30:00 EST = 2007-11-04 06:30:00 UTC

No, cos I think recurrence sets have to be stored as local time, so BYHOUR 
works properly, and 1:30 EST won't turn into 6:30 UTC.

> R3.  Events represented by repeated time values take place at every
> occurence of the repeated time.

No.  You'd use UTC or a TZ with no DST if you wanted there to be two.

> R4.  Repeated time values are interpreted as an unspecified occurence
> of the repeated time.

I'm fine with unspecified, I don't mind if implementations aren't fully 
interoperable here, and it would allow me to choose R1.

> R5.  Repeated time values are interpreted as an an unspecified time in
> time in the range [R1 - R2].

If I fully understand this, which I'm not sure I do, then I don't like this 
as I don't think it makes a lot of sense. (!!?!!)  More helpfully it sounds 
like it might change the minutes of the time which I think is bad.

> R6.  Repeated time values are completely unspecified, and intepreters can
> treat them however they like.

Fine, allows we to choose R1 yes?

> R7.  Repeated time values are forbidden, and interpreters MUST reject any
> iCalendar document specifying them.

I don't think this is practical.  It seems very easy to create a rule that 
would naievely create repeated times, but with my proposal you can't get 
duplicated times, as "1:30 EDT always turns into 5:30 UTC, never 6:30 UTC".

======================================
> Skipped times: local wall-clock values that do not occur.
>        E.g.: 2007-03-11 02:30:00 America/New_York.

I think the solution here is fairly arbitrary, my personal opinion is that 
S2 is what most would expect, but I'm happy if the behaviour is undefined.

> Possible solutions:
> S1.  Skipped time values are interpreted as the instant of the
> discontinuity which skipped the time.
>       E.g.: 2007-03-11 03:00:00 EDT = 2007-03-11 07:00:00 UTC
>       (Note that this is one second after
>             2007-03-11 01:59:59 EST = 2007-03-11 06:59:59 UTC.)

No. I think you are proposing that 02:34 EDT becomes 03:00 EDT.  I don't 
like the suggestion that we would change the seconds/minutes.

> S2.  Skipped time values are interpreted using the UTC offset from before
> the discontinuity.
>       E.g.: 2007-03-11 02:30:00 "EST" (UTC-5) = 2007-03-11 07:30:00 UTC =
>             2007-03-11 03:30:00 EDT

Yes

> S3.  Skipped time values are interpreted using the UTC offset from after
> the discontinuity.
>       E.g.: 2007-03-11 02:30:00 "EDT" (UTC-4) = 2007-03-11 06:30:00 UTC =
>             2007-03-11 01:30:00 EST

No

> S4.  Events represented by skipped time values do not take place.

Definately not.

> S5.  Skipped time values are interpreted as an unspecified instance of 
> {S3,
> S2}.

Ok, I'll choose S2

> S6.  Skipped time values are interpreted as an unspecified instance of 
> {S3,
> S1, S2}.

No

> S7.  Skipped time values are interpreted as an unspecified time in the
> range [S3 - S2].

No, same reason as S1

> S8.  Skipped time values are completely unspecified, and intepreters can
> treat them however they like.

Ok, I'll choose S2

> S9.  Skipped time values are forbidden, and interpreters MUST reject any
> iCalendar document specifying them.

I don't think this is practical

======================================
> There are also several ways that discontinuous times can arise in
> iCalendar.  I've described these by their issue numbers in Calsify issue
> tracker, breaking down further where necessary

You effectively call this on each instance to correct for leap forward 
periods.

TimeZone::Adjust() {
 // ToUtc will fix any leap forward problems, and FromUtc will take us back
 FromUtc(ToUtc());
}

> I68: Discontinuous times explicitly specified in an iCalendar document,
> other than in an VTIMEZONE (where they're well-defined by 2445).
>      DTSTART;TZID=America/New_York:20070311T023000

Convert to UTC using winter time.  Adjust() would move this to 
20070311T033000.

It is obviously going to be helpful if clients make their best efforts to 
prevent creation of times like this.

>      DTEND;TZID=America/New_York:20071104T013000

Convert to UTC using summer time. Adjust() would leave this as 
20071104T013000.

> I69: Discontinuous times that arise as a recurrence instance's start time.
>        DTSTART;TZID=America/New_York:20070310T023000
>        RECUR:FREQ=DAILY;COUNT=2
>
>        The first occurence of this event is well-defined, taking place at
>        2007-03-10 02:30:00 EST; the event's second occurence is
>        problematic.

Date arithmetic (as opposed to time arithmetic) can/should be done without 
timezones, so:

Adjust(20070310T023000 + 2D)
=Adjust(20070310 + 2D + T023000)
=Adjust(20070312 + T023000)
=Adjust(20070312T023000)
=20070312T023000

> I70a1: Discontinuous times that arise because of a nominal event duration,
> offset from an explicit time.
>        DTSTART;TZID=America/New_York:20070310T023000
>        DURATION:P1D
>
>        The start time of this event is well-defined, taking place at
>        2007-03-10 02:30:00 EST; the event's end time is problematic.

1D means end at 02:30 and Adjust() moves it to T033000

> I70a2: Discontinuous times that arise because of a hybrid nominal/accurate
> event duration, offset from an explicit time.
>        DTSTART;TZID=America/New_York:20070310T023000
>        DURATION:P1DT8H
>
>        The start time of this event is well-defined, taking place at
>        2007-03-10 02:30:00 EST; the event's end time is problematic.

+1D first, then +8H then Adjust means,
=Adjust(20070310T023000 + 1D + 8H)
=Adjust(20070311T023000 + 8H)
=Adjust(20070311T113000) (we've added 9 hours because of the DST, I suggest 
date-time arithmetic always done in UTC)
=20070311T113000

> I70b1: Discontinuous times that arise because of a nominal event duration,
> offset from a recurrence instance's start time.
>        DTSTART;TZID=America/New_York:20070309T023000
>        DURATION:P1D
>        RECUR:FREQ=DAILY;COUNT=2
>
>        The first occurence of this event lasts from 2007-03-09 02:30:00 
> EST
>        to 2007-03-10 02:30:00 EST.  The second occurence starts at
>        2007-03-10 02:30:00 EST, but its end time is problematic.

Adjust means end time is T033000

> I70b2: Discontinuous times that arise because of a hybrid nominal/accurate
> event duration, offset from a recurrence instance's start time.
>        DTSTART;TZID=America/New_York:20070309T023000
>        DURATION:P1DT8H
>        RECUR:FREQ=DAILY;COUNT=2
>
>        The first occurence of this event lasts from 2007-03-09 02:30:00 
> EST
>        to 2007-03-10 10:30:00 EST.  The second occurence starts at
>        2007-03-10 02:30:00 EST, but its end time is problematic.

As for I70a2, end time is 20070311T113000

> I8/I68: A nominal duration starting from an explicitly-specified
> discontinuous time.
>      DTSTART;TZID=America/New_York:20070311T023000
>      DURATION:P1D
>
>      The naively-calculated end time, 2007-03-12 02:30:00 EDT, is
>      well-defined, but this may be surprising based on the resolution of
>      the start time.

I think we apply the duration before we Adjust().  As above, I think the 
user expects the appointment to finish at 2:30, and probably didn't think 
about DST when they created it.  If we Adjust() then apply duration calling 
Adjust() on the end time, then that means it'll start and end at 3:30am.  So 
I think the naively-calculated end time is correct. It is obviously going to 
be helpful if clients make their best efforts to prevent creation of times 
like this.

> I8/I69: A nominal duration starting from a discontinuous recurrance 
> instance
> start time.
>      DTSTART;TZID=America/New_York:20070310T023000
>      RECUR:FREQ=DAILY;COUNT=2
>      DURATION:P1D
>
>      The naively-calculated end time of the second occurence, 2007-03-12
>      02:30:00 EDT, is well-defined, but this may be surprising based on 
> the
>      resolution of the start time.

Again I think we apply the duration before we call Adjust(), but our 
recurrence set is based on days.  I'll presume count was 4 as it's 
interesting:

1) 20070310T023000-20070311T033000 (Adjust() Fixed endtime)
2) 20070311T033000-20070312T023000 (Applied duration before Adjust() fixed 
starttime)
3) 20070312T023000-20070313T023000 (What the user was really expecting)
4) 20070313T023000-20070314T023000

It's probably worth restating that the user can always enter their 
recurrence rule WRT to UTC should this kind of oddity not be as they would 
like.  Then if you are viewing the calender WRT to EST you'll get two 
recurrences at the same time WRT to that timezone, but on closer examination 
you'd see the start time was different WRT to UTC.

> I hope this is helpful.

It was thanks!  It made me realise that my CLocalTime::operator+ when adding 
45 mins, could possibly return a localtime than was before the source time 
potentially resulting in an infinite loop!

Nigel 

Date: Thu, 15 Mar 2007 21:14:25 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked], [email-masked]
Subject: [Ietf-calsify] [Fwd: RFC 4791 on Calendaring Extensions to WebDAV (CalDAV)]

FYI

-------- Original Message --------
Subject: RFC 4791 on Calendaring Extensions to WebDAV (CalDAV)
Date: Thu, 15 Mar 2007 14:51:26 -0700
From: [email-masked]
To: [email-masked], [email-masked]
CC: [email-masked]

A new Request for Comments is now available in online RFC libraries.

         RFC 4791

         Title:      Calendaring Extensions to WebDAV (CalDAV)
         Author:     C. Daboo, B. Desruisseaux,
                     L. Dusseault
         Status:     Standards Track
         Date:       March 2007
         Mailbox:    [email-masked],
                     [email-masked],
                     [email-masked]
         Pages:      107
         Characters: 206801
         Updates/Obsoletes/SeeAlso:   None

         I-D Tag:    draft-dusseault-caldav-15.txt

         URL:        http://www.rfc-editor.org/rfc/rfc4791.txt

This document defines extensions to the Web Distributed Authoring and
Versioning (WebDAV) protocol to specify a standard way of accessing,
managing, and sharing calendaring and scheduling information based on
the iCalendar format.  This document defines the "calendar-access"
feature of CalDAV.  [STANDARDS TRACK]

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and
suggestions for improvements.Please refer to the current edition of the
Internet Official Protocol Standards (STD 1) for the standardization
state and status of this protocol.  Distribution of this memo is
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body

help: ways_to_get_rfcs. For example:

         To: [email-masked]
         Subject: getting rfcs

         help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

Date: Wed, 14 Mar 2007 12:48:28 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] Attendees without email addresses

Hi Reinhold,

--On March 14, 2007 5:43:48 PM +0100 Reinhold Kainhofer 
<[email-masked]> wrote:

>> If you are not going to use iTIP at all, why not just use a bogus email
>> address: e.g., "mailto:[email-masked]"? Or use the urn:uuid
>> scheme and generate a uuid for each unique attendee.
>
> Because we display that URI (in a clickable way) and let KDE's URL
> handler  handle clicks on that URI (e.g. for sending a mail to that
> attendee or for  showing the web page or for joining that IRC channel or
> jabber room).  Inserting bogus data will (a) mess up that system as we
> need to filter out  bogus data and (b) when importing that calendar in a
> different application,  that application will treat the bogus data as
> real data...

Then use urn:uuid:... - your URL handler will likely not know what to do 
with it, so there should not be any unexpected actions resulting from a 
click on the URI.

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] Attendees without email addresses
Date: Wed, 14 Mar 2007 17:43:48 +0100

Am Mittwoch, 14. M�rz 2007 schrieben Sie:
> If you are not going to use iTIP at all, why not just use a bogus email
> address: e.g., "mailto:[email-masked]"? Or use the urn:uuid scheme
> and generate a uuid for each unique attendee.

Because we display that URI (in a clickable way) and let KDE's URL handler 
handle clicks on that URI (e.g. for sending a mail to that attendee or for 
showing the web page or for joining that IRC channel or jabber room). 
Inserting bogus data will (a) mess up that system as we need to filter out 
bogus data and (b) when importing that calendar in a different application, 
that application will treat the bogus data as real data...

Cheers,
Reinhold
- -- 

Date: Wed, 14 Mar 2007 12:12:50 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] Attendees without email addresses

Hi Reinhold,

--On March 14, 2007 4:25:41 PM +0100 Reinhold Kainhofer 
<[email-masked]> wrote:

> When an attendee (or an organizer) does not have an email adress (or any
> other  type of unique URI), what shall be the value of the ATTENDEE
> property? E.g. I  have an informal gethering at my place and I only know
> the names of some  visitors, but nothing else. Clearly, I want to have
> these persons also as  attendees to my event. However, RFC 2445 requires
> the value of the ATTENDEE  property to be a cal-address, which is defined
> to be any valid URI (RFC  1738). However, I don't have any uniquely
> identifying information, and simply  using the name of the person is
> disallowed by the RFC...
>
> So, what should a calendar application do in this case. Of course, you
> cannot  send iTIP invitations, but for data im-/export with other
> calendaring  applications (also with groupware servers!), this attendee
> information needs  to be available.

If you are not going to use iTIP at all, why not just use a bogus email 
address: e.g., "mailto:[email-masked]"? Or use the urn:uuid scheme 
and generate a uuid for each unique attendee.

-- 
Cyrus Daboo

From: Jonathan Lennox <[email-masked]>
Date: Wed, 14 Mar 2007 11:49:16 -0400
To: "[email-masked]" <[email-masked]>
Subject: Re: [Ietf-calsify] Issues 8, 68, 69, 70

On Thursday, March 8 2007, "Eliot Lear" wrote to "[email-masked]" saying:

> Dear all,
> 
> As the jabber session clearly indicates we are having difficulty with 
> the many corner cases presented when a local time either occurs twice or 
> doesn't occur at all.
> This will be a topic for the working group meeting.  Please have your 
> proposals to the mailing list BEFORE the meeting.

For the sake of the working group meeting, here's a taxonomy of possible
solutions for local time discontinuities.  I don't have a single concrete
proposal at this point, but I think this will help move our discussion of
possible solutions forward.

I will first discuss the types of local time discontinuities and various
possible ways of resolving them, and then discuss the ways that they can
arise.  (It may well be that the group decides on different resolutions for
discontinuities that arise in different ways.)

There are two types of discontinuities: repeated times ("fall back") and
skipped times ("spring forward").

Repeated times: local wall-clock values that occur more than once.
         E.g.: 2007-11-04 01:30:00 America/New_York.

Possible solutions:
R1.  Repeated time values are interpreted as the first occurence of the
repeated time.
         E.g.: 2007-11-04 01:30:00 EDT = 2007-11-04 05:30:00 UTC

R2.  Repeated time values are interpreted as the final occurence of the
repeated time.
         E.g.: 2007-11-04 01:30:00 EST = 2007-11-04 06:30:00 UTC

R3.  Events represented by repeated time values take place at every
occurence of the repeated time.

R4.  Repeated time values are interpreted as an unspecified occurence
of the repeated time.

R5.  Repeated time values are interpreted as an an unspecified time in
time in the range [R1 - R2].

R6.  Repeated time values are completely unspecified, and intepreters can
treat them however they like.

R7.  Repeated time values are forbidden, and interpreters MUST reject any
iCalendar document specifying them.

(Note that in obscure situations, involving buggy VTIMEZONE definitions or
particularly crazy legislatures, local wall-clock values can actually occur
three or more times, not just twice.  I've worded my solutions above to take
this into account.)

Skipped times: local wall-clock values that do not occur.
        E.g.: 2007-03-11 02:30:00 America/New_York.

Possible solutions:
S1.  Skipped time values are interpreted as the instant of the
discontinuity which skipped the time.
       E.g.: 2007-03-11 03:00:00 EDT = 2007-03-11 07:00:00 UTC
       (Note that this is one second after
             2007-03-11 01:59:59 EST = 2007-03-11 06:59:59 UTC.)

S2.  Skipped time values are interpreted using the UTC offset from before
the discontinuity.
       E.g.: 2007-03-11 02:30:00 "EST" (UTC-5) = 2007-03-11 07:30:00 UTC =
             2007-03-11 03:30:00 EDT

S3.  Skipped time values are interpreted using the UTC offset from after
the discontinuity.
       E.g.: 2007-03-11 02:30:00 "EDT" (UTC-4) = 2007-03-11 06:30:00 UTC =
             2007-03-11 01:30:00 EST

S4.  Events represented by skipped time values do not take place.

S5.  Skipped time values are interpreted as an unspecified instance of {S3,
S2}.

S6.  Skipped time values are interpreted as an unspecified instance of {S3,
S1, S2}.

S7.  Skipped time values are interpreted as an unspecified time in the
range [S3 - S2].

S8.  Skipped time values are completely unspecified, and intepreters can
treat them however they like.

S9.  Skipped time values are forbidden, and interpreters MUST reject any
iCalendar document specifying them.

There are also several ways that discontinuous times can arise in
iCalendar.  I've described these by their issue numbers in Calsify issue
tracker, breaking down further where necessary.

I68: Discontinuous times explicitly specified in an iCalendar document,
other than in an VTIMEZONE (where they're well-defined by 2445).
      DTSTART;TZID=America/New_York:20070311T023000
      
      DTEND;TZID=America/New_York:20071104T013000

I69: Discontinuous times that arise as a recurrence instance's start time.
        DTSTART;TZID=America/New_York:20070310T023000
        RECUR:FREQ=DAILY;COUNT=2
        
        The first occurence of this event is well-defined, taking place at
        2007-03-10 02:30:00 EST; the event's second occurence is
        problematic.

I70a1: Discontinuous times that arise because of a nominal event duration,
offset from an explicit time.
        DTSTART;TZID=America/New_York:20070310T023000
        DURATION:P1D

        The start time of this event is well-defined, taking place at
        2007-03-10 02:30:00 EST; the event's end time is problematic.

I70a2: Discontinuous times that arise because of a hybrid nominal/accurate
event duration, offset from an explicit time.
        DTSTART;TZID=America/New_York:20070310T023000
        DURATION:P1DT8H

        The start time of this event is well-defined, taking place at
        2007-03-10 02:30:00 EST; the event's end time is problematic. 

I70b1: Discontinuous times that arise because of a nominal event duration,
offset from a recurrence instance's start time.
        DTSTART;TZID=America/New_York:20070309T023000
        DURATION:P1D
        RECUR:FREQ=DAILY;COUNT=2

        The first occurence of this event lasts from 2007-03-09 02:30:00 EST
        to 2007-03-10 02:30:00 EST.  The second occurence starts at
        2007-03-10 02:30:00 EST, but its end time is problematic.

I70b2: Discontinuous times that arise because of a hybrid nominal/accurate
event duration, offset from a recurrence instance's start time.
        DTSTART;TZID=America/New_York:20070309T023000
        DURATION:P1DT8H
        RECUR:FREQ=DAILY;COUNT=2

        The first occurence of this event lasts from 2007-03-09 02:30:00 EST
        to 2007-03-10 10:30:00 EST.  The second occurence starts at
        2007-03-10 02:30:00 EST, but its end time is problematic.

I8/I68: A nominal duration starting from an explicitly-specified
discontinuous time.
      DTSTART;TZID=America/New_York:20070311T023000
      DURATION:P1D

      The naively-calculated end time, 2007-03-12 02:30:00 EDT, is
      well-defined, but this may be surprising based on the resolution of
      the start time.

I8/I69: A nominal duration starting from a discontinuous recurrance instance
start time.
      DTSTART;TZID=America/New_York:20070310T023000
      RECUR:FREQ=DAILY;COUNT=2
      DURATION:P1D

      The naively-calculated end time of the second occurence, 2007-03-12
      02:30:00 EDT, is well-defined, but this may be surprising based on the
      resolution of the start time.

I hope this is helpful.

-- 
Jonathan Lennox
[email-masked]

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Date: Wed, 14 Mar 2007 16:25:41 +0100
Subject: [Ietf-calsify] Attendees without email addresses

Hi all!
While playing around with the ics validator 
(http://severinghaus.org/projects/icv/), I stumbled upon a little problem 
that I have not yet realized and what might be cleared in a Best Practices 
document or in an FAQ:

When an attendee (or an organizer) does not have an email adress (or any other 
type of unique URI), what shall be the value of the ATTENDEE property? E.g. I 
have an informal gethering at my place and I only know the names of some 
visitors, but nothing else. Clearly, I want to have these persons also as 
attendees to my event. However, RFC 2445 requires the value of the ATTENDEE 
property to be a cal-address, which is defined to be any valid URI (RFC 
1738). However, I don't have any uniquely identifying information, and simply 
using the name of the person is disallowed by the RFC...

So, what should a calendar application do in this case. Of course, you cannot 
send iTIP invitations, but for data im-/export with other calendaring 
applications (also with groupware servers!), this attendee information needs 
to be available.

Cheers,
Reinhold
- -- 

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issues 8, 68, 69, 70
Date: Fri, 9 Mar 2007 00:08:24 +0100

Am Donnerstag, 8. März 2007 schrieb Eliot Lear:
> Failing a resolution in person, we must ask how
> important it is to deal with these DST transitions.

To be honest, in KOrganizer and libkcal (which is used in all KDE applications 
that use calendars to any extent), we don't care about the transitions at 
all, so this is not a real issue for us. It's just an issue that a 
specification still needs to deal with...

Chers,
Reinhold

- -- 

Date: Thu, 08 Mar 2007 17:56:33 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issues 8, 68, 69, 70

Dear all,

As the jabber session clearly indicates we are having difficulty with 
the many corner cases presented when a local time either occurs twice or 
doesn't occur at all.  The proposals we have seen have the flavors of:

1.  Doctor, it hurts when I hit my head...
2.  Specify what happens in each case (but nobody can agree on what 
happens in each case)

This will be a topic for the working group meeting.  Please have your 
proposals to the mailing list BEFORE the meeting.  We may go with 
something else, but the discussion will go faster if we have good 
starting points.  Failing a resolution in person, we must ask how 
important it is to deal with these DST transitions.

Thanks,

Eliot

Date: Thu, 08 Mar 2007 17:51:45 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] iTIP issues

Dear all,

As we will be discussing iTIP at the next IETF now is a good time to 
read the draft and come up with your list of issues that you would like 
to raise.  Having them out on the list BEFORE Prague gets you bonus points.

Thanks,

Eliot

Date: Thu, 08 Mar 2007 15:56:09 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber starts in 5 mins

See you there!

Date: Wed, 07 Mar 2007 21:20:37 +0100
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Cc: [email-masked]

Cyrus Daboo wrote:
> Speaking of which, which timezone are our jabber sessions on Thursday 
> "anchored" in? The last iCal that Elliot sent out used an updated 
> TZID:America/Los_Angeles except this Thursday is the last in the 
> recurrence set - so I guess we get to fight over who absorbs the hour 
> offset for the next few weeks where DSTs are not in sync across 
> continents!
>

Conveniently here comes the IETF face to face meeting ;-)

Date: Wed, 07 Mar 2007 12:25:42 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] rrule in timezone components
Cc: [email-masked]

Hi Mike,

--On March 6, 2007 11:17:38 PM -0800 Mike Samuel <[email-masked]> 
wrote:

> The spec could recommend an external TZID format like
> //Olson/<olson-id> which would help ical generators pick names that
> can be easily interpreted by others and explicitly permit calendaring
> systems that recognize that format to substitute their own definition.

Yup - that is the concept of a standard registry with the option of a 
timezone service that can deliver updated definitions to those who are 
interested. Calconnect did write a document with recommendations for such a 
service:

<http://www.calconnect.org/publications/timezoneregistryandservicerecommendationsv1.0.pdf>

> It would also make ical better as a persistence format.   You can
> include you're VTIMEZONE definition, but if the TZID is
> //Olson/America/Los_Angeles then a calendaring system that knows it
> has a more up-to-date definition of Los Angeles time could feel free
> to substitute it.

Actually, automatically updating timezones is not always appropriate. One 
of the big problems vendors have had with the upcoming EDST change is 
figuring out which events really should be upgraded. In practice you cannot 
automatically do that because sometimes users create events using their own 
local timezone, but the actual event is "anchored" in someone else's 
timezone.

e.g. someone in the UK calls up and tells me a future meeting is 15:00 GMT, 
which is 10:00 my time, so I go and enter it as 10:00 EST on my calendar. 
But then the DST rule changes for that period. If the VTIMEZONE were 
automatically updated, then my meeting time would be off by an hour.

That is why most calendar product vendors have had to tell their users that 
they need to double-check all meetings during the EDST change periods to 
verify they really are when they are supposed to be. This is obviously not 
an ideal situation. It will be interesting to see how many people miss 
meetings next Monday!

Speaking of which, which timezone are our jabber sessions on Thursday 
"anchored" in? The last iCal that Elliot sent out used an updated 
TZID:America/Los_Angeles except this Thursday is the last in the recurrence 
set - so I guess we get to fight over who absorbs the hour offset for the 
next few weeks where DSTs are not in sync across continents!

-- 
Cyrus Daboo

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: dd4e94902897e088d9016b58c44386ec
X-Spam-Score-Summary: 2, 0, 0, 3815f509c71385aa, 42f367296d8970cb, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:945:968:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1542:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2198:2199:2379:2393:2553:2559:2562:2692:2693:2731:2828:2894:2897:3027:3355:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:4250:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Date: Wed, 7 Mar 2007 16:38:06 -0000
Cc: [email-masked]

> This seems like something of an arbitrary restriction just for =
VTIMEZONE.=20
> Given that you have to support the full gamut of RRULE in VEVENT, =
VTODO=20
> etc, why does it matter if an RRULE in a VTIMEZONE is
>=20
> RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU
>=20
> as opposed to:
>=20
> RRULE:FREQ=3DMONTHLY;BYMONTH=3D3;BYDAY=3D2SU
>=20
> They both generate the same set. Why add more complexity by saying =
RRULE in=20
> VTIMEZONE is special and has extra restrictions that RRULE elsewhere =
does=20
> not?

Primarily for reasons of security and resuource usage but also to =
*reduce* implementational complexity.  RRules in timezones clearly must =
relate to annual events by the very definition of DST, and all the =
examples in the spec do so just now, so it seems like sensible advice to =
promote ineteroperability and protect installations.

Besides, you imply some neat recurrence engine that you can call =
arbitrarily from event, todo, timezone.  I don't think you can do that =
correctly, as we have to treat VTIMEZONE specially anyway:

An event can have a recurrence rule and a date-time dtstart.  This means =
you (potentially) need to understand the timezone in order to expand the =
recurring rule.  But to understand the timezone, you may need to expand =
a recurrence rule which comes with another date-time dtstart.   This is =
a cyclic dependancy which was complex to fix. =20

I found you end up with three recurrence engines, one that operates on =
dtstart of type date, one on UTC and one on LocalTime.  The timezone =
recurrence engine uses the UTC recurrence engine, and thus doesn't need =
to adjust for a timezone, despite the fact that the standard goes to =
great pains to tell me that dtstart is a local time, not in UTC.  I =
couldn't see how I could consider that as a local time as how then could =
I know how to adjust for DST when that's exactly what I was trying to =
define?  So I combine dtstart and offsetfrom and use the UTC recurrence =
engine.  The event can then use the LocalTime recurrence engine to =
expand it's rrule, where a localtime can combine the timezone and the =
datetime and thus break the cyclic dependancy.

> Of course it is true that wherever possible is probably more efficient =
from=20
> a computational standpoint to always use the highest FREQ value=20
> representation possible as they will result in the need to generate =
fewer=20
> "cycles" (* - see below) to calculate the recurrence set. Probably the =
same=20
> thing as saying its better to use a FREQ/BYxxx rule where the BYxxx =
rules=20
> "expand" the set of instances within one cycle, as opposed to a =
FREQ/BYxxx=20
> rule where the BYxxx rules remove entire cycles.

So I am wanting to be able to legally object to timezone definitions =
that could have been more efficiently expressed as freq=3Dyearly, and =
wanting to discourage future implementors from creating vtimezones that =
do otherwise.

Nigel

Date: Wed, 07 Mar 2007 11:01:08 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-2446bis-03.txt 

Hi folks,

--On March 7, 2007 10:50:02 AM -0500 [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Calendaring and Scheduling Standards
> Simplification Working Group of the IETF.
>
> 	Title		: iCalendar Transport-Independent Interoperability Protocol (iTIP)
> 	Author(s)	: C. Daboo
> 	Filename	: draft-ietf-calsify-2446bis-03.txt
> 	Pages		: 121
> 	Date		: 2007-3-7
> 	

This was just a quick update to refresh the draft as it had expired. There 
were no substantive changes. Hopefully we will be finished with the major 
work on 2445bis soon and we can move on to this beast.

-- 
Cyrus Daboo

Date: Wed, 07 Mar 2007 10:59:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Nigel Swinson <[email-masked]>, Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Cc: [email-masked]

Hi Nigel,

--On March 7, 2007 3:47:04 PM +0000 Nigel Swinson 
<[email-masked]> wrote:

>> Putting aside the fact that we are no longer entertaining changes beyond
>> the scope of changes made in response to closing open issues,
>
> So are we at least registering these ideas for discussion/action later
> rather than ignoring them as not on the "blessed list of open issues"?
> Again I can appreciate that dropping VTIMEZONE is a fairly major change,
> but surely restricting FREQ to yearly isn't so controversial we don't
> have the bandwidth to agree on that now?

This seems like something of an arbitrary restriction just for VTIMEZONE. 
Given that you have to support the full gamut of RRULE in VEVENT, VTODO 
etc, why does it matter if an RRULE in a VTIMEZONE is

RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU

as opposed to:

RRULE:FREQ=MONTHLY;BYMONTH=3;BYDAY=2SU

They both generate the same set. Why add more complexity by saying RRULE in 
VTIMEZONE is special and has extra restrictions that RRULE elsewhere does 
not?

Of course it is true that wherever possible is probably more efficient from 
a computational standpoint to always use the highest FREQ value 
representation possible as they will result in the need to generate fewer 
"cycles" (* - see below) to calculate the recurrence set. Probably the same 
thing as saying its better to use a FREQ/BYxxx rule where the BYxxx rules 
"expand" the set of instances within one cycle, as opposed to a FREQ/BYxxx 
rule where the BYxxx rules remove entire cycles.

* - I define a "cycle" as one iteration over the FREQ value.

-- 
Cyrus Daboo

Date: Wed, 07 Mar 2007 10:50:54 -0500
From: Cyrus Daboo <[email-masked]>
To: Eliot Lear <[email-masked]>, George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Cc: [email-masked]

Hi Eliot,

--On March 7, 2007 3:26:04 PM +0100 Eliot Lear <[email-masked]> wrote:

> Putting aside the fact that we are no longer entertaining changes beyond
> the scope of changes made in response to closing open issues, I can think
> of one reason why the Olson database itself is insufficient: it's not
> versioned.  You can't simply refer to America/Los_Angeles and understand
> what people meant.  Was it the old definition that had DST starting a few
> weeks from now or the new version where it starts in a few days?

Strictly speaking its not Olson that is unversioned, but rather the common 
VTIMEZONE derivations from Olson (remember Olson itself is not an iCalendar 
format - it has to be converted). The Olson db itself does have regular 
updates tagged by a "version" string - e.g., the current version is 
tzdata2007c, the previous one is tzdata2007b, etc.

The vzic conversion tool does allow you to specify different prefixes to 
timezone names. So with that, someone who cared about versioning could 
easily generate timezones with ids like /tzdata2007c/America/New_York etc. 
The trouble is it is up to each individual or organization that uses 
converted Olson VTIMEZONEs to do that themselves, and each could choose to 
use their own format for the ids etc.

> As others have mentioned, we have discussed in the past sticking all of
> this information in the DNS and elsewhere to make it interactively
> retrievable.  One of the other nice things about the way things are is
> that iCalendar objects are intended to be self-consistent requiring no
> additional lookups.  This has some drawbacks, obviously, one of which is
> that it makes for additional hair in server implementations.
>
> These problems are not unsolvable, but will have to wait for another day.

Agreed - this is a post-calsify effort. But it is one that is important, I 
believe.

-- 
Cyrus Daboo

To: [email-masked]
From: [email-masked]
Date: Wed, 07 Mar 2007 10:50:02 -0500
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-2446bis-03.txt 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: iCalendar Transport-Independent Interoperability Protocol (iTIP)
	Author(s)	: C. Daboo
	Filename	: draft-ietf-calsify-2446bis-03.txt
	Pages		: 121
	Date		: 2007-3-7
	
This document specifies a protocol using the iCalendar object
   specification to provide scheduling interoperability between
   different calendar systems.  This is done without reference to a
   specific transport protocol so as to allow multiple methods of
   communication between systems.  Subsequent documents will define
   profiles of this protocol using specific interoperable methods of
   communications between systems.
   iTIP complements the iCalendar object specification by adding
   semantics for group scheduling methods commonly available in current
   calendar systems.  These scheduling methods permit two or more
   calendar systems to perform transactions such as publish, schedule,
   reschedule, respond to scheduling requests, negotiation of changes or
   cancel.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-calsify-2446bis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-2446bis-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-2446bis-03.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-calsify-2446bis-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 4ee9155f2224d7578012dfcf57040542
X-Spam-Score-Summary: 2, 0, 0, 68b26f9a35d5437e, 42f367296d8970cb, [email-masked], , RULES_HIT:355:379:481:539:540:541:542:543:567:599:601:946:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1538:1568:1587:1593:1594:1711:1714:1730:1747:1766:1792:2073:2075:2078:2198:2199:2393:2559:2562:2828:3027:3865:3866:3867:3869:3870:3871:3874:4250:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Eliot Lear" <[email-masked]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Date: Wed, 7 Mar 2007 15:47:04 -0000
Cc: [email-masked]

> Putting aside the fact that we are no longer entertaining changes =
beyond=20
> the scope of changes made in response to closing open issues,=20

So are we at least registering these ideas for discussion/action later =
rather than ignoring them as not on the "blessed list of open issues"?  =
Again I can appreciate that dropping VTIMEZONE is a fairly major change, =
but surely restricting FREQ to yearly isn't so controversial we don't =
have the bandwidth to agree on that now?

Date: Wed, 07 Mar 2007 15:26:04 +0100
From: Eliot Lear <[email-masked]>
To: George Sexton <[email-masked]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Cc: [email-masked]

Putting aside the fact that we are no longer entertaining changes beyond 
the scope of changes made in response to closing open issues, I can 
think of one reason why the Olson database itself is insufficient: it's 
not versioned.  You can't simply refer to America/Los_Angeles and 
understand what people meant.  Was it the old definition that had DST 
starting a few weeks from now or the new version where it starts in a 
few days?

As others have mentioned, we have discussed in the past sticking all of 
this information in the DNS and elsewhere to make it interactively 
retrievable.  One of the other nice things about the way things are is 
that iCalendar objects are intended to be self-consistent requiring no 
additional lookups.  This has some drawbacks, obviously, one of which is 
that it makes for additional hair in server implementations.

These problems are not unsolvable, but will have to wait for another day.

Eliot

Date: Tue, 6 Mar 2007 23:17:38 -0800
From: "Mike Samuel" <[email-masked]>
To: "Nigel Swinson" <[email-masked]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Cc: [email-masked]
Reply-To: [email-masked]

There's a step short of deprecating VTIMEZONE that would help weather
events like the upcoming US timezone changes.

>From 4.2.19
   The presence of the SOLIDUS character (US-ASCII decimal 47) as a
   prefix, indicates that this TZID represents a unique ID in a globally
   defined time zone registry (when such registry is defined).

The spec could recommend an external TZID format like
//Olson/<olson-id> which would help ical generators pick names that
can be easily interpreted by others and explicitly permit calendaring
systems that recognize that format to substitute their own definition.

It would also make ical better as a persistence format.   You can
include you're VTIMEZONE definition, but if the TZID is
//Olson/America/Los_Angeles then a calendaring system that knows it
has a more up-to-date definition of Los Angeles time could feel free
to substitute it.

mike

On 06/03/07, Nigel Swinson <[email-masked]> wrote:
> > Like:
> >
> > <http://dialspace.dial.pipex.com/prod/dialspace/town/pipexdsl/s/asbm26/vzic/>
> >
> > which I believe a lot of people already use? I think there are some other
> > tools that will do that too. A good reference is:
> >
> > <http://www.twinsun.com/tz/tz-link.htm>
> >
> > There has also been discussion of having a formal timezone registry with
> > IANA that could use Olson to generate a set of VTIMEZONE definitions that
> > everyone could then use. But that is out of scope for the calsify effort,
> > as is actually deprecating VTIMEZONE altogether (which would have a major
> > impact in terms of backwards compatibility).
>
> I agree with George.  But I suspected it would be too big a change to deprecate VTIMEZONE at this time hence chose a different tack.
>
> I consider my suggestion a lot less jarring, and still in the remit of calsify?  It's the specifying that FREQ must = YEARLY that I think has the biggest gains.
>
> Nigel
>
>

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 98380a6508946c8574edf11bd85f821e
X-Spam-Score-Summary: 50, 0, 0, cda0d20d666c7afb, 42f367296d8970cb, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:960:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1534:1540:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2393:2525:2560:2564:2612:2682:2685:2691:2693:2828:2857:2859:2902:2933:2937:2939:2942:2945:2947:2951:2954:3000:3022:3027:3352:3865:3866:3867:3868:3869:3870:3871:3872:3874:3934:3936:3938:3941:4037:4250:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "George Sexton" <[email-masked]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Date: Tue, 6 Mar 2007 23:51:32 -0000
Cc: [email-masked]

> Like:
>=20
> =
<http://dialspace.dial.pipex.com/prod/dialspace/town/pipexdsl/s/asbm26/vz=
ic/>
>=20
> which I believe a lot of people already use? I think there are some =
other=20
> tools that will do that too. A good reference is:
>=20
> <http://www.twinsun.com/tz/tz-link.htm>
>=20
> There has also been discussion of having a formal timezone registry =
with=20
> IANA that could use Olson to generate a set of VTIMEZONE definitions =
that=20
> everyone could then use. But that is out of scope for the calsify =
effort,=20
> as is actually deprecating VTIMEZONE altogether (which would have a =
major=20
> impact in terms of backwards compatibility).

I agree with George.  But I suspected it would be too big a change to =
deprecate VTIMEZONE at this time hence chose a different tack. =20

I consider my suggestion a lot less jarring, and still in the remit of =
calsify?  It's the specifying that FREQ must =3D YEARLY that I think has =
the biggest gains.

Nigel

Date: Tue, 06 Mar 2007 14:50:20 -0500
From: Cyrus Daboo <[email-masked]>
To: George Sexton <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] rrule in timezone components

Hi George,

--On March 6, 2007 12:34:50 PM -0700 George Sexton <[email-masked]> 
wrote:

> b)   Create a standardized C/ (or other programming language) that can
> read the Olson TZ database, and perform the conversion.

Like:

<http://dialspace.dial.pipex.com/prod/dialspace/town/pipexdsl/s/asbm26/vzic/>

which I believe a lot of people already use? I think there are some other 
tools that will do that too. A good reference is:

<http://www.twinsun.com/tz/tz-link.htm>

There has also been discussion of having a formal timezone registry with 
IANA that could use Olson to generate a set of VTIMEZONE definitions that 
everyone could then use. But that is out of scope for the calsify effort, 
as is actually deprecating VTIMEZONE altogether (which would have a major 
impact in terms of backwards compatibility).

-- 
Cyrus Daboo

Date: Tue, 06 Mar 2007 12:34:50 -0700
From: George Sexton <[email-masked]>
Organization: MH Software, Inc.
To: [email-masked]
Subject: Re: [Ietf-calsify] rrule in timezone components

Nigel Swinson wrote:
> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.6.5
>      MUST represent a unique time zone definition.  This is necessary
>      for some classes of events, such as airline flights, that start in
>      one time zone and end in another.
>

Speaking from a position of semi-safety, and knowing that I can't be 
burned at the stake for heresy in this may I ask a series of simple 
questions?

I know these questions are as silly as questioning the fact that the sun 
revolves around the earth, but please, bear with me.

1)   In order to write a really accurate VTIMEZONE record you need a 
source of information. The only really generic, solid source of this 
information that I'm aware of is the Olson Time Zone Database.

2)   The VTIMEZONE is in essence a series of rules, describing the 
shifts of the time zone. IOW, it's perhaps a slightly more structured 
rendition of the data in the Olson time zone database.

3)   Some programming languages (Like Java in particular), and most 
operating systems now use the Olson Time Zone DB as their reference 
source. Java can convert time from one TZ to another TZ, with no effort.

4)   VTIMEZONE is a unique thing, tied specifically to iCal, and not 
used by any other standard.

Given all of these things, why would it not make sense to:

a)   Deprecate VTIMEZONE and say that all VEVENT time zone references 
must reference an Olson TZ Definition. After all, to write a really 
decent VTIMEZONE entry you need to have this present anyway and be able 
to parse it.

b)   Create a standardized C/ (or other programming language) that can 
read the Olson TZ database, and perform the conversion.

The benefits of this would be that developers could use a standard set 
of library functions for time zone conversions rather than creating a 
custom implementation. This library could be shared with other 
applications and would achieve maturity and correctness very quickly.

So, my heretical question is why are you hanging on to VTIMEZONE 
records? They're archaic and honestly there are just better things out 
there now.

-- 
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL:   http://www.mhsoftware.com/

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: a5eb104e72bc0f0a910c6d0991e74a32
X-Spam-Score-Summary: 2, 0, 0, fbd99ed10e8a4641, 42f367296d8970cb, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:599:601:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1538:1587:1593:1594:1711:1714:1730:1747:1766:1792:2073:2075:2078:2393:2559:2562:2691:2828:3027:3351:3865:3866:3867:3868:3869:3870:3871:3874:4250:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Date: Tue, 6 Mar 2007 18:35:15 -0000
Cc: [email-masked]

> I believe the original intent of that was to describe the case of an event 
> where the DTSTART and DTEND used different TZIDs. A single event 
> representing travel between locations with different timezones is one 
> example (though we can debate about the utility of using DTEND+different 
> TZID, vs DURATION). Your example of different events in different 
> timezones is also valid.
>
> I actually suggest removing the "This is necessary..." sentence 
> altogether, as we state further down:

I'd be happy with that too.  :o)

Nigel

Date: Tue, 06 Mar 2007 12:45:23 -0500
From: Cyrus Daboo <[email-masked]>
To: Nigel Swinson <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] rrule in timezone components

Hi Nigel,

--On March 6, 2007 4:57:01 PM +0000 Nigel Swinson 
<[email-masked]> wrote:

> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.6.5
>       MUST represent a unique time zone definition.  This is necessary
>       for some classes of events, such as airline flights, that start in
>       one time zone and end in another.
>
> The above seems a bit silly.  Planes travel WRT to UTC, or perhaps best
> take off WRT to local time.  If the US changes it's TZ definition does
> that mean the flight gets longer by 1 hour?  Probably more relevant to
> say:
>
>       MUST represent a unique time zone definition.  This is necessary
> -      for some classes of events, such as airline flights, that start in
> -      one time zone and end in another.
> +      for some classes of events, such as a tour which has events in
> +      more than one timezone.

I believe the original intent of that was to describe the case of an event 
where the DTSTART and DTEND used different TZIDs. A single event 
representing travel between locations with different timezones is one 
example (though we can debate about the utility of using DTEND+different 
TZID, vs DURATION). Your example of different events in different timezones 
is also valid.

I actually suggest removing the "This is necessary..." sentence altogether, 
as we state further down:

> An individual "VTIMEZONE" calendar component MUST be specified for
>       each unique "TZID" parameter value specified in the iCalendar
>       object.

Which I think adequately describes the constraint.

-- 
Cyrus Daboo

X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 8047113ce6464ba2fb6544b237384d2b
X-Spam-Score-Summary: 2, 0, 0, 3e6761cbf8309b3b, 4c409de4df48254b, [email-masked], , RULES_HIT:355:379:539:540:541:542:543:567:945:967:973:988:989:1155:1156:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1543:1587:1593:1594:1711:1730:1747:1766:1792:2073:2075:2078:2194:2198:2199:2200:2379:2393:2525:2559:2563:2682:2685:2693:2828:2857:2859:2894:2933:2937:2939:2942:2945:2947:2951:2954:3022:3355:3636:3770:3865:3866:3867:3868:3869:3870:3871:3872:3874:3934:3936:3938:3941:4250:4321:4421:4605:5007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none
X-Spam-Score-rbl_summary: none
X-Spam-Score-Phishing_status: no
From: "Nigel Swinson" <[email-masked]>
To: <[email-masked]>
Date: Tue, 6 Mar 2007 16:57:01 -0000
Subject: [Ietf-calsify] rrule in timezone components

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.6.5
      MUST represent a unique time zone definition.  This is necessary
      for some classes of events, such as airline flights, that start in
      one time zone and end in another.

The above seems a bit silly.  Planes travel WRT to UTC, or perhaps best take 
off WRT to local time.  If the US changes it's TZ definition does that mean 
the flight gets longer by 1 hour?  Probably more relevant to say:

      MUST represent a unique time zone definition.  This is necessary
-      for some classes of events, such as airline flights, that start in
-      one time zone and end in another.
+      for some classes of events, such as a tour which has events in
+      more than one timezone.

But what I really came here to say was, consider:

        BEGIN:VTIMEZONE
        TZID:Fictitious--with ridiculous rrule
        BEGIN:STANDARD
        DTSTART:19671029T020000
        RRULE:FREQ=HOURLY;INTERVAL=2
        TZOFFSETFROM:-0400
        TZOFFSETTO:-0500
        END:STANDARD
        BEGIN:DAYLIGHT
        etc
        END:DAYLIGHT
        END:VTIMEZONE

We are also told that DTSTART MUST be a local time. If DTSTART is a local 
time, then normally to decode an hourly/minutely/secondly recurring rules, 
we need to know what to do about timezone shifts.  But that's exactly what 
we are defining.  Not only does this seem messy to me, but I also think 
mallicious recurrence rules warrant mention in the security section as they 
could add considerable cpu/memory burdens on some implementations.

Surely we should really use the DATE from DTSTART and the RRULE to establing 
the DATE of the recurrence, with the intention being that there be only one 
date in the recurrence set per year, and then use the TIME from the 
DTSTART-OFFSETFROM to build the DATE-TIME of the point in UTC at which we 
apply the new offset.  I'd like to suggest that we add this:

      The "RRULE" property defines the recurrence rule for the onset of
      the observance defined by this time zone sub-component.  Some
      specific requirements for the usage of "RRULE" for this purpose
      include:

      *  If observance is known to have an effective end date, the
         "UNTIL" recurrence rule parameter MUST be used to specify the
         last valid onset of this observance (i.e., the UNTIL date-time
         will be equal to the last instance generated by the recurrence
         pattern).  It MUST be specified in UTC time.

      *  The "DTSTART" and the "TZOFFSETFROM" properties MUST be used
         when generating the onset date-time values (instances) from the
         "RRULE".

+      *  If present, the "RRULE" MUST have a "FREQ" of "YEARLY" and MUST
+          NOT use "BYHOUR", "BYMINUTE", "BYSECOND".  The "RRULE"
+          SHOULD define a recurrence set that includes a single instance 
per year.
+          Where the "RRULE" specifies more than one instance per year, 
implementations
+          SHOULD ignore all but the first instance.

Nigel 

Date: Tue, 06 Mar 2007 16:47:56 +0200
From: Aki Niemi <[email-masked]>
To: ext Jay Batson <[email-masked]>
Subject: Re: [Ietf-calsify] Issues with Security / Spoofing section
Cc: Calsify WG <[email-masked]>

Hi Jay,

I punched this issue in as #80 in the tracker.

I suspect we're in for an even more extensive revamp of the Security
Considerations section, and your proposal seems like a good start.

Specifically, I think the section should ultimately talk about exactly
what's in scope of RFC2445bis, and more importantly what's *not* in
scope. I would assume transport security for instance only really
becomes an issue in iTIP/iMIP.

Any volunteers?

Cheers,
Aki

ext Jay Batson wrote:
> I was reviewing the latest draft, and finally (after not paying
> sufficient attention previously) noted that the Security section has a
> real problem.
> 
> The SPOOFING section is trouble waiting to happen.  Currently, that
> section says:
> 
> "... the "Organizer" is the only person authorized to make changes to an
> existing "VEVENT", "VTODO", "VJOURNAL" calendar component...."
> 
> (I'm going to restrict my comments to the application of that logic to
> VTODO and VJOURNAL components, because I think VEVENT may have different
> needs.)
> 
> ASSERTION:
> In general, the current language isn't practical in real life.  When
> VTODOs (and/or VJOURNALs) are used in group task coordination
> applications, it is highly likely that other persons besides the
> "Organizer" will need to be able to modify these components after they
> are created.  Thus, the current restriction is not practical and should
> not remain.
> 
> ILLUSTRATIVE BACKGROUND:
> Assume:
> - a collaborative application that stores tasks assigned to people in a
> project team;
> - tasks are stored as VTODO entries in a project.ics file (and the .ics
> file is regularly "synchronized" among team members);
> - all users in a project have access to all the project information
> (e.g. all have read-rights to the .ics file)
> - assume the software implements the current SPOOFING constraint -- that
> only the "Organizer" (task assignor) can modify the task details.
> (This is a "generalized" description of what our software does. 
> Implementation is different, but the effect is the same.)
> 
> Our largest single feature request from users -- by a factor of at least
> 3 over others -- is that users want the "Attendees" to be able to modify
> the VTODO entry.  People often need to modify task descriptions to
> conform with changed requirements, add / modify / change assignees (e.g.
> remove somebody who left the company/team and whose PC/software-account
> you no longer have access to), change dates when all agree on the need
> for change (but the original assignor isn't present to make the change),
> etc.
> 
> Note:  In fact, most of our customers want *any* person in the project
> team to be able to modify the task details for *any* task in the project
> -- not just the "Attendees" of a project.  For instance, if Sally
> assigned task A to herself, but went to the hospital to have a baby this
> morning, and Jim is going to assume responsibility for it, Jim must have
> the ability to change the "Attendee" - and probably the due-date, too.
> 
> In real life, teams work together; it's not a strict hierarchy of
> assignor/assignee, and task detailss change constantly.  Therefore, the
> current SPOOFING restriction is simply not practical if iCalendar VTODOs
> are to be used in anything else than a single-user software application.
> 
> PROPOSAL:
> 2445 should simply be silent about who can, or cannot modify (at least)
> VTODO and VJOURNAL components.  Access control is outside the scope of
> the definition of task data.  If some application wants to decide to
> only grant write capabilities to the Organizer it can.  If another
> application wants to maintain ACLs outside the scope of the calendar
> object, it can.  If others want to add x-props to include ACL guidance
> (which could be difficult to enforce if there is no secure transit), it
> can.  It's not the role of 2445 to specify ACLs; it is only its role to
> define the listed components in *this* case (of tasks/journals).
> 
> I propose the SPOOFING section be rewritten to indicate that the RFC is
> providing no access control for these two components, identify the risks
> of uncontrolled access, and leave security implementation up to some
> externality, e.g. iTIP.  Here is some proposed text (though I suspect
> this needs LOTS of discussion before it goes in):
> 
> NEW LANGUAGE:
> -----------
> SPOOFING:
> In this memo, there is no restriction on who is authorized to make
> changes to a "VTODO" or "VJOURNAL" calendar component entry.  Some
> applications using these components in a collaborative setting may
> intentionally desire to provide "Attendees" the ability to update this
> data based on ongoing actual activities, and communicate these changes
> to the "Attendees" as part of the collaborative process.  Malicious
> behavior in this context can of course result in data changes or loss
> that is unexpected by the "Attendees".  This is an inherent risk in any
> situation where all "Attendees" are collaborating on "VTODO" or
> "VJOURNAL" entries, and it is up to the individuals, or to some other
> controlling technology, such as iTIP, document versioning, or other, to
> provide any desired control over the ability of "Attendees" to make
> changes in these components.
> -----------
> 
> Note again that I cannot speak to the implications of changing the
> SPOOFING section relative to VEVENT components.  There must of course be
> SOME description of how to handle VEVENT components.  My language
> proposal above does NOT address this.  Somebody more versed in the
> implications of calendaring must come up with it.
> 
> Comments?
> -jb
> 
> -------------
> Jay Batson
> [email-masked]
> +1-978-824-0111 (w)
> +1-978-758-1599 (m)
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 

Date: Tue, 06 Mar 2007 15:59:29 +0200
From: Aki Niemi <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Draft agenda for IETF68

Dear WG,

A draft agenda for our upcoming IETF68 meeting is out:

http://www3.ietf.org/proceedings/07mar/agenda/calsify.txt

Please send all comments to the chairs, if you have any.

Cheers,
Aki

Date: Tue, 06 Mar 2007 08:40:59 -0500
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-06.txt

Folks,

I have uploaded the .html and .changes.html versions of the draft
on the IETF Tools web site at the following locations:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-06.html

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-06.changes.html

Cheers,
Bernard

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.
> 
> 	Title		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
> 	Author(s)	: B. Desruisseaux
> 	Filename	: draft-ietf-calsify-rfc2445bis-06.txt
> 	Pages		: 176
> 	Date		: 2007-3-5
> 	
> This document defines a MIME media type for representing and
>    exchanging calendaring and scheduling information such as events, to-
>    dos, journal entries and free/busy information.  The definition of
>    the text/calendar media type, known as iCalendar, is independent of
>    any particular calendar service or protocol.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-06.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-ietf-calsify-rfc2445bis-06.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-06.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 

To: [email-masked]
From: [email-masked]
Date: Mon, 05 Mar 2007 15:50:02 -0500
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-06.txt 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-06.txt
	Pages		: 176
	Date		: 2007-3-5
	
This document defines a MIME media type for representing and
   exchanging calendaring and scheduling information such as events, to-
   dos, journal entries and free/busy information.  The definition of
   the text/calendar media type, known as iCalendar, is independent of
   any particular calendar service or protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-06.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-calsify-rfc2445bis-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-rfc2445bis-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-calsify-rfc2445bis-06.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

From: Jonathan Lennox <[email-masked]>
Date: Thu, 1 Mar 2007 14:49:47 -0500
To: [email-masked]
Subject: Re: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities

On Thursday, March 1 2007, "Jeffrey Harris" wrote to "[email-masked]" saying:

> Hi Jonathan,
> 
> > The third bullet point here is the potentially controversial one, and would
> > be an incompatible change with 2445.  Does anyone currently generate
> > DURATION values of the form "P1DT8H"?
> 
> I'm not following why we'd disallow "P1DT8H".  What's wrong with this
> heuristic for interpreting such a value: Add the nominal time first,
> then add the accurate time delta?

So long as the rule is clearly defined as "add nominal duration first, then
accurate duration", that's okay.  Is this additional complexity actually
useful, though?

In particular, this might make my proposed resolution of issue 70 more
difficult to implement.  For a calendar generator, it's not sufficient to
say "alert the user if the end time of this event, calculated naively, would
be nonexistent or ambiguous".  Instead, it would have to ask "does the
process of calculating the nominal part of this event's duration hit a
non-existent or ambiguous time?" which is perhaps a more complex question to
answer.

That is to say, a calendar generator has to realize that not only is this a
problem:

DTSTART;TZID=America/New_York:20070310PT023000
DURATION:P1D

(which would last from 2007-03-10 02:30:00 EST to *"2007-03-11 02:30:00")

but also this:

DTSTART;TZID=America/New_York:20070310PT023000
DURATION:P1DT8H

(which you might naively calculate as lasting from 2007-03-10 02:30:00 EST
to either 2007-03-11 10:30:00 EDT or 2007-03-11 11:30:00 EDT, and not
realize that something's wrong). 

-- 
Jonathan Lennox
[email-masked]

From: Jonathan Lennox <[email-masked]>
Date: Thu, 1 Mar 2007 14:42:42 -0500
To: <[email-masked]>
Subject: Re-wording of issue 27 consensus (Re: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities)

Following today's jabber discussion, I'd also suggest clarifing issue 27's
consensus, in the new terminology, to say that DTEND - DTSTART is always an
accurate duration, not a nominal duration.  Thus, issue 27's example 2

  DTSTART;TZID=America/Montreal:20070311T000000
  DTEND;TZID=America/Montreal:20070312T000000
  RRULE:FREQ=DAILY;COUNT=2

is exactly equivalent to

  DTSTART;TZID=America/Montreal:20070311T000000
  DURATION:PT23H
  RRULE:FREQ=DAILY;COUNT=2

because 2007-03-12 00:00:00 EDT is 23 elapsed hours after 2007-03-11
00:00:00 EST in America/Montreal.

I'm pretty sure this is what the consensus on issue 27 was, but I think this
makes things clearer and is easier to understand.

Does this seem reasonable?

On Thursday, March 1 2007, "Jonathan Lennox" wrote to "<[email-masked]>" saying:

> For issue 8 (P1D vs. PT24H):
> 
> ISO 8601 defines D and W durations (and also larger ones that iCalendar
> doesn't use) as being "nominal" durations, while the smaller periods are
> "accurate" durations".  (See the jabber logs for the full quote from 8601).
> 
> To align with 8601 and remove ambiguity, then, we propose:
> * D and W durations are nominal, i.e. refer to the same wall-clock time n
> days or weeks later.
> * H, M, and D durations are accurate, i.e. refer to an actual number of
> elapsed hours, minutes, or seconds.
> * We forbid DURATION values that mix nominal durations (W [already
> forbidden] and D) with accurate durations (H, M, and S).

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

From: Jonathan Lennox <[email-masked]>
Date: Thu, 1 Mar 2007 14:39:22 -0500
To: <[email-masked]>
Subject: Proposed resolution of issue 70 (was Re: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities)

Moving forward a bit while I have it in mind, I think the resolutions of
issues 68 and 69 from today's Jabber can be generalized pretty easily to
issue 70 (ambiguous end times).

Given our resolution of issue 8, ambiguous event end times can only occur
because of nominal durations (D and W), not accurate durations (H, M, and
S).  Thus, the problematic cases are:

DTSTART;TZID=America/New_York:20070310PT023000
DURATION:P1D

and

DTSTART;TZID=America/New_York:20070309PT023000
DURATION:P1D
RRULE:FREQ=DAILY;COUNT=2

remembering that in the U.S.'s new DST rules, 2007-03-11 01:59:59 EST is
followed by 2007-03-11 03:00:00 EDT.

My inclination is to follow the same solution for DTSTART+nominal duration
as we followed for DATE-TIME.  I.e., an event end time from an explicit
DTSTART+nominal duration that hits a "bad" time is undefined, and MUST NOT
be generated (generalization of 68); an event end time from a recurrence
start+nominal duration that hits a "bad" time is unspecified, and the
recurrence instance SHOULD be overridden with an EXDATE (generalization of
69).

Does this seem reasonable?

On Thursday, March 1 2007, "Jonathan Lennox" wrote to "<[email-masked]>" saying:

> For issue 68 (ambiguous or nonexistent DATE-TIME values):
> 
> Calendar generators MUST NOT generate DATE-TIME values that are non-existent
> (occurring in a time zone's leap-forward period) or ambiguous (occurring
> more than once, due to a time zone's leap-backward period) in the time zone
> in which they occur, except in VTIMEZONE or EXDATE components.  If such
> values appear in an iCalendar document, the meaning is undefined.  Calendar
> generators SHOULD alert the user if such a time is requested, and SHOULD
> instead represent the DATE-TIME values in a different time zone, or UTC,
> where the instant is well-defined.
> 
> (This is "undefined" in the strict standardese sense, i.e. "demons can fly
> out your nose."  A more likely undefined behavior would be something like
> "java.util.GregorianCalendar.computeTime() throws an uncaught exception,
> terminating your program.")
> 
> 
> For issue 69 (discontinuities for recurring event start times):
> 
> If a time generated by an RRULE falls on an ambiguous or non-existent time,
> the resulting event occurs exactly once (and thus counts as one recurrence
> instance for the purposes of COUNT and BYSETPOS).  However, the actual time
> at which the event occurs is unspecified.  [Note: do we need some guidance
> bounding the range of valid times here, for the sake of UNTIL below?]
> 
> Calendar generators SHOULD alert the user in this case.  Once the user
> provides a desired interpretation, calendar generators SHOULD provide EXDATE
> entries matching the ambiguous or non-existent recurrence instances, with
> corresponding RDATE entries in UTC or a non-ambiguous time zone indicating
> the actual desired occurrence time of the recurrence instance.  (Note
> however that this is not possible for perpetual recurrences, which might
> have an unbounded number of ambiguous recurrence instances.)

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

Date: Thu, 01 Mar 2007 14:32:59 -0500
From: Cyrus Daboo <[email-masked]>
To: Jonathan Lennox <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Resolutions of issues 8,	68 and 69: DST discontinuities

Hi Jonathan,

--On March 1, 2007 12:27:50 PM -0500 Jonathan Lennox 
<[email-masked]> wrote:

> The third bullet point here is the potentially controversial one, and
> would be an incompatible change with 2445.  Does anyone currently generate
> DURATION values of the form "P1DT8H"?
>

Yes, Mulberry will, for whatever its worth. In fact it explicitly allows 
users to set Durations for events using a UI that exposed fields for Days, 
Hours, Minutes and Seconds (or just Weeks). Note that I wrote the iCalendar 
library to manipulate dates as separate components for years, months, days, 
hours, minutes, seconds - i.e. handling "nominal" durations is easy.

I think Jeffrey's comment is right - there is nothing wrong with mixing 
nominal and accurate in this case.

-- 
Cyrus Daboo

Date: Thu, 01 Mar 2007 10:11:46 -0800
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities

Hi Jonathan,

> The third bullet point here is the potentially controversial one, and would
> be an incompatible change with 2445.  Does anyone currently generate
> DURATION values of the form "P1DT8H"?

Chandler doesn't currently serialize durations, but internally we store
durations and I've been trying to move things over to serializing
DURATION instead of DTEND.

I'm not following why we'd disallow "P1DT8H".  What's wrong with this
heuristic for interpreting such a value: Add the nominal time first,
then add the accurate time delta?

Sincerely,
Jeffrey

From: Jonathan Lennox <[email-masked]>
Date: Thu, 1 Mar 2007 12:27:50 -0500
To: <[email-masked]>
Subject: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities

Following today's Jabber chat, Bernard asked me to follow up on the
resolutions of the DST discontinuity issues we discussed.

This is sort of a mixture of informal discussion and proposed text; sorry
about that.

For issue 8 (P1D vs. PT24H):

ISO 8601 defines D and W durations (and also larger ones that iCalendar
doesn't use) as being "nominal" durations, while the smaller periods are
"accurate" durations".  (See the jabber logs for the full quote from 8601).

To align with 8601 and remove ambiguity, then, we propose:
* D and W durations are nominal, i.e. refer to the same wall-clock time n
days or weeks later.
* H, M, and D durations are accurate, i.e. refer to an actual number of
elapsed hours, minutes, or seconds.
* We forbid DURATION values that mix nominal durations (W [already
forbidden] and D) with accurate durations (H, M, and S).

The third bullet point here is the potentially controversial one, and would
be an incompatible change with 2445.  Does anyone currently generate
DURATION values of the form "P1DT8H"?

For issue 68 (ambiguous or nonexistent DATE-TIME values):

Calendar generators MUST NOT generate DATE-TIME values that are non-existent
(occurring in a time zone's leap-forward period) or ambiguous (occurring
more than once, due to a time zone's leap-backward period) in the time zone
in which they occur, except in VTIMEZONE or EXDATE components.  If such
values appear in an iCalendar document, the meaning is undefined.  Calendar
generators SHOULD alert the user if such a time is requested, and SHOULD
instead represent the DATE-TIME values in a different time zone, or UTC,
where the instant is well-defined.

(This is "undefined" in the strict standardese sense, i.e. "demons can fly
out your nose."  A more likely undefined behavior would be something like
"java.util.GregorianCalendar.computeTime() throws an uncaught exception,
terminating your program.")

For issue 69 (discontinuities for recurring event start times):

If a time generated by an RRULE falls on an ambiguous or non-existent time,
the resulting event occurs exactly once (and thus counts as one recurrence
instance for the purposes of COUNT and BYSETPOS).  However, the actual time
at which the event occurs is unspecified.  [Note: do we need some guidance
bounding the range of valid times here, for the sake of UNTIL below?]

Calendar generators SHOULD alert the user in this case.  Once the user
provides a desired interpretation, calendar generators SHOULD provide EXDATE
entries matching the ambiguous or non-existent recurrence instances, with
corresponding RDATE entries in UTC or a non-ambiguous time zone indicating
the actual desired occurrence time of the recurrence instance.  (Note
however that this is not possible for perpetual recurrences, which might
have an unbounded number of ambiguous recurrence instances.)

If the last occurrence of a recurrence bounded with UNTIL falls at an
ambiguous or non-existent time, the UNTIL value (which MUST be in UTC)
SHOULD be specified to be after the range of ambiguous or non-existent
times, so the final occurrence definitely occurs no matter what time the
interpreter of the iCalendar document chooses for the event.

Comments?

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

Date: Thu, 01 Mar 2007 16:01:37 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] jabber chat starts now!

[email-masked]

Date: Thu, 01 Mar 2007 13:26:45 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] More references to 2446?
Cc: [email-masked]

Cyrus Daboo wrote:

> Proposals:
>
> 1) Add the following text somewhere in the description of the 
> ORGANIZER property:
>
> The exact behavior and interpretation of the ORGANIZER property and 
> its related parameters is defined in iTIP [2446bis]. In particular 
> note that the organizer is not implicitly considered a participant in 
> an event or to do, and therefore an explicit ATTENDEE property may 
> need to be added for the organizer.
>
> 2) Same thing for the ATTENDEE property:
>
> The exact behavior and interpretation of the ATTENDEE property and its 
> related parameters is defined in iTIP [2446bis]. In particular note 
> that the organizer is not implicitly considered a participant in an 
> event or to do, and therefore an explicit ATTENDEE property may need 
> to be added for the organizer.
>
> I believe these are just editorial changes.

+1.