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

[reinhold at kainhofer.com (Reinhold Kainhofer)]

Am Freitag, 30. M?rz 2007 schrieben Sie:
> 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.

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

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], 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/

Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C386B7F586 for <[e-mail]>; Fri, 30 Mar 2007 09:33:45 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F2E7F142272 for <[e-mail]>; Fri, 30 Mar 2007 09:32:50 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11660-08 for <[e-mail]>; Fri, 30 Mar 2007 08:32:48 -0800 (PST)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2121D142270 for <[e-mail]>; Fri, 30 Mar 2007 09:32:47 -0700 (PDT)
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2UGWftv026085 for <[e-mail]>; Fri, 30 Mar 2007 18:32:45 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: CALSIFY Mailinglist <[e-mail]>
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend =?iso-8859-1?q?in=09floating=09time?=
User-Agent: KMail/1.9.5 + Features
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Disposition: inline
X-UID: 4393
X-Length: 2666
Date: Fri, 30 Mar 2007 18:32:40 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 16:33:46 -0000

Am Freitag, 30. M=E4rz 2007 schrieben Sie:
> 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.

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: [e-mail], 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/


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 68DE17F586 for <[e-mail]>; Fri, 30 Mar 2007 07:52:05 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 97E5F142273 for <[e-mail]>; Fri, 30 Mar 2007 07:51:10 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09558-02 for <[e-mail]>; Fri, 30 Mar 2007 06:51:10 -0800 (PST)
Received: from mulberrymail.com (static-151-201-20-152.pitbpa.east.verizon.net [151.201.20.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EC55614225E for <[e-mail]>; Fri, 30 Mar 2007 07:51:09 -0700 (PDT)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2UEopGh003857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2007 09:50:57 -0500
Date: Fri, 30 Mar 2007 10:50:45 -0400
From: Cyrus Daboo <[e-mail]>
To: Reinhold Kainhofer <[e-mail]>, CALSIFY Mailinglist <[e-mail]>
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating	time
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 14:52:05 -0000

Hi Reinhold,

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

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1DE547F60B for <[e-mail]>; Fri, 30 Mar 2007 07:20:58 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 40F9614228B for <[e-mail]>; Fri, 30 Mar 2007 07:20:03 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09841-03 for <[e-mail]>; Fri, 30 Mar 2007 06:20:00 -0800 (PST)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6FB06142288 for <[e-mail]>; Fri, 30 Mar 2007 07:20:00 -0700 (PDT)
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2UEJugV003829 for <[e-mail]>; Fri, 30 Mar 2007 16:19:58 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: Vienna University of Technology
To: CALSIFY Mailinglist <[e-mail]>
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
User-Agent: KMail/1.9.6
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Disposition: inline
X-UID: 4385
X-Length: 2278
Date: Fri, 30 Mar 2007 16:19:55 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 14:20:58 -0000

Am Freitag, 30. M=E4rz 2007 schrieb Mike Samuel:
> If I understand the questions, Arnaud is not asking about different
> value types,=20

Nope, but Petr was.

> but about start and ends that are both date-times but=20
> where one is in a timezone and one is floating, so:
>
>   DTSTART;TZID=3DAmerica/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.

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: [e-mail], 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/


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 088D07F53D for <[e-mail]>; Fri, 30 Mar 2007 07:06:03 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3802014228B for <[e-mail]>; Fri, 30 Mar 2007 07:05:08 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09796-03 for <[e-mail]>; Fri, 30 Mar 2007 06:05:07 -0800 (PST)
Received: from mulberrymail.com (static-151-201-20-152.pitbpa.east.verizon.net [151.201.20.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 92856142288 for <[e-mail]>; Fri, 30 Mar 2007 07:05:07 -0700 (PDT)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2UE54qo003604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 30 Mar 2007 09:05:05 -0500
Date: Fri, 30 Mar 2007 10:04:59 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] iTIP and overridden instances
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 14:06:03 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8F9727F586 for <[e-mail]>; Fri, 30 Mar 2007 06:50:33 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C00E5142279 for <[e-mail]>; Fri, 30 Mar 2007 06:49:38 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08634-04 for <[e-mail]>; Fri, 30 Mar 2007 05:49:38 -0800 (PST)
Received: from mulberrymail.com (static-151-201-20-152.pitbpa.east.verizon.net [151.201.20.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1684C142276 for <[e-mail]>; Fri, 30 Mar 2007 06:49:37 -0700 (PDT)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2UDnNZ6003529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2007 08:49:26 -0500
Date: Fri, 30 Mar 2007 09:49:18 -0400
From: Cyrus Daboo <[e-mail]>
To: Arnaud Quillaud <[e-mail]>, [e-mail], Reinhold Kainhofer <[e-mail]>
Subject: RE: [Ietf-calsify] dtstart in tz or utc time and dtend in	floating	time
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 13:50:33 -0000

Hi Arnaud,

--On March 30, 2007 9:35:25 AM +0200 Arnaud Quillaud 
<[e-mail]> 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.
>
> Same for CalDAV calendar-query where you can choose in which timezone you
> want to represent floating times.

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B08867F586 for <[e-mail]>; Fri, 30 Mar 2007 06:45:23 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DDE60142279 for <[e-mail]>; Fri, 30 Mar 2007 06:44:28 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08800-05 for <[e-mail]>; Fri, 30 Mar 2007 05:44:28 -0800 (PST)
Received: from mulberrymail.com (static-151-201-20-152.pitbpa.east.verizon.net [151.201.20.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3FFBC142276 for <[e-mail]>; Fri, 30 Mar 2007 06:44:25 -0700 (PDT)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2UDi7x9003504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2007 08:44:10 -0500
Date: Fri, 30 Mar 2007 09:44:02 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail], Reinhold Kainhofer <[e-mail]>
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating	time
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 13:45:23 -0000

Hi Mike,

--On March 29, 2007 4:23:01 PM -0700 Mike Samuel <[e-mail]> 
wrote:

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

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EA6507F582 for <[e-mail]>; Fri, 30 Mar 2007 00:34:14 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 28DC2142295 for <[e-mail]>; Fri, 30 Mar 2007 00:33:20 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05463-10 for <[e-mail]>; Thu, 29 Mar 2007 23:33:19 -0800 (PST)
Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 13F4E142293 for <[e-mail]>; Fri, 30 Mar 2007 00:33:15 -0700 (PDT)
Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2U7XEKf005388 for <[e-mail]>; Fri, 30 Mar 2007 07:33:14 GMT
Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Fri, 30 Mar 2007 08:33:14 +0100 (BST)
Received: from vpn-129-150-116-178.UK.Sun.COM ([129.150.116.178]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) with ESMTPSA id <[e-mail]>; Fri, 30 Mar 2007 08:33:14 +0100 (BST)
Content-return: prohibited
Date: Fri, 30 Mar 2007 09:35:25 +0200
From: Arnaud Quillaud <[e-mail]>
Subject: RE: [Ietf-calsify] dtstart in tz or utc time and dtend in floating	time
In-reply-to: <[e-mail]>
Sender: [e-mail]
To: [e-mail], Reinhold Kainhofer <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Outlook Connector 7.2.309.0
Content-type: TEXT/PLAIN; CHARSET=Windows-1252
Content-transfer-encoding: QUOTED-PRINTABLE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.8 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2007 07:34:15 -0000

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of=20
> Mike Samuel
> Sent: Friday, March 30, 2007 1:23 AM
> To: Reinhold Kainhofer
> Cc: [e-mail]
> Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in
> floating time
>=20
>=20
> 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:
>=20
>   DTSTART;TZID=3DAmerica/Los_Angeles:20060329T161900
>   DTEND:20060329T164900
>=20
> 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 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
> mike
>=20
>=20
>=20
> On 29/03/07, Reinhold Kainhofer <[e-mail]> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 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
> > > > is FORM #1: DATE WITH LOCAL TIME (See
> > > >=20
> http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis
> /draft-ietf
> > > >-calsify-rfc2445bis-06.html#VALUE.DATE-TIME), DTEND=20
> should also be of the
> > > > same form.
> > >
> > > 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=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
> > 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: [e-mail], http://reinhold.kainhofer.com/
> >  * Financial and Actuarial Mathematics, TU Wien,=20
http://www.fam.tuwien.ac.at/
>  * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
>  * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGDDK4TqjEwhXvPN0RAjhPAKCkdCt53lYsK5XNAg6aeyO9jt4RAACfZY/E
> wxDHhSQwsTPP3RZOpzBQLDs=3D
> =3DIKwK
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
_______________________________________________
Ietf-calsify mailing list
[e-mail]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7A0107F685 for <[e-mail]>; Thu, 29 Mar 2007 16:23:59 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5F7E5142295 for <[e-mail]>; Thu, 29 Mar 2007 16:23:04 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26815-09 for <[e-mail]>; Thu, 29 Mar 2007 15:23:03 -0800 (PST)
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by laweleka.osafoundation.org (Postfix) with ESMTP id 436CD142290 for <[e-mail]>; Thu, 29 Mar 2007 16:23:03 -0700 (PDT)
Received: by mu-out-0910.google.com with SMTP id w9so319788mue for <[e-mail]>; Thu, 29 Mar 2007 16:23:02 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=meLcps1Nvk7TieAgi83Fs8VsMx+RwomixLOqo/gzFfPnzdBHrVxytyFF4uFyQQISmDvFkoNKfLyPRO/UtiyZfhJ/fPaPpowU80jZk15mjMy2rJnt3yQ076uYzi47dS9KMGMpnMUtB26Fft9k5J1nBLx0LkO8IUua2fct4A8SRKY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DxKaDAuIagX86QoqWZy3iayAhmkJAaNjL8n9Tq+038yGGMLoJVGhrUu596QdWf2TZhanqAu1Eviayxl+Y2zwPfRcGGqX+kA2ybOEF09yJ1+yL2vGXsuNssATd5vD7WEBV6Qv/wRDalBYmJescIk0MFhAdeOiDiWUUyS7pFlJusI=
Received: by 10.82.163.13 with SMTP id l13mr2554295bue.1175210581542; Thu, 29 Mar 2007 16:23:01 -0700 (PDT)
Received: by 10.82.157.8 with HTTP; Thu, 29 Mar 2007 16:23:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 29 Mar 2007 16:23:01 -0700
From: "Mike Samuel" <[e-mail]>
To: "Reinhold Kainhofer" <[e-mail]>
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=1.2 tagged_above=-50.0 required=4.0 tests=MISSING_SUBJECT
X-Spam-Level: *
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 23:24:01 -0000

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=3DAmerica/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 <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
> > > 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.
> >
> > 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!
>
> 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
> 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: [e-mail], 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/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGDDK4TqjEwhXvPN0RAjhPAKCkdCt53lYsK5XNAg6aeyO9jt4RAACfZY/E
> wxDHhSQwsTPP3RZOpzBQLDs=3D
> =3DIKwK
> -----END PGP SIGNATURE-----
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 035817F635 for <[e-mail]>; Thu, 29 Mar 2007 14:43:18 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2FDA4142293 for <[e-mail]>; Thu, 29 Mar 2007 14:42:23 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22785-10 for <[e-mail]>; Thu, 29 Mar 2007 13:42:20 -0800 (PST)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 52D1C142292 for <[e-mail]>; Thu, 29 Mar 2007 14:42:19 -0700 (PDT)
Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2TLgHYK031149 for <[e-mail]>; Thu, 29 Mar 2007 23:42:17 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
Date: Thu, 29 Mar 2007 23:42:14 +0200
User-Agent: KMail/1.9.6
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 21:43:19 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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: [e-mail], 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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGDDK4TqjEwhXvPN0RAjhPAKCkdCt53lYsK5XNAg6aeyO9jt4RAACfZY/E
wxDHhSQwsTPP3RZOpzBQLDs=
=IKwK
-----END PGP SIGNATURE-----


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1D14E7F66D for <[e-mail]>; Thu, 29 Mar 2007 14:09:59 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 420A6142295 for <[e-mail]>; Thu, 29 Mar 2007 14:09:04 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27352-03 for <[e-mail]>; Thu, 29 Mar 2007 13:09:00 -0800 (PST)
Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 77988142288 for <[e-mail]>; Thu, 29 Mar 2007 14:09:00 -0700 (PDT)
Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id l2TLAdxA027699 for <[e-mail]>; Thu, 29 Mar 2007 23:10:39 +0200
Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id l2TLAaFX027685 for [e-mail]; Thu, 29 Mar 2007 23:10:36 +0200
Date: Thu, 29 Mar 2007 23:10:36 +0200
From: Petr Tomasek <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-Homepage: http://www.etf.cuni.cz/~tomasek/
X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon
X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.3.1.46; VDF: 6.38.0.144; host: ebed.etf.cuni.cz)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=1.2 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: *
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 21:09:59 -0000

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

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>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C4AC27F631 for <[e-mail]>; Thu, 29 Mar 2007 09:15:13 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 00AE6142290 for <[e-mail]>; Thu, 29 Mar 2007 09:14:19 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23011-01 for <[e-mail]>; Thu, 29 Mar 2007 08:14:18 -0800 (PST)
Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id F1E4D142288 for <[e-mail]>; Thu, 29 Mar 2007 09:14:17 -0700 (PDT)
Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2TGEGq7005191 for <[e-mail]>; Thu, 29 Mar 2007 16:14:16 GMT
Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 29 Mar 2007 17:14:16 +0100 (BST)
Received: from vpn-129-150-116-199.UK.Sun.COM ([129.150.116.199]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) with ESMTPSA id <[e-mail]>; Thu, 29 Mar 2007 17:14:16 +0100 (BST)
Content-return: prohibited
Date: Thu, 29 Mar 2007 18:16:27 +0200
From: Arnaud Quillaud <[e-mail]>
Subject: RE: Issue 65: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
In-reply-to: <[e-mail]>
Sender: [e-mail]
To: Bernard Desruisseaux <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Outlook Connector 7.2.309.0
Content-type: TEXT/PLAIN; CHARSET=Windows-1252
Content-transfer-encoding: 7BIT
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.8 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 16:15:13 -0000

> -----Original Message-----
> From: Bernard Desruisseaux [mailto:[e-mail]]
> Sent: Thursday, March 29, 2007 4:59 PM
> To: Arnaud Quillaud
> Cc: [e-mail]
> Subject: Issue 65: Re: [Ietf-calsify] dtstart in tz or utc time and
> dtend in floating time
> 
> 
> [ 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).

Yes. I was talking only about the first case.

Thanks,

Arnaud Q
> 
> 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:
> > 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-Feb
ruary/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
> 
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B44AA7F527 for <[e-mail]>; Thu, 29 Mar 2007 08:00:28 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E002A142294 for <[e-mail]>; Thu, 29 Mar 2007 07:59:33 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21605-04 for <[e-mail]>; Thu, 29 Mar 2007 06:59:33 -0800 (PST)
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 58E89142292 for <[e-mail]>; Thu, 29 Mar 2007 07:59:33 -0700 (PDT)
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l2TExU0T006331; Thu, 29 Mar 2007 08:59:31 -0600
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2TCc9DD010105; Thu, 29 Mar 2007 08:59:29 -0600
Received: from dhcp-montreal-17fl-utilca-10-156-43-50.ca.oracle.com by acsmt351.oracle.com with ESMTP id 2572584811175180345; Thu, 29 Mar 2007 07:59:05 -0700
Message-ID: <[e-mail]>
Date: Thu, 29 Mar 2007 10:58:53 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Arnaud Quillaud <[e-mail]>
Subject: Issue 65: Re: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=1.7 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: *
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 15:00:28 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E9CE97F727 for <[e-mail]>; Thu, 29 Mar 2007 03:48:36 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 25641142282 for <[e-mail]>; Thu, 29 Mar 2007 03:47:42 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17673-09 for <[e-mail]>; Thu, 29 Mar 2007 02:47:37 -0800 (PST)
Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 54C6514227F for <[e-mail]>; Thu, 29 Mar 2007 03:47:37 -0700 (PDT)
Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2TAlZUH015771 for <[e-mail]>; Thu, 29 Mar 2007 10:47:36 GMT
Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Thu, 29 Mar 2007 11:47:35 +0100 (BST)
Received: from vpn-129-150-116-199.UK.Sun.COM ([129.150.116.199]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) with ESMTPSA id <[e-mail]> for [e-mail]; Thu, 29 Mar 2007 11:47:31 +0100 (BST)
Content-return: prohibited
Date: Thu, 29 Mar 2007 12:49:42 +0200
From: Arnaud Quillaud <[e-mail]>
Sender: [e-mail]
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Outlook Connector 7.2.309.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] dtstart in tz or utc time and dtend in floating time
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2007 10:48:37 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6C3057F57B for <[e-mail]>; Tue, 27 Mar 2007 14:25:54 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9F817142279 for <[e-mail]>; Tue, 27 Mar 2007 14:24:59 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21067-04 for <[e-mail]>; Tue, 27 Mar 2007 13:24:58 -0800 (PST)
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8BA4A142267 for <[e-mail]>; Tue, 27 Mar 2007 14:24:57 -0700 (PDT)
Received: by nf-out-0910.google.com with SMTP id k26so3182908nfc for <[e-mail]>; Tue, 27 Mar 2007 14:24:56 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iLoBhU3UY1RuM69/DGEM5agpofA0n7AoCQM9xV3QoOETLGAH7dkPTMV20a2YTvpBBHTBXH89pdIIWG6Kxj9QQgU2bVJIPw6I2KxqkU2H9UZd+WnlJcWCqo3wWtpIEKzfiucJQyTId1M8S8vfIT0cHtmIG3wJzJcXgjJfZwWx59E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dIj3iqmbU656OGcqqQZJnCtOFjnlRyejGndARmzzQ1UBkdWwdKVST6xsZZ+8HPyjjeAyEf0G3JQ4A90dy8S9QogDvNPY4UAnoNpv4rtz8yL9UEvM6O+YpboaMyVAmsYywnR8muPod4fPM5KydiBxVsRgK+UioAVT+unk+5JWXjk=
Received: by 10.82.114.3 with SMTP id m3mr17147436buc.1175030696055; Tue, 27 Mar 2007 14:24:56 -0700 (PDT)
Received: by 10.82.100.7 with HTTP; Tue, 27 Mar 2007 14:24:55 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 27 Mar 2007 14:24:55 -0700
From: "Mike Samuel" <[e-mail]>
To: "Bill Kearney" <[e-mail]>
Subject: Re: [Ietf-calsify] definitive references for UTC
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2007 21:25:54 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 440A27F566 for <[e-mail]>; Tue, 27 Mar 2007 07:47:52 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7AF5314227C for <[e-mail]>; Tue, 27 Mar 2007 07:46:57 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15580-03 for <[e-mail]>; Tue, 27 Mar 2007 06:46:57 -0800 (PST)
Received: from mulberrymail.com (static-151-201-20-152.pitbpa.east.verizon.net [151.201.20.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CB3D8142267 for <[e-mail]>; Tue, 27 Mar 2007 07:46:56 -0700 (PDT)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2REkpva031841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 27 Mar 2007 09:46:54 -0500
Date: Tue, 27 Mar 2007 10:46:46 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] TZID property/parameter value inconsistency
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2007 14:47:52 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2C79D7F976 for <[e-mail]>; Mon, 26 Mar 2007 11:21:51 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 43C24142279 for <[e-mail]>; Mon, 26 Mar 2007 11:20:56 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32649-10 for <[e-mail]>; Mon, 26 Mar 2007 10:20:54 -0800 (PST)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id C11BD142271 for <[e-mail]>; Mon, 26 Mar 2007 11:20:54 -0700 (PDT)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 40b8e56bf9c0286b87c12b483ae58acd
X-Spam-Score-Summary: 50, 0, 0, bc4cdb841249fc5f, afc90f00e596c9e6, [e-mail], , 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
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigel (unverified [10.42.44.110]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <[e-mail]> for <[e-mail]>;  Mon, 26 Mar 2007 11:20:54 -0700
Message-ID: <004a01c76fd3$7d74aed0$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: [Ietf-calsify] BYDAY integers with other BY* rules (was: BYSETPOS and contracting BY* rules)
Date: Mon, 26 Mar 2007 19:20:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 18:21:51 -0000

> 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 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0845D7F8EE for <[e-mail]>; Mon, 26 Mar 2007 10:25:01 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2D867142279 for <[e-mail]>; Mon, 26 Mar 2007 10:24:06 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31382-10 for <[e-mail]>; Mon, 26 Mar 2007 09:24:05 -0800 (PST)
Received: from bay0-omc1-s36.bay0.hotmail.com (bay0-omc1-s36.bay0.hotmail.com [65.54.246.108]) by laweleka.osafoundation.org (Postfix) with ESMTP id AF952142276 for <[e-mail]>; Mon, 26 Mar 2007 10:24:05 -0700 (PDT)
Received: from hotmail.com ([65.55.152.25]) by bay0-omc1-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668);  Mon, 26 Mar 2007 10:24:05 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 26 Mar 2007 10:24:05 -0700
Message-ID: <[e-mail]>
Received: from 66.92.145.118 by BAY141-DAV15.phx.gbl with DAV; Mon, 26 Mar 2007 17:24:03 +0000
X-Originating-IP: [66.92.145.118]
X-Originating-Email: [[e-mail]]
X-Sender: [e-mail]
From: "Bill Kearney" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: [Ietf-calsify] definitive references for UTC
Date: Mon, 26 Mar 2007 09:50:59 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-OriginalArrivalTime: 26 Mar 2007 17:24:05.0398 (UTC) FILETIME=[8DF42360:01C76FCB]
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=3.0 tagged_above=-50.0 required=4.0 tests=DNS_FROM_RFC_POST, MISSING_HEADERS, MISSING_SUBJECT
X-Spam-Level: **
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 17:25:01 -0000

> 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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 60ACB7F9CA for <[e-mail]>; Mon, 26 Mar 2007 10:07:12 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9BBBD142255 for <[e-mail]>; Mon, 26 Mar 2007 10:06:17 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32559-05 for <[e-mail]>; Mon, 26 Mar 2007 09:06:17 -0800 (PST)
Received: from mulberrymail.com (static-151-201-20-152.pitbpa.east.verizon.net [151.201.20.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EC46F142276 for <[e-mail]>; Mon, 26 Mar 2007 10:06:16 -0700 (PDT)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2QH6COF027376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 26 Mar 2007 12:06:15 -0500
Date: Mon, 26 Mar 2007 13:06:07 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] 2445bis Abstract
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 17:07:12 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E70C27F7A7 for <[e-mail]>; Mon, 26 Mar 2007 09:32:22 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2D663142279 for <[e-mail]>; Mon, 26 Mar 2007 09:31:28 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00759-07 for <[e-mail]>; Mon, 26 Mar 2007 08:31:25 -0800 (PST)
Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8FBC9142277 for <[e-mail]>; Mon, 26 Mar 2007 09:31:25 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2QGVOBW011248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Mar 2007 09:31:24 -0700
X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2QGVLK5020478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Mar 2007 09:31:23 -0700
Date: Mon, 26 Mar 2007 09:31:18 -0700 (PDT)
From: Mark Crispin <[e-mail]>
Sender: [e-mail]
To: Jonathan Lennox <[e-mail]>
Subject: Re: [Ietf-calsify] definitive references for UTC
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii
X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.26.91934
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.3 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 16:32:23 -0000

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.


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3F64B7F5B2 for <[e-mail]>; Mon, 26 Mar 2007 07:36:09 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7B0D2142279 for <[e-mail]>; Mon, 26 Mar 2007 07:35:14 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31564-04 for <[e-mail]>; Mon, 26 Mar 2007 06:35:14 -0800 (PST)
Received: from mulberrymail.com (static-151-201-20-152.pitbpa.east.verizon.net [151.201.20.152]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D28F3142277 for <[e-mail]>; Mon, 26 Mar 2007 07:35:13 -0700 (PDT)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2QEZ9H5026712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 26 Mar 2007 09:35:11 -0500
Date: Mon, 26 Mar 2007 10:35:05 -0400
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; FORMAT=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.3 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] Minor issues in 2445bis
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 14:36:09 -0000

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




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 901407F5B2 for <[e-mail]>; Mon, 26 Mar 2007 07:35:53 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CC26114227A for <[e-mail]>; Mon, 26 Mar 2007 07:34:58 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31770-03 for <[e-mail]>; Mon, 26 Mar 2007 06:34:55 -0800 (PST)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5F5F0142277 for <[e-mail]>; Mon, 26 Mar 2007 07:34:55 -0700 (PDT)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 7ecd5687cd2c089efe864b67832613d4
X-Spam-Score-Summary: 2, 0, 0, 623485aa5792b0c3, 72151a5f3763fbbc, [e-mail], , 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
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigelhome (unverified [10.42.40.204]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <[e-mail]>; Mon, 26 Mar 2007 07:34:54 -0700
Message-ID: <017b01c76fb4$000c21e0$d201a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Jonathan Lennox" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: [Ietf-calsify] definitive references for UTC
Date: Mon, 26 Mar 2007 15:35:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 14:35:53 -0000

> 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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E432C7F63C for <[e-mail]>; Mon, 26 Mar 2007 07:13:54 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 277ED142279 for <[e-mail]>; Mon, 26 Mar 2007 07:13:00 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29780-08 for <[e-mail]>; Mon, 26 Mar 2007 06:12:56 -0800 (PST)
Received: from mgw-ext13.nokia.com (smtp.nokia.com [131.228.20.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6107F142277 for <[e-mail]>; Mon, 26 Mar 2007 07:12:56 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2QECXfC021098 for <[e-mail]>; Mon, 26 Mar 2007 17:12:52 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 26 Mar 2007 17:12:43 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 17:12:43 +0300
Received: from [172.21.41.157] (esdhcp041157.research.nokia.com [172.21.41.157]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l2QECbnO014643 for <[e-mail]>; Mon, 26 Mar 2007 17:12:38 +0300
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2007 16:12:37 +0200
From: Aki Niemi <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Mar 2007 14:12:43.0771 (UTC) FILETIME=[D25EE4B0:01C76FB0]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::070326171252-4F327BB0-502C5FB4/0-0/0-1
X-Nokia-AV: Clean
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.3 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] Draft minutes from IETF68 available
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 14:13:55 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 128577F63C for <[e-mail]>; Mon, 26 Mar 2007 07:06:50 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4DC00142279 for <[e-mail]>; Mon, 26 Mar 2007 07:05:55 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30246-09 for <[e-mail]>; Mon, 26 Mar 2007 06:05:54 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B55EF142277 for <[e-mail]>; Mon, 26 Mar 2007 07:05:54 -0700 (PDT)
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l2QE5q4Q028347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Mon, 26 Mar 2007 10:05:52 -0400 (EDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l2QE5qYK021090 for <[e-mail]>; Mon, 26 Mar 2007 10:05:52 -0400 (EDT) (envelope-from [e-mail])
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l2QE5qho021087; Mon, 26 Mar 2007 10:05:52 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2007 10:05:51 -0400
To: [e-mail]
Subject: Re: [Ietf-calsify] definitive references for UTC
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.9 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 14:06:50 -0000

On Friday, March 23 2007, "Steve Allen" wrote to "[e-mail]" 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
[e-mail]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EBD0F7F835 for <[e-mail]>; Mon, 26 Mar 2007 06:07:29 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 33854142278 for <[e-mail]>; Mon, 26 Mar 2007 06:06:35 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29617-07 for <[e-mail]>; Mon, 26 Mar 2007 05:06:34 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6FE7114224B for <[e-mail]>; Mon, 26 Mar 2007 06:06:34 -0700 (PDT)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2007 15:06:33 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2QD6WNs024127;  Mon, 26 Mar 2007 15:06:32 +0200
Received: from elear-mac.cisco.com (ams3-vpn-dhcp429.cisco.com [10.61.65.173]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2QD6WlZ015111; Mon, 26 Mar 2007 13:06:32 GMT
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2007 15:06:34 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1607; t=1174914392; x=1175778392; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Calsify=20next=20steps |Sender:=20; bh=8ulC8BL2TI7Co03O4ovAFNU3TARpCfFOAO6jRzZtGM0=; b=JQVHyrv7mQWhEZmIfvGf4cKcXZMGnhbZtQQ8Sfg0XeyUmkLxmn1K5J/7WDG5uJJ/XqaOJ3Nz DMBVkqEAhAqVQQ2ZDMJ/yFnzqRJwNC1vBC7HTD4YcZZ9aUF6icpXPVOJ;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.8 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] Calsify next steps
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 13:07:30 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 33D0A7F9A4 for <[e-mail]>; Mon, 26 Mar 2007 01:09:31 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 70BC114225C for <[e-mail]>; Mon, 26 Mar 2007 01:08:36 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26119-04 for <[e-mail]>; Mon, 26 Mar 2007 00:08:36 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE583142255 for <[e-mail]>; Mon, 26 Mar 2007 01:08:35 -0700 (PDT)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2007 10:08:35 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2Q88Yu2021139;  Mon, 26 Mar 2007 10:08:34 +0200
Received: from elear-mac.cisco.com (ams3-vpn-dhcp429.cisco.com [10.61.65.173]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2Q88XlZ006170; Mon, 26 Mar 2007 08:08:34 GMT
Message-ID: <[e-mail]>
Date: Mon, 26 Mar 2007 10:08:36 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: Petr Tomasek <[e-mail]>
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=811; t=1174896514; x=1175760514; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20B.C.E=20and=20Y10K=20problem=20with= 20iCalendar? |Sender:=20; bh=C35GWHJ44/N55QOU61M4QkPPk/RjMsfGfbMwHJB5CTM=; b=ltmcKgMssYpc1W6bZUaq5kttAOciS6jwPODq+J5ry4kWDmZzTpnnC+mGvyHwhPUHUnnJwBho XSGrZUJDt1jYTV2Ml3TjHtZvkHEkS0Eya43EQK6mxgSfzrcGeYkclC0w;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 08:09:31 -0000

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.


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6A4D57F959 for <[e-mail]>; Sun, 25 Mar 2007 23:08:31 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A72E1142277 for <[e-mail]>; Sun, 25 Mar 2007 23:07:36 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26276-05 for <[e-mail]>; Sun, 25 Mar 2007 22:07:36 -0800 (PST)
Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DD9D4142276 for <[e-mail]>; Sun, 25 Mar 2007 23:07:35 -0700 (PDT)
Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id l2Q5wMOL032213 for <[e-mail]>; Mon, 26 Mar 2007 07:58:22 +0200
Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id l2Q5wMr3032211 for [e-mail]; Mon, 26 Mar 2007 07:58:22 +0200
Date: Mon, 26 Mar 2007 07:58:22 +0200
From: Petr Tomasek <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-Homepage: http://www.etf.cuni.cz/~tomasek/
X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon
X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.3.1.44; VDF: 6.38.0.114; host: ebed.etf.cuni.cz)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=1.1 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: *
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 06:08:31 -0000

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

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E77077F508 for <[e-mail]>; Sun, 25 Mar 2007 22:54:27 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3046F142277 for <[e-mail]>; Sun, 25 Mar 2007 22:53:33 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25479-10 for <[e-mail]>; Sun, 25 Mar 2007 21:53:30 -0800 (PST)
Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 51417142276 for <[e-mail]>; Sun, 25 Mar 2007 22:53:30 -0700 (PDT)
Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id l2Q5iGjf031326 for <[e-mail]>; Mon, 26 Mar 2007 07:44:16 +0200
Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id l2Q5iGji031323 for [e-mail]; Mon, 26 Mar 2007 07:44:16 +0200
Date: Mon, 26 Mar 2007 07:44:16 +0200
From: Petr Tomasek <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-Homepage: http://www.etf.cuni.cz/~tomasek/
X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon
X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.3.1.44; VDF: 6.38.0.114; host: ebed.etf.cuni.cz)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=1.1 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: *
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 05:54:28 -0000

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

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B94D87F7AA for <[e-mail]>; Sun, 25 Mar 2007 22:14:15 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A4391142279 for <[e-mail]>; Sun, 25 Mar 2007 22:13:20 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24384-02 for <[e-mail]>; Sun, 25 Mar 2007 21:13:19 -0800 (PST)
Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D3791142278 for <[e-mail]>; Sun, 25 Mar 2007 22:13:18 -0700 (PDT)
Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id l2Q545Z7028646 for <[e-mail]>; Mon, 26 Mar 2007 07:04:05 +0200
Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id l2Q544w9028644 for [e-mail]; Mon, 26 Mar 2007 07:04:04 +0200
Date: Mon, 26 Mar 2007 07:04:04 +0200
From: Petr Tomasek <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-Homepage: http://www.etf.cuni.cz/~tomasek/
X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon
X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.3.1.44; VDF: 6.38.0.114; host: ebed.etf.cuni.cz)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=1.1 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: *
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2007 05:14:20 -0000

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. 

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 04C377F63C for <[e-mail]>; Sun, 25 Mar 2007 11:19:18 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 42091142274 for <[e-mail]>; Sun, 25 Mar 2007 11:18:23 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19869-04 for <[e-mail]>; Sun, 25 Mar 2007 10:18:20 -0800 (PST)
Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B91CE142271 for <[e-mail]>; Sun, 25 Mar 2007 11:18:20 -0700 (PDT)
Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2PIIFar010893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 25 Mar 2007 11:18:15 -0700
X-Auth-Received: from localhost (panda.com [206.124.149.114]) (authenticated authid=mrc) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2PIICqg030080 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 25 Mar 2007 11:18:14 -0700
Date: Sun, 25 Mar 2007 11:17:49 -0700
From: Mark Crispin <[e-mail]>
To: Eliot Lear <[e-mail]>
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Organization: Networks & Distributed Computing
Sender: [e-mail]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii
X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.25.110434
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.3 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 25 Mar 2007 18:19:18 -0000

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.


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DCFDE7F5B2 for <[e-mail]>; Sun, 25 Mar 2007 10:24:58 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 259A6142271 for <[e-mail]>; Sun, 25 Mar 2007 10:24:04 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20657-02 for <[e-mail]>; Sun, 25 Mar 2007 09:24:00 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 60C08142264 for <[e-mail]>; Sun, 25 Mar 2007 10:24:00 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2007 19:24:00 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2PHNxGT009831;  Sun, 25 Mar 2007 19:23:59 +0200
Received: from elear-mac.cisco.com (ams3-vpn-dhcp429.cisco.com [10.61.65.173]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2PHNxlZ007463; Sun, 25 Mar 2007 17:23:59 GMT
Message-ID: <[e-mail]>
Date: Sun, 25 Mar 2007 19:24:01 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: Steve Allen <[e-mail]>
Subject: Re: [Ietf-calsify] definitive references for UTC
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1063; t=1174843439; x=1175707439; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20definitive=20references=20for=20UTC |Sender:=20; bh=+OpJLS9YZ34Su4H7u7G2gLEzTWVn2d6bGqso2JA+5mQ=; b=dGGFkuQXC0J1NZV8OxJVxJnfzUN7Iq+1tEin89rcUnZ3BnfT4oDjR/bgo8LPml9Ynj1Kw5Zq Tvx8nmLfZ6yYOB1mvMiFO8WjruCbP6Q65YRZc6wZrYMqOi5v3aimsf5q;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: "[e-mail]" <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 25 Mar 2007 17:24:59 -0000

<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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BE0567F697 for <[e-mail]>; Sun, 25 Mar 2007 10:22:50 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 02B30142277 for <[e-mail]>; Sun, 25 Mar 2007 10:21:56 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17990-09 for <[e-mail]>; Sun, 25 Mar 2007 09:21:55 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2B72E142276 for <[e-mail]>; Sun, 25 Mar 2007 10:21:54 -0700 (PDT)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Mar 2007 19:21:54 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l2PHLrhG021759;  Sun, 25 Mar 2007 19:21:53 +0200
Received: from elear-mac.cisco.com (ams3-vpn-dhcp429.cisco.com [10.61.65.173]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2PHLklZ007225; Sun, 25 Mar 2007 17:21:48 GMT
Message-ID: <[e-mail]>
Date: Sun, 25 Mar 2007 19:21:48 +0200
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: Petr Tomasek <[e-mail]>
Subject: Re: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=909; t=1174843313; x=1175707313; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20B.C.E=20and=20Y10K=20problem=20with= 20iCalendar? |Sender:=20; bh=+Q2xBz+TkZ7knVIPKetjAW1OQxbt1IL5GpQ/WpVugYo=; b=f3tMdrxUeJYpTO9cb8iY5qa9KZQTzYE/Ww1upU4KcpOPtreG1gHrr3YnypG7LAqBcLF0XV3O VCUmGgnT7lZjla4Ixgvj6Iyb2WNOioduNKZ4BP4CixKdaeyffSuUyiOq;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 25 Mar 2007 17:22:50 -0000

<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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EE2467F793 for <[e-mail]>; Sun, 25 Mar 2007 06:40:09 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3709F142274 for <[e-mail]>; Sun, 25 Mar 2007 06:39:15 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17873-06 for <[e-mail]>; Sun, 25 Mar 2007 05:39:13 -0800 (PST)
Received: from ebed.etf.cuni.cz (ebed.etf.cuni.cz [195.113.5.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 67D80142273 for <[e-mail]>; Sun, 25 Mar 2007 06:39:13 -0700 (PDT)
Received: from ebed.etf.cuni.cz (localhost.localdomain [127.0.0.1]) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11) with ESMTP id l2PDU3hb001879 for <[e-mail]>; Sun, 25 Mar 2007 15:30:03 +0200
Received: (from tomasek@localhost) by ebed.etf.cuni.cz (8.12.11.20060308/8.12.11/Submit) id l2PDU3ks001870 for [e-mail]; Sun, 25 Mar 2007 15:30:03 +0200
Date: Sun, 25 Mar 2007 15:30:03 +0200
From: Petr Tomasek <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
X-Homepage: http://www.etf.cuni.cz/~tomasek/
X-Echelon: bomb Arafat Intifada bus kach drugs mafia boss heroin spy Semtex Saddam Al-Qaida Usama bin Ladin Bush Sharon
X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-4; AVE: 7.3.1.44; VDF: 6.38.0.113; host: ebed.etf.cuni.cz)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.9 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 25 Mar 2007 13:40:10 -0000

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

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A21177F511 for <[e-mail]>; Fri, 23 Mar 2007 22:17:48 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E3C66142270 for <[e-mail]>; Fri, 23 Mar 2007 22:16:53 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00961-08 for <[e-mail]>; Fri, 23 Mar 2007 21:16:50 -0800 (PST)
Received: from smtp.ucolick.org (hunan.ucolick.org [128.114.23.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 747A214226E for <[e-mail]>; Fri, 23 Mar 2007 22:16:50 -0700 (PDT)
Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id ED9BC3A0B for <[e-mail]>; Fri, 23 Mar 2007 22:16:49 -0700 (PDT)
Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ucolick.org (Postfix) with ESMTP id DFCCE3A00 for <[e-mail]>; Fri, 23 Mar 2007 22:16:49 -0700 (PDT)
Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (8.13.1/8.12.10) with ESMTP id l2O5Gn9e015132 for <[e-mail]>; Fri, 23 Mar 2007 22:16:49 -0700
Received: (from sla@localhost) by geneva.ucolick.org (8.13.1/8.13.1/Submit) id l2O5GnWR015131 for [e-mail]; Fri, 23 Mar 2007 22:16:49 -0700
Date: Fri, 23 Mar 2007 22:16:49 -0700
From: Steve Allen <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=1.2 tagged_above=-50.0 required=4.0 tests=MISSING_SUBJECT
X-Spam-Level: *
Subject: [Ietf-calsify] definitive references for UTC
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 24 Mar 2007 05:17:48 -0000

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                 <[e-mail]>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99845
University of California    Voice: [phone]           Lng -122.06025
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2C9F77F9C7 for <[e-mail]>; Wed, 21 Mar 2007 19:14:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 32D03142264 for <[e-mail]>; Wed, 21 Mar 2007 19:13:18 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32332-06 for <[e-mail]>; Wed, 21 Mar 2007 18:13:17 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 37C4C142260 for <[e-mail]>; Wed, 21 Mar 2007 19:13:16 -0700 (PDT)
Received: from [10.0.1.5] ([10.0.1.5]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2M2DAwb030350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2007 21:13:14 -0500
Date: Wed, 21 Mar 2007 22:13:09 -0400
From: Cyrus Daboo <[e-mail]>
To: Nigel Swinson <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] Interpretation of the UNTIL part of RRULEs in	Timezones
Message-ID: <[e-mail]>
In-Reply-To: <001001c76bde$65ab8600$[e-mail]>
References: <001001c76bde$65ab8600$[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-2.1 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2007 02:14:14 -0000

Hi Nigel,

--On March 21, 2007 5:28:51 PM +0000 Nigel Swinson 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F2CE47F9C3 for <[e-mail]>; Wed, 21 Mar 2007 10:29:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 48862142260 for <[e-mail]>; Wed, 21 Mar 2007 10:28:55 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15052-04 for <[e-mail]>; Wed, 21 Mar 2007 09:28:54 -0800 (PST)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9E097142258 for <[e-mail]>; Wed, 21 Mar 2007 10:28:54 -0700 (PDT)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 12ae79e199a05b7c75429e25638c5d00
X-Spam-Score-Summary: 2, 0, 0, 046a475d25d27149, 77946e9d9e053620, [e-mail], , 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
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigel (unverified [10.42.44.110]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <[e-mail]> for <[e-mail]>;  Wed, 21 Mar 2007 10:28:53 -0700
Message-ID: <001001c76bde$65ab8600$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Date: Wed, 21 Mar 2007 17:28:51 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] Interpretation of the UNTIL part of RRULEs in Timezones
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2007 17:29:50 -0000

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 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 27AD17F7AA for <[e-mail]>; Mon, 19 Mar 2007 08:19:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 790EF142256 for <[e-mail]>; Mon, 19 Mar 2007 08:18:26 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09696-06 for <[e-mail]>; Mon, 19 Mar 2007 07:18:26 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E4EC0142254 for <[e-mail]>; Mon, 19 Mar 2007 08:18:25 -0700 (PDT)
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l2JFI6aU023253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Mar 2007 11:18:17 -0400 (EDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l2JFI6C5076356; Mon, 19 Mar 2007 11:18:06 -0400 (EDT) (envelope-from [e-mail])
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l2JFI5YI076353; Mon, 19 Mar 2007 11:18:05 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Mon, 19 Mar 2007 11:18:05 -0400
To: Eliot Lear <[e-mail]>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.9 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
Subject: [Ietf-calsify] Overlooked issues for the tracker
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 19 Mar 2007 15:19:23 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 407177F8FA for <[e-mail]>; Sat, 17 Mar 2007 05:49:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9BBC214225D for <[e-mail]>; Sat, 17 Mar 2007 05:48:53 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13730-04 for <[e-mail]>; Sat, 17 Mar 2007 04:48:52 -0800 (PST)
Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 56ACA14225B for <[e-mail]>; Sat, 17 Mar 2007 05:48:51 -0700 (PDT)
Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2HCmj6g029907 for <[e-mail]>; Sat, 17 Mar 2007 12:48:50 GMT
Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Sat, 17 Mar 2007 12:48:45 +0000 (GMT)
Received: from KONE-JHY8LIXZ2A.Sun.COM ([129.150.116.85]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <[e-mail]>; Sat, 17 Mar 2007 12:48:45 +0000 (GMT)
Content-return: prohibited
Date: Sat, 17 Mar 2007 13:48:56 +0100
From: Arnaud Quillaud <[e-mail]>
Subject: RE : RE : [Ietf-calsify] rfc 2446 - Cancel and sequence number
In-reply-to: <[e-mail]>
Sender: [e-mail]
To: Eliot Lear <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Outlook Connector 7.2.307.0
Content-type: TEXT/PLAIN; CHARSET=Windows-1252
Content-transfer-encoding: QUOTED-PRINTABLE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Mar 2007 12:49:48 -0000

> -----Message d'origine-----
> De : Eliot Lear [mailto:[e-mail]]=20
> Envoy=E9 : samedi 17 mars 2007 13:22
> =C0 : Arnaud Quillaud
> Cc : Cyrus Daboo; Robert Ransdell; [e-mail]
> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 54E417F8FA for <[e-mail]>; Sat, 17 Mar 2007 05:22:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B12A214225C for <[e-mail]>; Sat, 17 Mar 2007 05:21:53 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12910-10 for <[e-mail]>; Sat, 17 Mar 2007 04:21:51 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id EC23714225B for <[e-mail]>; Sat, 17 Mar 2007 05:21:50 -0700 (PDT)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Mar 2007 13:21:51 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2HCLnXR012351;  Sat, 17 Mar 2007 13:21:49 +0100
Received: from elear-mac.cisco.com (ams3-vpn-dhcp4327.cisco.com [10.61.80.230]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2HCLhlZ020202;  Sat, 17 Mar 2007 12:21:44 GMT
Message-ID: <[e-mail]>
Date: Sat, 17 Mar 2007 13:21:43 +0100
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: Arnaud Quillaud <[e-mail]>
Subject: Re: RE : [Ietf-calsify] rfc 2446 - Cancel and sequence number
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=727; t=1174134109; x=1174998109; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20RE=20=3A=20[Ietf-calsify]=20rfc=202446=20-=20Cancel=2 0and=20sequence=20number |Sender:=20; bh=v4HRSbVfTy9SDCKLrLiKDtn1dFmCxxMoCilvEMQ1yUI=; b=MIEWYuUguerKcspOfoBaZEuxpC2hSUDudzU2hgVQO3Gs91Ed/R6MfpORd8NWlpL05I0E57ZT x3Y45rwNTKiL06Nx0ZkIcOvp/LTeMLh6EGXf3taQO1iLpN9kAnYV9gLu;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Mar 2007 12:22:48 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 507B47F6B1 for <[e-mail]>; Sat, 17 Mar 2007 02:06:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A576014225B for <[e-mail]>; Sat, 17 Mar 2007 02:06:01 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10534-10 for <[e-mail]>; Sat, 17 Mar 2007 01:06:00 -0800 (PST)
Received: from gmp-ea-fw-1.sun.com (gmp-ea-fw-1.sun.com [192.18.1.36]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6AB5914225A for <[e-mail]>; Sat, 17 Mar 2007 02:05:59 -0700 (PDT)
Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2H95rSU021469 for <[e-mail]>; Sat, 17 Mar 2007 09:05:58 GMT
Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006)) id <[e-mail]> (original mail from [e-mail]) for [e-mail]; Sat, 17 Mar 2007 09:05:53 +0000 (GMT)
Received: from KONE-JHY8LIXZ2A.Sun.COM ([129.150.116.88]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <[e-mail]>; Sat, 17 Mar 2007 09:05:53 +0000 (GMT)
Content-return: prohibited
Date: Sat, 17 Mar 2007 10:06:04 +0100
From: Arnaud Quillaud <[e-mail]>
Subject: RE : [Ietf-calsify] rfc 2446 - Cancel and sequence number
In-reply-to: <[e-mail]>
Sender: [e-mail]
To: Cyrus Daboo <[e-mail]>, Robert Ransdell <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Sun Outlook Connector 7.2.307.0
Content-type: TEXT/PLAIN; CHARSET=Windows-1252
Content-transfer-encoding: QUOTED-PRINTABLE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sat, 17 Mar 2007 09:06:57 -0000

> -----Message d'origine-----
> De : [e-mail]=20
> [mailto:[e-mail]] De la part de=20
> Cyrus Daboo
> Envoy=E9 : vendredi 16 mars 2007 19:02
> =C0 : Robert Ransdell; [e-mail]
> 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
> <[e-mail]> 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
> Cyrus Daboo
>=20
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]=20
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>=20



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CD47D7FB8E for <[e-mail]>; Fri, 16 Mar 2007 12:21:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 15D0A142257 for <[e-mail]>; Fri, 16 Mar 2007 12:20:39 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04666-05 for <[e-mail]>; Fri, 16 Mar 2007 11:20:38 -0800 (PST)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 70FC9142256 for <[e-mail]>; Fri, 16 Mar 2007 12:20:38 -0700 (PDT)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 7d9a83b71c1bcc41093c079f1eb50ccd
X-Spam-Score-Summary: 2, 0, 0, 921ffa70e94e0dd2, 2ca01a0416685845, [e-mail], , 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
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigel (unverified [10.42.44.110]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <[e-mail]>; Fri, 16 Mar 2007 12:20:38 -0700
Message-ID: <00cc01c76800$2d9bc360$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Jonathan Lennox" <[e-mail]>
References: <[e-mail]><[e-mail]><007301c767e7$1b5d15a0$[e-mail]> <[e-mail]>
Subject: Re: [Ietf-calsify] Issues 8, 68, 69, 70
Date: Fri, 16 Mar 2007 19:20:35 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 19:21:34 -0000

> 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 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4A0B77FB8D for <[e-mail]>; Fri, 16 Mar 2007 12:05:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A4F88142256 for <[e-mail]>; Fri, 16 Mar 2007 12:04:33 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04636-01 for <[e-mail]>; Fri, 16 Mar 2007 11:04:32 -0800 (PST)
Received: from redwood.morsemedia.net (redwood.morsemedia.net [69.50.246.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E4926142250 for <[e-mail]>; Fri, 16 Mar 2007 12:04:32 -0700 (PDT)
Received: from [75.111.50.119] (helo=[192.168.0.102]) by redwood.morsemedia.net with esmtpa (Exim 4.63) (envelope-from <[e-mail]>) id 1HSHim-0002Ec-Sv; Fri, 16 Mar 2007 12:04:13 -0700
Message-ID: <[e-mail]>
Date: Fri, 16 Mar 2007 12:04:05 -0700
From: Dave Thewlis <[e-mail]>
Organization: The Calendaring and Scheduling Consortium
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: ietf-calsify list <[e-mail]>
Content-Type: multipart/alternative; boundary="------------060906050502040504030405"
X-MorseMedia-MailScanner-Information: Please contact the ISP for more information
X-MorseMedia-MailScanner-SpamCheck: 
X-MorseMedia-MailScanner-From: [e-mail]
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - redwood.morsemedia.net
X-AntiAbuse: Original Domain - osafoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - calconnect.org
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=1.1 tagged_above=-50.0 required=4.0 tests=AWL, HTML_20_30, HTML_MESSAGE, MISSING_SUBJECT
X-Spam-Level: *
Subject: [Ietf-calsify] Announcing CalConnect Roundtable IX and Interoperability Test Event - May 7-11, Seattle, Washington
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 19:05:28 -0000

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*
[phone] (voice) · [phone] (mobile)
http://www.calconnect.org · [e-mail] 
<mailto:[e-mail]>

--------------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>
[phone] (voice) &middot; [phone] (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[e-mail]">[e-mail]</a>
</font></div>
</body>
</html>

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C495F7FB8E for <[e-mail]>; Fri, 16 Mar 2007 11:03:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2C09F142256 for <[e-mail]>; Fri, 16 Mar 2007 11:02:45 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04074-02 for <[e-mail]>; Fri, 16 Mar 2007 10:02:44 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 18315142250 for <[e-mail]>; Fri, 16 Mar 2007 11:02:43 -0700 (PDT)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2GI2NhC023934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Mar 2007 13:02:26 -0500
Date: Fri, 16 Mar 2007 14:02:18 -0400
From: Cyrus Daboo <[e-mail]>
To: Robert Ransdell <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] rfc 2446 - Cancel and sequence number
Message-ID: <[e-mail]>
In-Reply-To: <OFCB2B39FC.1B944264-ON852572A0.0060589A-852572A0.0060FC2C@LocalDomain>
References: <OFCB2B39FC.1B944264-ON852572A0.0060589A-852572A0.0060FC2C@LocalDomain>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 18:03:39 -0000

Hi Robert,

--On March 16, 2007 1:39:20 PM -0400 Robert Ransdell 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 11F937FCCC for <[e-mail]>; Fri, 16 Mar 2007 10:52:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6D84814225B for <[e-mail]>; Fri, 16 Mar 2007 10:51:06 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03233-03 for <[e-mail]>; Fri, 16 Mar 2007 09:51:06 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D00C114225A for <[e-mail]>; Fri, 16 Mar 2007 10:51:05 -0700 (PDT)
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l2GHp3Dq002689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Mar 2007 13:51:03 -0400 (EDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l2GHp3X4059552; Fri, 16 Mar 2007 13:51:03 -0400 (EDT) (envelope-from [e-mail])
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l2GHom4u059547; Fri, 16 Mar 2007 13:50:48 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Fri, 16 Mar 2007 13:50:48 -0400
To: "Nigel Swinson" <[e-mail]>
Subject: Re: [Ietf-calsify] Issues 8, 68, 69, 70
In-Reply-To: <007301c767e7$1b5d15a0$[e-mail]>
References: <[e-mail]> <[e-mail]> <007301c767e7$1b5d15a0$[e-mail]>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.9 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 17:52:01 -0000

On Friday, March 16 2007, "Nigel Swinson" wrote to "Jonathan Lennox, <[e-mail]>" 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
[e-mail]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2F4467FCCC for <[e-mail]>; Fri, 16 Mar 2007 10:40:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E3C0A14225B for <[e-mail]>; Fri, 16 Mar 2007 10:39:23 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03514-10 for <[e-mail]>; Fri, 16 Mar 2007 09:39:23 -0800 (PST)
Received: from capricorn.notesdev.ibm.com (capricorn.notesdev.ibm.com [205.159.212.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id 48956142257 for <[e-mail]>; Fri, 16 Mar 2007 10:39:23 -0700 (PDT)
To: [e-mail]
Message-ID: <OFCB2B39FC.1B944264-ON852572A0.0060589A-852572A0.0060FC2C@LocalDomain>
Date: Fri, 16 Mar 2007 13:39:20 -0400
From: "Robert Ransdell" <[e-mail]>
Content-Type: multipart/alternative; boundary="=_alternative 0060FC1A852572A0_="
MIME-Version: 1.0
X-KeepSent: CB2B39FC:1B944264-852572A0:0060589A; name=$KeepSent; type=4
X-Mailer: Lotus Notes Build V703_01092007NP January 09, 2007
X-Disclaimed: 11407
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.8 tagged_above=-50.0 required=4.0 tests=AWL, HTML_30_40, HTML_MESSAGE, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] rfc 2446 - Cancel and sequence number
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 17:40:19 -0000

--=_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_=--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DBB497FA26 for <[e-mail]>; Fri, 16 Mar 2007 09:22:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4359F142256 for <[e-mail]>; Fri, 16 Mar 2007 09:21:12 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01081-07 for <[e-mail]>; Fri, 16 Mar 2007 08:21:11 -0800 (PST)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3BB77142250 for <[e-mail]>; Fri, 16 Mar 2007 09:21:11 -0700 (PDT)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 7729710623e7b6fd4af3adea5491fd5a
X-Spam-Score-Summary: 2, 0, 0, a359772ed984727c, 2ca01a0416685845, [e-mail], , 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
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigel (unverified [10.42.44.110]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <[e-mail]>; Fri, 16 Mar 2007 09:21:10 -0700
Message-ID: <007301c767e7$1b5d15a0$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Jonathan Lennox" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: [Ietf-calsify] Issues 8, 68, 69, 70
Date: Fri, 16 Mar 2007 16:21:07 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 16:22: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 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 290B47F5D1; Fri, 16 Mar 2007 02:31:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7CD26142257; Fri, 16 Mar 2007 02:30:20 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30887-01; Fri, 16 Mar 2007 01:30:17 -0800 (PST)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BCA9F14224B; Fri, 16 Mar 2007 02:30:17 -0700 (PDT)
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2G9UEw1000342; Fri, 16 Mar 2007 04:30:14 -0500
Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2G9UCJW025255; Fri, 16 Mar 2007 03:30:12 -0600
Received: from dhcp-amer-rmdc-csvpn-gw6-141-144-113-7.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2534100241174007661; Thu, 15 Mar 2007 18:14:21 -0700
Message-ID: <[e-mail]>
Date: Thu, 15 Mar 2007 21:14:25 -0400
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: [e-mail], [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=1.2 tagged_above=-50.0 required=4.0 tests=MISSING_SUBJECT
X-Spam-Level: *
Subject: [Ietf-calsify] [Fwd: RFC 4791 on Calendaring Extensions to WebDAV (CalDAV)]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 16 Mar 2007 09:31:15 -0000

FYI

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


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:    [e-mail],
                     [e-mail],
                     [e-mail]
         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 [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

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

help: ways_to_get_rfcs. For example:

         To: [e-mail]
         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 [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

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


The RFC Editor Team
USC/Information Sciences Institute

...



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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A57617FA38 for <[e-mail]>; Wed, 14 Mar 2007 09:49:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 140FE14225C for <[e-mail]>; Wed, 14 Mar 2007 09:48:53 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03157-06 for <[e-mail]>; Wed, 14 Mar 2007 08:48:52 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 48B69142257 for <[e-mail]>; Wed, 14 Mar 2007 09:48:52 -0700 (PDT)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2EGmXWN012593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Mar 2007 11:48:36 -0500
Date: Wed, 14 Mar 2007 12:48:28 -0400
From: Cyrus Daboo <[e-mail]>
To: Reinhold Kainhofer <[e-mail]>, CALSIFY Mailinglist <[e-mail]>
Subject: Re: [Ietf-calsify] Attendees without email addresses
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL, MISSING_SUBJECT, TW_UU
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2007 16:49:47 -0000

Hi Reinhold,

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

>> If you are not going to use iTIP at all, why not just use a bogus email
>> address: e.g., "mailto:[e-mail]"? 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 814DC7FA38 for <[e-mail]>; Wed, 14 Mar 2007 09:45:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DF2ED14225C for <[e-mail]>; Wed, 14 Mar 2007 09:44:05 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02084-07 for <[e-mail]>; Wed, 14 Mar 2007 08:44:04 -0800 (PST)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1748E142257 for <[e-mail]>; Wed, 14 Mar 2007 09:44:03 -0700 (PDT)
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2EGhwLT003616 for <[e-mail]>; Wed, 14 Mar 2007 17:44:01 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: CALSIFY Mailinglist <[e-mail]>
Subject: Re: [Ietf-calsify] Attendees without email addresses
Date: Wed, 14 Mar 2007 17:43:48 +0100
User-Agent: KMail/1.9.5 + Features
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT, TW_UU
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2007 16:45:00 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:[e-mail]"? 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
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], 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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF+CZNTqjEwhXvPN0RAgimAJsEMvnJksnNJ6hbQXR185LYudLbngCgy9cB
QmRV942SsT2D/mtPXXdtV5Q=
=lVfx
-----END PGP SIGNATURE-----


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 413117FA3A for <[e-mail]>; Wed, 14 Mar 2007 09:14:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6368014225C for <[e-mail]>; Wed, 14 Mar 2007 09:13:12 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01443-10 for <[e-mail]>; Wed, 14 Mar 2007 08:13:11 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7B063142256 for <[e-mail]>; Wed, 14 Mar 2007 09:13:11 -0700 (PDT)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l2EGCtHU012462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Mar 2007 11:12:58 -0500
Date: Wed, 14 Mar 2007 12:12:50 -0400
From: Cyrus Daboo <[e-mail]>
To: Reinhold Kainhofer <[e-mail]>, CALSIFY Mailinglist <[e-mail]>
Subject: Re: [Ietf-calsify] Attendees without email addresses
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL, MISSING_SUBJECT, TW_UU
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2007 16:14:07 -0000

Hi Reinhold,

--On March 14, 2007 4:25:41 PM +0100 Reinhold Kainhofer 
<[e-mail]> 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:[e-mail]"? Or use the urn:uuid scheme 
and generate a uuid for each unique attendee.

-- 
Cyrus Daboo



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5339B7FA3C for <[e-mail]>; Wed, 14 Mar 2007 08:50:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B683F14225C for <[e-mail]>; Wed, 14 Mar 2007 08:49:23 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00900-02 for <[e-mail]>; Wed, 14 Mar 2007 07:49:23 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CA58014225B for <[e-mail]>; Wed, 14 Mar 2007 08:49:22 -0700 (PDT)
Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l2EFnKVC026181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Wed, 14 Mar 2007 11:49:20 -0400 (EDT)
Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.6/8.13.6) with ESMTP id l2EFnK7I051326 for <[e-mail]>; Wed, 14 Mar 2007 11:49:20 -0400 (EDT) (envelope-from [e-mail])
Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.6/8.13.6/Submit) id l2EFnGGh051321; Wed, 14 Mar 2007 11:49:16 -0400 (EDT) (envelope-from lennox)
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 14 Mar 2007 11:49:16 -0400
To: "[e-mail]" <[e-mail]>
Subject: Re: [Ietf-calsify] Issues 8, 68, 69, 70
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 7.19 under Emacs 21.3.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.9 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2007 15:50:18 -0000

On Thursday, March 8 2007, "Eliot Lear" wrote to "[e-mail]" 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
[e-mail]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D6B3E7F721 for <[e-mail]>; Wed, 14 Mar 2007 08:26:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 467EC14225B for <[e-mail]>; Wed, 14 Mar 2007 08:25:56 -0700 (PDT)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31881-07 for <[e-mail]>; Wed, 14 Mar 2007 07:25:53 -0800 (PST)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6D8CF142258 for <[e-mail]>; Wed, 14 Mar 2007 08:25:53 -0700 (PDT)
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2EFPlU0024740 for <[e-mail]>; Wed, 14 Mar 2007 16:25:50 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: CALSIFY Mailinglist <[e-mail]>
Date: Wed, 14 Mar 2007 16:25:41 +0100
User-Agent: KMail/1.9.5 + Features
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] Attendees without email addresses
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2007 15:26:51 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], 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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF+BP7TqjEwhXvPN0RAqS/AJsFr6guJncOLC48DyT979AL8F3+1gCfchGf
AUCbVh1krYhsRbm7kBOs7uM=
=Hx0c
-----END PGP SIGNATURE-----


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9C4E57F9EE for <[e-mail]>; Thu,  8 Mar 2007 15:09:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 235B714224B for <[e-mail]>; Thu,  8 Mar 2007 15:08:38 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31416-01 for <[e-mail]>; Thu, 8 Mar 2007 15:08:35 -0800 (PST)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 461A6142247 for <[e-mail]>; Thu,  8 Mar 2007 15:08:34 -0800 (PST)
Received: from einstein.kainhofer.com (localhost [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l28N8Thh004841 for <[e-mail]>; Fri, 9 Mar 2007 00:08:29 +0100
From: Reinhold Kainhofer <[e-mail]>
Organization: Vienna University of Technology
To: [e-mail]
Subject: Re: [Ietf-calsify] Issues 8, 68, 69, 70
Date: Fri, 9 Mar 2007 00:08:24 +0100
User-Agent: KMail/1.9.6
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 23:09:33 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [e-mail], 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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF8JdqTqjEwhXvPN0RAl4QAJ4hpfFwTvHStMFTo1VztRYoIq6hWQCfYHJ2
d6LlrjcR5dgIaVrVRoJTCNw=
=13Qz
-----END PGP SIGNATURE-----


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B451D7F7A7 for <[e-mail]>; Thu,  8 Mar 2007 08:57:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3C907142250 for <[e-mail]>; Thu,  8 Mar 2007 08:56:36 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24839-02 for <[e-mail]>; Thu, 8 Mar 2007 08:56:35 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8268114224D for <[e-mail]>; Thu,  8 Mar 2007 08:56:35 -0800 (PST)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2007 17:56:34 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l28GuYr4031342 for <[e-mail]>; Thu, 8 Mar 2007 17:56:34 +0100
Received: from elear-mac.cisco.com (ams3-vpn-dhcp4472.cisco.com [10.61.81.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l28GuYAp008854 for <[e-mail]>; Thu, 8 Mar 2007 16:56:34 GMT
Message-ID: <[e-mail]>
Date: Thu, 08 Mar 2007 17:56:33 +0100
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=722; t=1173372994; x=1174236994; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Issues=208,=2068,=2069,=2070 |Sender:=20; bh=nGGPiuPhzDglVQVjc/6SMtUdBnGPZ5fsEJioa3bOFxc=; b=Hd6wkQaNxK7LVlxgh+PIz5SpZkNJkQCCfj6WGBPcQqpJ+y0dVbz7ZUm+658+eBiXyeqrTHvb YgSYoQUhsh+ps2dVNGu5131q+sXIwTFPfQ6pUVJ0Kyj9Z+dBvQ426kHl;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] Issues 8, 68, 69, 70
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 16:57:30 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8D18C7F7A7 for <[e-mail]>; Thu,  8 Mar 2007 08:52:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1502C142250 for <[e-mail]>; Thu,  8 Mar 2007 08:51:48 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23534-07 for <[e-mail]>; Thu, 8 Mar 2007 08:51:47 -0800 (PST)
Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by laweleka.osafoundation.org (Postfix) with ESMTP id A772014224D for <[e-mail]>; Thu,  8 Mar 2007 08:51:47 -0800 (PST)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2007 08:51:46 -0800
X-IronPort-AV: i="4.14,264,1170662400";  d="scan'208"; a="364652178:sNHT43454320"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l28Gpkqh009748 for <[e-mail]>; Thu, 8 Mar 2007 17:51:46 +0100
Received: from elear-mac.cisco.com (ams3-vpn-dhcp4472.cisco.com [10.61.81.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l28GpjAp007649 for <[e-mail]>; Thu, 8 Mar 2007 16:51:46 GMT
Message-ID: <[e-mail]>
Date: Thu, 08 Mar 2007 17:51:45 +0100
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=255; t=1173372706; x=1174236706; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20iTIP=20issues |Sender:=20; bh=V6/PRFwDanjYeDsT0i38LCcrYM78ZZZ8IjfdmW4Hzqs=; b=jJkpyd1UL9Ttl3sc5Y92CvZJcRuY9GOACIHZa8eWjvUKB5KTikH9320ZZUKCkw2JiyatUgye mepTcpKpQPavn8WnaUpUqvURIaFVO/f9/rA4nAt/RCb/vU/pMMOM3Bis;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] iTIP issues
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 16:52:42 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7B4637F5E1 for <[e-mail]>; Thu,  8 Mar 2007 06:57:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EA32C14224D for <[e-mail]>; Thu,  8 Mar 2007 06:56:15 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24402-10 for <[e-mail]>; Thu, 8 Mar 2007 06:56:15 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4469114224B for <[e-mail]>; Thu,  8 Mar 2007 06:56:15 -0800 (PST)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2007 15:56:14 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l28EuEGF024088 for <[e-mail]>; Thu, 8 Mar 2007 15:56:14 +0100
Received: from elear-mac.cisco.com (ams3-vpn-dhcp4740.cisco.com [10.61.82.131]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l28Eu9Ap001453 for <[e-mail]>; Thu, 8 Mar 2007 14:56:13 GMT
Message-ID: <[e-mail]>
Date: Thu, 08 Mar 2007 15:56:09 +0100
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16; t=1173365774; x=1174229774; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20jabber=20starts=20in=205=20mins |Sender:=20; bh=MjBhJMNzV4Xit8qvaHWOui8VcAu7XmrOqd5DhXg4ISg=; b=mZXp1gbcAdQXRyCiHbUNV6y8/05irobV67dTNgfJL4Y6G08vH0++ov/BiqfZ8tscn1uQ3F/4 S08zlEUnQGsseHF41yBFoYGk1Vkht1xeb/Q3eIzsHyH+uqvRsFgSn+MZ;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] jabber starts in 5 mins
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2007 14:57:10 -0000

See you there!


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 130AE7F721 for <[e-mail]>; Wed,  7 Mar 2007 12:21:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8D1B6142250 for <[e-mail]>; Wed,  7 Mar 2007 12:20:44 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14144-05 for <[e-mail]>; Wed, 7 Mar 2007 12:20:44 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by laweleka.osafoundation.org (Postfix) with ESMTP id 27BBD14224D for <[e-mail]>; Wed,  7 Mar 2007 12:20:44 -0800 (PST)
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2007 12:20:44 -0800
X-IronPort-AV: i="4.14,261,1170662400";  d="scan'208"; a="398337369:sNHT47650932"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l27KKgct009477;  Wed, 7 Mar 2007 21:20:42 +0100
Received: from elear-mac.cisco.com (ams3-vpn-dhcp4740.cisco.com [10.61.82.131]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l27KKbAp019737;  Wed, 7 Mar 2007 20:20:37 GMT
Message-ID: <[e-mail]>
Date: Wed, 07 Mar 2007 21:20:37 +0100
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] rrule in timezone components
References: <009101c76010$76e79460$[e-mail]>		<[e-mail]>		<[e-mail]>		<009601c7604a$5f970e50$0202fea9@nigelhome>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=456; t=1173298842; x=1174162842; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20rrule=20in=20timezone=20components |Sender:=20; bh=g9pToNpoguU/fwIYFJ97c+3nJlloj/KZo4+TjxNZp5s=; b=KTu82vxuGsz6q8ZZHP915PUk9NNtZhtF+X4tTMi7xD5V0qiI3W3gzrjIGX5gyPpem0D3W1lW 2v6fZYFJFTFAJK1pa/xC2QM0Fm90uZareGfkv64QsFJv0m2PDfTtikM5;
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 20:21:39 -0000

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 ;-)


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 81DDE7F793 for <[e-mail]>; Wed,  7 Mar 2007 09:26:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 07BF714224C for <[e-mail]>; Wed,  7 Mar 2007 09:26:02 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10356-01 for <[e-mail]>; Wed, 7 Mar 2007 09:25:58 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E9D2B14224B for <[e-mail]>; Wed,  7 Mar 2007 09:25:57 -0800 (PST)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l27HPllS025367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 12:25:49 -0500
Date: Wed, 07 Mar 2007 12:25:42 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] rrule in timezone components
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <009101c76010$76e79460$[e-mail]>	 <[e-mail]>	 <[e-mail]>	 <009601c7604a$5f970e50$0202fea9@nigelhome> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-2.1 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 17:26:57 -0000

Hi Mike,

--On March 6, 2007 11:17:38 PM -0800 Mike Samuel <[e-mail]> 
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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BCF117F53B for <[e-mail]>; Wed,  7 Mar 2007 08:38:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 47D53142249 for <[e-mail]>; Wed,  7 Mar 2007 08:37:57 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10765-01 for <[e-mail]>; Wed, 7 Mar 2007 08:37:56 -0800 (PST)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6203B142247 for <[e-mail]>; Wed,  7 Mar 2007 08:37:56 -0800 (PST)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: dd4e94902897e088d9016b58c44386ec
X-Spam-Score-Summary: 2, 0, 0, 3815f509c71385aa, 42f367296d8970cb, [e-mail], , 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
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigelhome (unverified [10.42.40.205]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <[e-mail]>; Wed, 7 Mar 2007 08:37:55 -0800
Message-ID: <010f01c760d6$fca46ad0$d201a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>
References: <009101c76010$76e79460$[e-mail]> <[e-mail]>	<[e-mail]> <00d101c760cf$dbccfe50$d201a8c0@nigelhome> <[e-mail]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Date: Wed, 7 Mar 2007 16:38:06 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 16:38:52 -0000

> 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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C51F47F6E6 for <[e-mail]>; Wed,  7 Mar 2007 08:02:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4EFAB142249 for <[e-mail]>; Wed,  7 Mar 2007 08:01:19 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09602-10 for <[e-mail]>; Wed, 7 Mar 2007 08:01:18 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8DDC8142247 for <[e-mail]>; Wed,  7 Mar 2007 08:01:18 -0800 (PST)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l27G1Eos024906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 7 Mar 2007 11:01:16 -0500
Date: Wed, 07 Mar 2007 11:01:08 -0500
From: Cyrus Daboo <[e-mail]>
To: [e-mail]
Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-2446bis-03.txt 
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-2.1 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 16:02:13 -0000

Hi folks,

--On March 7, 2007 10:50:02 AM -0500 [e-mail] 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 28C017F6C0 for <[e-mail]>; Wed,  7 Mar 2007 08:00:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A954614224B for <[e-mail]>; Wed,  7 Mar 2007 07:59:31 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09650-05 for <[e-mail]>; Wed, 7 Mar 2007 07:59:31 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CAC1A142249 for <[e-mail]>; Wed,  7 Mar 2007 07:59:30 -0800 (PST)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l27FxMVP024891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 10:59:24 -0500
Date: Wed, 07 Mar 2007 10:59:16 -0500
From: Cyrus Daboo <[e-mail]>
To: Nigel Swinson <[e-mail]>, Eliot Lear <[e-mail]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Message-ID: <[e-mail]>
In-Reply-To: <00d101c760cf$dbccfe50$d201a8c0@nigelhome>
References: <009101c76010$76e79460$[e-mail]> <[e-mail]>	<[e-mail]> <00d101c760cf$dbccfe50$d201a8c0@nigelhome>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-2.1 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 16:00:26 -0000

Hi Nigel,

--On March 7, 2007 3:47:04 PM +0000 Nigel Swinson 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 932917F67F for <[e-mail]>; Wed,  7 Mar 2007 07:52:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1FD7F142249 for <[e-mail]>; Wed,  7 Mar 2007 07:51:14 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09252-09 for <[e-mail]>; Wed, 7 Mar 2007 07:51:13 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 37BA4142247 for <[e-mail]>; Wed,  7 Mar 2007 07:51:13 -0800 (PST)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l27Fp0Xw024852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Mar 2007 10:51:04 -0500
Date: Wed, 07 Mar 2007 10:50:54 -0500
From: Cyrus Daboo <[e-mail]>
To: Eliot Lear <[e-mail]>, George Sexton <[e-mail]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <009101c76010$76e79460$[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-2.1 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 15:52:08 -0000

Hi Eliot,

--On March 7, 2007 3:26:04 PM +0100 Eliot Lear <[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2BB7A7F67F for <[e-mail]>; Wed,  7 Mar 2007 07:51:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 68AD5142249 for <[e-mail]>; Wed,  7 Mar 2007 07:50:05 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08566-09 for <[e-mail]>; Wed, 7 Mar 2007 07:50:03 -0800 (PST)
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9B033142247 for <[e-mail]>; Wed,  7 Mar 2007 07:50:03 -0800 (PST)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6869826EDC; Wed,  7 Mar 2007 15:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOyOw-0006TT-9L; Wed, 07 Mar 2007 10:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Wed, 07 Mar 2007 10:50:02 -0500
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-2446bis-03.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 15:51:00 -0000

--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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>


--OtherAccess--

--NextPart--



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 53D6E7F67F for <[e-mail]>; Wed,  7 Mar 2007 07:46:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D393D142249 for <[e-mail]>; Wed,  7 Mar 2007 07:46:03 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07061-09 for <[e-mail]>; Wed, 7 Mar 2007 07:46:03 -0800 (PST)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4E277142247 for <[e-mail]>; Wed,  7 Mar 2007 07:46:03 -0800 (PST)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 4ee9155f2224d7578012dfcf57040542
X-Spam-Score-Summary: 2, 0, 0, 68b26f9a35d5437e, 42f367296d8970cb, [e-mail], , 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
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigelhome (unverified [10.42.40.205]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <[e-mail]>; Wed, 7 Mar 2007 07:46:02 -0800
Message-ID: <00d101c760cf$dbccfe50$d201a8c0@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Eliot Lear" <[e-mail]>
References: <009101c76010$76e79460$[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Date: Wed, 7 Mar 2007 15:47:04 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 15:46:58 -0000

> 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?


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A5B667F586 for <[e-mail]>; Wed,  7 Mar 2007 06:27:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 31BB1142249 for <[e-mail]>; Wed,  7 Mar 2007 06:26:11 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09202-02 for <[e-mail]>; Wed, 7 Mar 2007 06:26:10 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 73C25142247 for <[e-mail]>; Wed,  7 Mar 2007 06:26:10 -0800 (PST)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Mar 2007 15:26:10 +0100
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l27EQ9Q0030750;  Wed, 7 Mar 2007 15:26:09 +0100
Received: from elear-mac.cisco.com (ams3-vpn-dhcp363.cisco.com [10.61.65.107]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l27EQ4Ap015395; Wed, 7 Mar 2007 14:26:08 GMT
Message-ID: <[e-mail]>
Date: Wed, 07 Mar 2007 15:26:04 +0100
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: George Sexton <[e-mail]>
Subject: Re: [Ietf-calsify] rrule in timezone components
References: <009101c76010$76e79460$[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=956; t=1173277569; x=1174141569; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20Re=3A=20[Ietf-calsify]=20rrule=20in=20timezone=20components |Sender:=20; bh=/WpsP//0NuSuJciSOySqN9BCaJEn+r4jU3EPDOvXCKw=; b=rgKh43BQ9wlj7Rj+YXP3sEnIVe36Q6BHUCvC+LAyu+T5Q/6FAmAZwVq75Q8gCQg5OQG+kbJe u1C0VPcTD6ybwehg0HHtX066nsNHj46z9JuCjo/6yXM9RAGx2h8Jih2q;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 14:27:05 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 42C637F5AB for <[e-mail]>; Tue,  6 Mar 2007 23:18:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C14B3142249 for <[e-mail]>; Tue,  6 Mar 2007 23:17:42 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02852-08 for <[e-mail]>; Tue, 6 Mar 2007 23:17:41 -0800 (PST)
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by laweleka.osafoundation.org (Postfix) with ESMTP id DA2C814221E for <[e-mail]>; Tue,  6 Mar 2007 23:17:40 -0800 (PST)
Received: by mu-out-0910.google.com with SMTP id w9so72365mue for <[e-mail]>; Tue, 06 Mar 2007 23:17:39 -0800 (PST)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ecLMmio9nvv8cG3R7mp2bdhrZHprPOF3xbwwQrHcerHFLHql3iEBkZWV24Lu6DRda+U30KkcRwmdeuwVPgX4V40+7JAvjltT4CKs+a4Y4+SarvfbGpnyB128yt99PNBXNgeX+7Lz5MGHkF0BAsx+RNFY3jGECv4NJWP81XqcynI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F0uT1ON1uKKdWDW0i+CHXpmrBX93uSYhwWRRs2bJnMDGtb/kbLiFHitrDG5w+r8NA/bmXneiC4kYk1a9+o5yMbZCdY/Tay6ruB7GoXUziRsP9sbg8YGFb9vldDGdlRDhFz3tV0eHwfO/W61HOuyC8Lwlhpf7KPM0tBGzIOvhyuA=
Received: by 10.82.152.16 with SMTP id z16mr8622382bud.1173251858977; Tue, 06 Mar 2007 23:17:38 -0800 (PST)
Received: by 10.82.157.8 with HTTP; Tue, 6 Mar 2007 23:17:38 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 6 Mar 2007 23:17:38 -0800
From: "Mike Samuel" <[e-mail]>
To: "Nigel Swinson" <[e-mail]>
Subject: Re: [Ietf-calsify] rrule in timezone components
In-Reply-To: <009601c7604a$5f970e50$0202fea9@nigelhome>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <009101c76010$76e79460$[e-mail]> <[e-mail]> <[e-mail]> <009601c7604a$5f970e50$0202fea9@nigelhome>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=1.2 tagged_above=-50.0 required=4.0 tests=MISSING_SUBJECT
X-Spam-Level: *
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2007 07:18:37 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2F7137FA26 for <[e-mail]>; Tue,  6 Mar 2007 15:52:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AC6BA14224C for <[e-mail]>; Tue,  6 Mar 2007 15:51:20 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32749-02 for <[e-mail]>; Tue, 6 Mar 2007 15:51:19 -0800 (PST)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3F4D914224B for <[e-mail]>; Tue,  6 Mar 2007 15:51:19 -0800 (PST)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 98380a6508946c8574edf11bd85f821e
X-Spam-Score-Summary: 50, 0, 0, cda0d20d666c7afb, 42f367296d8970cb, [e-mail], , 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
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigelhome (unverified [10.42.24.205]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <[e-mail]>; Tue, 6 Mar 2007 15:51:18 -0800
Message-ID: <009601c7604a$5f970e50$0202fea9@nigelhome>
From: "Nigel Swinson" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>, "George Sexton" <[e-mail]>
References: <009101c76010$76e79460$[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Date: Tue, 6 Mar 2007 23:51:32 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 23:52:15 -0000

> 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




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 68DB27F8FA for <[e-mail]>; Tue,  6 Mar 2007 11:51:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E6958142253 for <[e-mail]>; Tue,  6 Mar 2007 11:50:35 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29682-02 for <[e-mail]>; Tue, 6 Mar 2007 11:50:34 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 0C5B9142250 for <[e-mail]>; Tue,  6 Mar 2007 11:50:33 -0800 (PST)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l26JoP5o020846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 14:50:28 -0500
Date: Tue, 06 Mar 2007 14:50:20 -0500
From: Cyrus Daboo <[e-mail]>
To: George Sexton <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] rrule in timezone components
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <009101c76010$76e79460$[e-mail]> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-2.1 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 19:51:30 -0000

Hi George,

--On March 6, 2007 12:34:50 PM -0700 George Sexton <[e-mail]> 
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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 176837F724 for <[e-mail]>; Tue,  6 Mar 2007 11:35:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 848A3142254 for <[e-mail]>; Tue,  6 Mar 2007 11:34:55 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29208-04 for <[e-mail]>; Tue, 6 Mar 2007 11:34:54 -0800 (PST)
Received: from mail.mhsoftware.com (mail.mhsoftware.com [216.17.130.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EAF0E142250 for <[e-mail]>; Tue,  6 Mar 2007 11:34:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.mhsoftware.com (Postfix) with ESMTP id B870229AED89 for <[e-mail]>; Tue,  6 Mar 2007 12:34:51 -0700 (MST)
Received: from mail.mhsoftware.com ([127.0.0.1]) by localhost (hagrid [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19714-07 for <[e-mail]>; Tue,  6 Mar 2007 12:34:51 -0700 (MST)
Received: from [192.168.0.254] (c-24-8-34-101.hsd1.co.comcast.net [24.8.34.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mhsoftware.com (Postfix) with ESMTP id 23866290FFD0 for <[e-mail]>; Tue,  6 Mar 2007 12:34:51 -0700 (MST)
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2007 12:34:50 -0700
From: George Sexton <[e-mail]>
Organization: MH Software, Inc.
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] rrule in timezone components
References: <009101c76010$76e79460$[e-mail]>
In-Reply-To: <009101c76010$76e79460$[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at mhsoftware.com
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 19:35:50 -0000

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: [phone]
URL:   http://www.mhsoftware.com/



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9BFF37F956 for <[e-mail]>; Tue,  6 Mar 2007 10:36:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 25292142253 for <[e-mail]>; Tue,  6 Mar 2007 10:35:20 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27941-08 for <[e-mail]>; Tue, 6 Mar 2007 10:35:19 -0800 (PST)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7646B142250 for <[e-mail]>; Tue,  6 Mar 2007 10:35:19 -0800 (PST)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: a5eb104e72bc0f0a910c6d0991e74a32
X-Spam-Score-Summary: 2, 0, 0, fbd99ed10e8a4641, 42f367296d8970cb, [e-mail], , 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
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigel (unverified [10.42.44.110]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <[e-mail]>; Tue, 6 Mar 2007 10:35:17 -0800
Message-ID: <00b901c7601e$30024910$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: "Cyrus Daboo" <[e-mail]>
References: <009101c76010$76e79460$[e-mail]> <[e-mail]>
Subject: Re: [Ietf-calsify] rrule in timezone components
Date: Tue, 6 Mar 2007 18:35:15 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 18:36:14 -0000

> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A76B97F943 for <[e-mail]>; Tue,  6 Mar 2007 09:46:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30D33142255 for <[e-mail]>; Tue,  6 Mar 2007 09:45:38 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27041-04 for <[e-mail]>; Tue, 6 Mar 2007 09:45:36 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3F848142250 for <[e-mail]>; Tue,  6 Mar 2007 09:45:36 -0800 (PST)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l26HjSFZ020474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2007 12:45:31 -0500
Date: Tue, 06 Mar 2007 12:45:23 -0500
From: Cyrus Daboo <[e-mail]>
To: Nigel Swinson <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] rrule in timezone components
Message-ID: <[e-mail]>
In-Reply-To: <009101c76010$76e79460$[e-mail]>
References: <009101c76010$76e79460$[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-2.1 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 17:46:33 -0000

Hi Nigel,

--On March 6, 2007 4:57:01 PM +0000 Nigel Swinson 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C92767F8FA for <[e-mail]>; Tue,  6 Mar 2007 08:58:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 13733142255 for <[e-mail]>; Tue,  6 Mar 2007 08:57:10 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27267-06 for <[e-mail]>; Tue, 6 Mar 2007 08:57:08 -0800 (PST)
Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3E44E142250 for <[e-mail]>; Tue,  6 Mar 2007 08:57:08 -0800 (PST)
X-Spam-Score-scoring_explanation: 
X-Spam-Score-spf_status: 
X-Spam-Score-Spamcatcher1: 8047113ce6464ba2fb6544b237384d2b
X-Spam-Score-Summary: 2, 0, 0, 3e6761cbf8309b3b, 4c409de4df48254b, [e-mail], , 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
X-Spam-Score-Countries: 
X-Spam-Score-Charsets: iso-8859-1
Received: from nigel (unverified [10.42.44.110]) by mail.rockliffe.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <[e-mail]> for <[e-mail]>; Tue, 6 Mar 2007 08:57:03 -0800
Message-ID: <009101c76010$76e79460$[e-mail]>
From: "Nigel Swinson" <[e-mail]>
To: <[e-mail]>
Date: Tue, 6 Mar 2007 16:57:01 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] rrule in timezone components
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 16:58:06 -0000

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 



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D6E347F68F for <[e-mail]>; Tue,  6 Mar 2007 06:49:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6239A142253 for <[e-mail]>; Tue,  6 Mar 2007 06:48:24 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25378-05 for <[e-mail]>; Tue, 6 Mar 2007 06:48:22 -0800 (PST)
Received: from mgw-ext14.nokia.com (smtp.nokia.com [131.228.20.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4BBA614224C for <[e-mail]>; Tue,  6 Mar 2007 06:48:22 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l26ElxCC000616; Tue, 6 Mar 2007 16:48:19 +0200
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Mar 2007 16:47:59 +0200
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 16:47:59 +0200
Received: from [172.21.40.82] (esdhcp04082.research.nokia.com [172.21.40.82]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l26ElvxO019578; Tue, 6 Mar 2007 16:47:57 +0200
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2007 16:47:56 +0200
From: Aki Niemi <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: ext Jay Batson <[e-mail]>
Subject: Re: [Ietf-calsify] Issues with Security / Spoofing section
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Mar 2007 14:47:59.0359 (UTC) FILETIME=[6F1900F0:01C75FFE]
X-Nokia-AV: Clean
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.3 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: Calsify WG <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 14:49:19 -0000

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
> [e-mail]
> [phone] (w)
> [phone] (m)
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0E7CF7F62C for <[e-mail]>; Tue,  6 Mar 2007 06:01:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8D80B142253 for <[e-mail]>; Tue,  6 Mar 2007 06:00:25 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25094-02 for <[e-mail]>; Tue, 6 Mar 2007 06:00:24 -0800 (PST)
Received: from mgw-ext12.nokia.com (smtp.nokia.com [131.228.20.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id CB518142250 for <[e-mail]>; Tue,  6 Mar 2007 06:00:23 -0800 (PST)
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l26DxilZ022429 for <[e-mail]>; Tue, 6 Mar 2007 16:00:18 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Mar 2007 15:59:34 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 6 Mar 2007 15:59:35 +0200
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Mar 2007 15:59:34 +0200
Received: from [172.21.40.82] (esdhcp04082.research.nokia.com [172.21.40.82]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l26DxVxo001994 for <[e-mail]>; Tue, 6 Mar 2007 15:59:33 +0200
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2007 15:59:29 +0200
From: Aki Niemi <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Mar 2007 13:59:34.0787 (UTC) FILETIME=[ABD67D30:01C75FF7]
X-Nokia-AV: Clean
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.3 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] Draft agenda for IETF68
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 14:01:20 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 912FA7F62F for <[e-mail]>; Tue,  6 Mar 2007 05:42:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1BE1C142253 for <[e-mail]>; Tue,  6 Mar 2007 05:41:51 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23754-09 for <[e-mail]>; Tue, 6 Mar 2007 05:41:49 -0800 (PST)
Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 61CC4142250 for <[e-mail]>; Tue,  6 Mar 2007 05:41:49 -0800 (PST)
Received: from rgmgw3.us.oracle.com (rgmgw3.us.oracle.com [138.1.186.112]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l26Dfk6e013780 for <[e-mail]>; Tue, 6 Mar 2007 07:41:47 -0600
Received: from rcsmt250.oracle.com (rcsmt250.oracle.com [148.87.90.195]) by rgmgw3.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l26DJT4Q019917 for <[e-mail]>; Tue, 6 Mar 2007 06:41:45 -0700
Received: from bdesruis-ca.ca.oracle.com by rcsmt251.oracle.com with ESMTP id 2497933781173188491; Tue, 06 Mar 2007 06:41:31 -0700
Message-ID: <[e-mail]>
Date: Tue, 06 Mar 2007 08:40:59 -0500
From: Bernard Desruisseaux <[e-mail]>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-06.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Whitelist: TRUE
X-Whitelist: TRUE
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2007 13:42:45 -0000

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


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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8D9677F648 for <[e-mail]>; Mon,  5 Mar 2007 12:50:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E22514224D for <[e-mail]>; Mon,  5 Mar 2007 12:50:05 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15586-01 for <[e-mail]>; Mon, 5 Mar 2007 12:50:04 -0800 (PST)
Received: from ns1.neustar.com (ns1.neustar.com [156.154.16.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 489C214224B for <[e-mail]>; Mon,  5 Mar 2007 12:50:04 -0800 (PST)
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id DAB3726EBD; Mon,  5 Mar 2007 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8A-0005eg-Jp; Mon, 05 Mar 2007 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
From: [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 05 Mar 2007 15:50:02 -0500
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.6 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-06.txt 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2007 20:50:59 -0000

--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 
[e-mail] 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:
	[e-mail].
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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>


--OtherAccess--

--NextPart--



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F2A2B7FC46 for <[e-mail]>; Thu,  1 Mar 2007 12:10:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 791CE14225A for <[e-mail]>; Thu,  1 Mar 2007 12:09:51 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05339-09 for <[e-mail]>; Thu, 1 Mar 2007 12:09:51 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id DAAFA142256 for <[e-mail]>; Thu,  1 Mar 2007 12:09:50 -0800 (PST)
Received: from metro-north.cs.columbia.edu (metro-north.cs.columbia.edu [128.59.19.61]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l21K623h026426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 1 Mar 2007 15:09:47 -0500 (EST)
Received: from metro-north.cs.columbia.edu (localhost [127.0.0.1]) by metro-north.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l21Jnlxn013164 for <[e-mail]>; Thu, 1 Mar 2007 14:49:47 -0500 (EST)
Received: (from lennox@localhost) by metro-north.cs.columbia.edu (8.12.10/8.12.10/Submit) id l21JnlfA013161; Thu, 1 Mar 2007 14:49:47 -0500 (EST)
X-Authentication-Warning: metro-north.cs.columbia.edu: lennox set sender to [e-mail] using -f
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 1 Mar 2007 14:49:47 -0500
To: [e-mail]
Subject: Re: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <00ab01c75b92$27523400$d201a8c0@nigelhome> <[e-mail]> <[e-mail]>
X-Mailer: VM 7.19 under Emacs 20.7.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.8 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2007 20:10:46 -0000

On Thursday, March 1 2007, "Jeffrey Harris" wrote to "[e-mail]" 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
[e-mail]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 248377FB8E for <[e-mail]>; Thu,  1 Mar 2007 11:47:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 96EBB14224D for <[e-mail]>; Thu,  1 Mar 2007 11:46:26 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06032-05 for <[e-mail]>; Thu, 1 Mar 2007 11:46:26 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 04A2B14224C for <[e-mail]>; Thu,  1 Mar 2007 11:46:25 -0800 (PST)
Received: from metro-north.cs.columbia.edu (metro-north.cs.columbia.edu [128.59.19.61]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l21Jgg3h021279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 1 Mar 2007 14:43:49 -0500 (EST)
Received: from metro-north.cs.columbia.edu (localhost [127.0.0.1]) by metro-north.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l21Jggxn013147 for <[e-mail]>; Thu, 1 Mar 2007 14:42:42 -0500 (EST)
Received: (from lennox@localhost) by metro-north.cs.columbia.edu (8.12.10/8.12.10/Submit) id l21JggS4013144; Thu, 1 Mar 2007 14:42:42 -0500 (EST)
X-Authentication-Warning: metro-north.cs.columbia.edu: lennox set sender to [e-mail] using -f
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 1 Mar 2007 14:42:42 -0500
To: <[e-mail]>
Subject: Re-wording of issue 27 consensus (Re: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <00ab01c75b92$27523400$d201a8c0@nigelhome> <[e-mail]>
X-Mailer: VM 7.19 under Emacs 20.7.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.8 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2007 19:47:21 -0000

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 "<[e-mail]>" 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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7F3917FC1B for <[e-mail]>; Thu,  1 Mar 2007 11:44:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 06BF414224D for <[e-mail]>; Thu,  1 Mar 2007 11:43:57 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05579-10 for <[e-mail]>; Thu, 1 Mar 2007 11:43:54 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4354014224C for <[e-mail]>; Thu,  1 Mar 2007 11:43:54 -0800 (PST)
Received: from metro-north.cs.columbia.edu (metro-north.cs.columbia.edu [128.59.19.61]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l21JdN3h020643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 1 Mar 2007 14:43:49 -0500 (EST)
Received: from metro-north.cs.columbia.edu (localhost [127.0.0.1]) by metro-north.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l21JdMxn013062 for <[e-mail]>; Thu, 1 Mar 2007 14:39:23 -0500 (EST)
Received: (from lennox@localhost) by metro-north.cs.columbia.edu (8.12.10/8.12.10/Submit) id l21JdMTh013059; Thu, 1 Mar 2007 14:39:22 -0500 (EST)
X-Authentication-Warning: metro-north.cs.columbia.edu: lennox set sender to [e-mail] using -f
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 1 Mar 2007 14:39:22 -0500
To: <[e-mail]>
Subject: Proposed resolution of issue 70 (was Re: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <00ab01c75b92$27523400$d201a8c0@nigelhome> <[e-mail]>
X-Mailer: VM 7.19 under Emacs 20.7.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2007 19:44:52 -0000

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 "<[e-mail]>" 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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 205587FB8D for <[e-mail]>; Thu,  1 Mar 2007 11:44:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A1E0614224D for <[e-mail]>; Thu,  1 Mar 2007 11:43:55 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06744-08 for <[e-mail]>; Thu, 1 Mar 2007 11:43:54 -0800 (PST)
Received: from mulberrymail.com (static-71-240-120-213.pitt.east.verizon.net [71.240.120.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A9551142266 for <[e-mail]>; Thu,  1 Mar 2007 11:43:54 -0800 (PST)
Received: from caldav.corp.apple.com (A17-101-32-44.apple.com [17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id l21JX52q020003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Mar 2007 14:33:06 -0500
Date: Thu, 01 Mar 2007 14:32:59 -0500
From: Cyrus Daboo <[e-mail]>
To: Jonathan Lennox <[e-mail]>, [e-mail]
Subject: Re: [Ietf-calsify] Resolutions of issues 8,	68 and 69: DST discontinuities
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <00ab01c75b92$27523400$d201a8c0@nigelhome> <[e-mail]>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.1 tagged_above=-50.0 required=4.0 tests=ALL_TRUSTED, AWL, MISSING_SUBJECT
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2007 19:44:50 -0000

Hi Jonathan,

--On March 1, 2007 12:27:50 PM -0500 Jonathan Lennox 
<[e-mail]> 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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D73CB7FBBD for <[e-mail]>; Thu,  1 Mar 2007 10:12:51 -0800 (PST)
Received: from [192.168.0.129] (c-69-181-148-207.hsd1.ca.comcast.net [69.181.148.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4E7B7142250 for <[e-mail]>; Thu,  1 Mar 2007 10:11:57 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 01 Mar 2007 10:11:46 -0800
From: Jeffrey Harris <[e-mail]>
User-Agent: Thunderbird 1.4.1 (Windows/20051006)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities
References: <[e-mail]>	<[e-mail]>	<00ab01c75b92$27523400$d201a8c0@nigelhome> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2007 18:12:52 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0B2667FA2F for <[e-mail]>; Thu,  1 Mar 2007 09:54:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8D029142270 for <[e-mail]>; Thu,  1 Mar 2007 09:53:34 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04652-09 for <[e-mail]>; Thu, 1 Mar 2007 09:53:34 -0800 (PST)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D240A14226E for <[e-mail]>; Thu,  1 Mar 2007 09:53:33 -0800 (PST)
Received: from metro-north.cs.columbia.edu (metro-north.cs.columbia.edu [128.59.19.61]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l21Hp23h021724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Thu, 1 Mar 2007 12:53:31 -0500 (EST)
Received: from metro-north.cs.columbia.edu (localhost [127.0.0.1]) by metro-north.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l21HRoxn012605 for <[e-mail]>; Thu, 1 Mar 2007 12:27:59 -0500 (EST)
Received: (from lennox@localhost) by metro-north.cs.columbia.edu (8.12.10/8.12.10/Submit) id l21HRoHh012602; Thu, 1 Mar 2007 12:27:50 -0500 (EST)
X-Authentication-Warning: metro-north.cs.columbia.edu: lennox set sender to [e-mail] using -f
From: Jonathan Lennox <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Thu, 1 Mar 2007 12:27:50 -0500
To: <[e-mail]>
In-Reply-To: <00ab01c75b92$27523400$d201a8c0@nigelhome>
References: <[e-mail]> <[e-mail]> <00ab01c75b92$27523400$d201a8c0@nigelhome>
X-Mailer: VM 7.19 under Emacs 20.7.1
X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter2.cs.columbia.edu
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.7 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] Resolutions of issues 8, 68 and 69: DST discontinuities
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2007 17:54:29 -0000

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


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EE7A57FA2F for <[e-mail]>; Thu,  1 Mar 2007 07:02:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6DC6B142269 for <[e-mail]>; Thu,  1 Mar 2007 07:01:41 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02151-08 for <[e-mail]>; Thu, 1 Mar 2007 07:01:40 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by laweleka.osafoundation.org (Postfix) with ESMTP id 03014142266 for <[e-mail]>; Thu,  1 Mar 2007 07:01:39 -0800 (PST)
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-5.cisco.com with ESMTP; 01 Mar 2007 07:01:39 -0800
X-IronPort-AV: i="4.14,234,1170662400";  d="scan'208"; a="395435784:sNHT37204448"
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l21F1b2T023118 for <[e-mail]>; Thu, 1 Mar 2007 16:01:37 +0100
Received: from elear-mac.cisco.com (ams3-vpn-dhcp85.cisco.com [10.61.64.85]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l21F1bC8014688 for <[e-mail]>; Thu, 1 Mar 2007 16:01:37 +0100 (MET)
Message-ID: <[e-mail]>
Date: Thu, 01 Mar 2007 16:01:37 +0100
From: Eliot Lear <[e-mail]>
User-Agent: Thunderbird 2.0b2 (Macintosh/20070116)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=25; t=1172761298; x=1173625298; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=[e-mail]; z=From:=20Eliot=20Lear=20<[e-mail]> |Subject:=20jabber=20chat=20starts=20now! |Sender:=20; bh=6CVPxcLSiaE3VU2Xzd9YUIVDthiKSoWdy9ZfiHd0jAI=; b=aZJHW+VzJyvuqP5zoio2OatsxO/Kf6cDYbvYBkohkEU8DRcrG9flPm5Ba2U0pEozagF/WXYP pkpdEZv1hnuLRETQF4250/D85EIg1k7TE6x2i4pWaupKGezp0ORI5jEY;
Authentication-Results: ams-dkim-2; header.From=[e-mail]; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); 
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.5 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Subject: [Ietf-calsify] jabber chat starts now!
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2007 15:02:36 -0000

[e-mail]


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2DDAE7FA50 for <[e-mail]>; Thu,  1 Mar 2007 05:28:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A612D14226C for <[e-mail]>; Thu,  1 Mar 2007 05:27:23 -0800 (PST)
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02066-06 for <[e-mail]>; Thu, 1 Mar 2007 05:27:23 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id E404F14226B for <[e-mail]>; Thu,  1 Mar 2007 05:27:22 -0800 (PST)
Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <[e-mail]>; Thu, 1 Mar 2007 13:27:21 +0000
Message-ID: <[e-mail]>
Date: Thu, 01 Mar 2007 13:26:45 +0000
From: Alexey Melnikov <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cyrus Daboo <[e-mail]>
Subject: Re: [Ietf-calsify] More references to 2446?
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=AWL, MISSING_SUBJECT
X-Spam-Level: 
Cc: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RFC2445, 2446 and 2447 Discusions" <ietf-calsify.osafoundation.org>
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2007 13:28:23 -0000

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.