From ietf-calsify-bounces@osafoundation.org Sun Dec 02 21:01:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz0cM-0006Dw-71 for calsify-archive-Feit0ahl@lists.ietf.org; Sun, 02 Dec 2007 21:01:06 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz0cL-00010i-9j for calsify-archive-Feit0ahl@lists.ietf.org; Sun, 02 Dec 2007 21:01:06 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 2E7CD8094B; Sun, 2 Dec 2007 18:01:02 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F3129808F6 for ; Sun, 2 Dec 2007 18:01:00 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DE84C142202 for ; Sun, 2 Dec 2007 18:01:01 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-50 required=4 tests=[AWL=0.246, BAYES_00=-2.599, HTML_00_10=0.795, HTML_MESSAGE=0.001] 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 jT4VWZJNfWiY for ; Sun, 2 Dec 2007 18:00:56 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8F8AC1421FF for ; Sun, 2 Dec 2007 18:00:56 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j40so5107568wah for ; Sun, 02 Dec 2007 18:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=jDew9kOx5N7rq7E+a891fyk3jNh15lXThva/t+S2YcM=; b=RYzIXgUc+m0y104S5ScAafJ00KN7eJb8e0/EeOph9K4Ww6KB/96G2LtJQvULF0FRB2g6U0l775kK9gI5pOZWGc6GamqxQQtRKilenTTlXkjkn7ygAvrE5rkuSb4SLWydV+d69HXOWC9ZdmbSCPYRL/5PgMLhL2MTwL/aXUGwuak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:mime-version:content-type; b=UZ807QKr2cUjSAT/NolL9We/jRS4hf81a53xNf2e8L3oEyUhOIl4fxJmUZ9bunwsDh7rYgEIKv5hvrjAEhpKIBGK4qRAj49MN0qhJkhYJiIpyyw1AtM8Ubywww2/95nAWmY17jUnXwlGf8qGzMBVL4BfRuOhKwxHutwS2C7wCEE= Received: by 10.142.171.6 with SMTP id t6mr276178wfe.1196645604175; Sun, 02 Dec 2007 17:33:24 -0800 (PST) Received: by 10.142.49.6 with HTTP; Sun, 2 Dec 2007 17:33:24 -0800 (PST) Message-ID: Date: Sun, 2 Dec 2007 22:33:24 -0300 From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" To: "ietf-calsify@osafoundation.org" MIME-Version: 1.0 Subject: [Ietf-calsify] Patterns on restriction tables for 2446bis X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0173167820==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 --===============0173167820== Content-Type: multipart/alternative; boundary="----=_Part_6579_26767612.1196645604165" ------=_Part_6579_26767612.1196645604165 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, There is not a clear pattern on the order of the properties and components (lexicographic / by presence), or on the text of the comments among the several restriction tables that describe iTIP methods (similar behaviors ar= e described in different ways). Is there any intention of organizing the restriction tables in this sense? Regards, F=E1bio Silva. ------=_Part_6579_26767612.1196645604165 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all,

There is not a clear pattern on the order of the properties = and components (lexicographic / by presence), or on the text of the comment= s among the several restriction tables that describe iTIP methods (similar = behaviors are described in different ways).
Is there any intention of organizing the restriction tables in this sen= se?

Regards,

F=E1bio Silva.
------=_Part_6579_26767612.1196645604165-- --===============0173167820== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============0173167820==-- From ietf-calsify-bounces@osafoundation.org Mon Dec 03 19:02:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLEf-00035v-E7 for calsify-archive-Feit0ahl@lists.ietf.org; Mon, 03 Dec 2007 19:02:01 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzLEe-0001jd-Gt for calsify-archive-Feit0ahl@lists.ietf.org; Mon, 03 Dec 2007 19:02:01 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id B42BF80CA3; Mon, 3 Dec 2007 16:01:54 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B63FE80CAC for ; Mon, 3 Dec 2007 16:01:53 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A1B58142206 for ; Mon, 3 Dec 2007 16:01:54 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-50 required=4 tests=[AWL=0.239, BAYES_00=-2.599] 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 loUOKuOr3S1a for ; Mon, 3 Dec 2007 16:01:30 -0800 (PST) Received: from andrew.triumf.ca (andrew.triumf.ca [142.90.106.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EA4EA142209 for ; Mon, 3 Dec 2007 16:01:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by andrew.triumf.ca (8.12.11.20060308/8.12.8) with ESMTP id lB401S0x022024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Dec 2007 16:01:28 -0800 Date: Mon, 3 Dec 2007 16:01:28 -0800 (PST) From: Andrew Daviel X-X-Sender: andrew@andrew.triumf.ca To: ietf-calsify@osafoundation.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Ietf-calsify] Future-proofing VTIMEZONE X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Apologies if this has been hammered to death already... I just joined, and grepping archives for an unknown keyword is not always fruitful I've been trying to write a CalDAV server for Mozilla clients (OK, according to the RFC it's not one because it doesn't implement all the mandatory stuff..). I notice that events in 2445 are tagged with a TZID (I was a bit slow realizing why; why not just translate everything to UTC). I presume the intention is that repeating events (10:00 every Wednesday) should be maintained in correct local time, regardless of DST changes. But as I understand it, VTIMEZONE (at least in the Mozilla clients) contains only the DST rules currently in effect (I admit, predicting future rules is impossible and though Dr. Who might schedule meetings in the past, most people don't). So if the rules change, pre-existing repeating events will be wrong. (In Canada/USA, we just went through an annoying and pointless (from an IT point of view) rule change, and the US law leaves open the possibility of putting it all back how it was if no-one saves energy. And Australia as I recall made a special change for the 2000 Olymics. So this is not an unlikely scenario.) So VTIMEZONE doesn't really work. It would seem more useful to use some defined list of timezones, e.g. Pozix or O/S system rules which hopefully get updated, and then repeating events would be future-proofed against most rule changes, not just for known DST transistions. (Locations might still hop from one zone to another, e.g. a certain locality suddenly decides to opt out of its parent zone's DST) Perhaps the optional TZURL element is a solution to this. if so, how many people are actually implementing it ? -- Andrew Daviel, TRIUMF, Canada Tel. +1 (604) 222-7376 (Pacific Time) Network Security Manager _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Mon Dec 03 22:50:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzOnj-0004va-Bp for calsify-archive-Feit0ahl@lists.ietf.org; Mon, 03 Dec 2007 22:50:27 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzOng-0006vT-VO for calsify-archive-Feit0ahl@lists.ietf.org; Mon, 03 Dec 2007 22:50:27 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id B777C80BB5; Mon, 3 Dec 2007 19:50:23 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 05E02808BE for ; Mon, 3 Dec 2007 19:50:23 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EF99814220C for ; Mon, 3 Dec 2007 19:50:23 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-50 required=4 tests=[AWL=0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 EeA1kcuMPiya for ; Mon, 3 Dec 2007 19:50:18 -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 1EC7D1421F1 for ; Mon, 3 Dec 2007 19:50:17 -0800 (PST) Received: from [75.111.50.119] (helo=[192.168.0.102]) by redwood.morsemedia.net with esmtpa (Exim 4.68) (envelope-from ) id 1IzOnc-0004EZ-SD; Mon, 03 Dec 2007 19:50:21 -0800 Message-ID: <4754CE7B.607@calconnect.org> Date: Mon, 03 Dec 2007 19:50:19 -0800 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ietf-calsify list Subject: Re: [Ietf-calsify] Future-proofing VTIMEZONE References: In-Reply-To: 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 - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1795021441==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 This is a multi-part message in MIME format. --===============1795021441== Content-Type: multipart/alternative; boundary="------------040607070302040107030309" This is a multi-part message in MIME format. --------------040607070302040107030309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Andrew, You might take a look at http://www.calconnect.org/publications/icalendartimezoneproblemsandrecomm= endationsv1.0.pdf http://www.calconnect.org/publications/timezoneregistryandservicerecommen= dationsv1.0.pdf http://www.calconnect.org/tc-timezone.shtml Cheers, Dave Thewlis Andrew Daviel wrote: > > Apologies if this has been hammered to death already... I just joined,=20 > and grepping archives for an unknown keyword is not always fruitful > > I've been trying to write a CalDAV server for Mozilla clients (OK,=20 > according to the RFC it's not one because it doesn't implement all the=20 > mandatory stuff..). > > I notice that events in 2445 are tagged with a TZID (I was a bit slow=20 > realizing why; why not just translate everything to UTC). > > I presume the intention is that repeating events (10:00 every=20 > Wednesday) should be maintained in correct local time, regardless of=20 > DST changes. But as I understand it, VTIMEZONE (at least in the=20 > Mozilla clients) contains only the DST rules currently in effect (I=20 > admit, predicting future rules is impossible and though Dr. Who might=20 > schedule meetings in the past, most people don't). So if the rules=20 > change, pre-existing repeating events will be wrong. (In Canada/USA,=20 > we just went through an annoying and pointless (from an IT point of=20 > view) rule change, and the US law leaves open the possibility of=20 > putting it all back how it was if no-one saves energy. And Australia=20 > as I recall made a special change for the 2000 Olymics. So this is not=20 > an unlikely scenario.) > > So VTIMEZONE doesn't really work. It would seem more useful to use=20 > some defined list of timezones, e.g. Pozix or O/S system rules which=20 > hopefully get updated, and then repeating events would be=20 > future-proofed against most rule changes, not just for known DST=20 > transistions. (Locations might still hop from one zone to another,=20 > e.g. a certain locality suddenly decides to opt out of its parent=20 > zone's DST) > > Perhaps the optional TZURL element is a solution to this. > if so, how many people are actually implementing it ? > --=20 *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) =B7 +1 707 498 2238 (mobile) http://www.calconnect.org =B7 Dave.Thewlis@calconnect.org=20 --------------040607070302040107030309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andrew,

You might take a look at

http://www.calconnect.org/publications/icalendartimezoneproblemsandrecommendationsv1.0.pdf

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

http://www.calconnect.org/tc-timezone.shtml

Cheers,

Dave Thewlis


Andrew Daviel wrote:

Apologies if this has been hammered to death already... I just joined, and grepping archives for an unknown keyword is not always fruitful

I've been trying to write a CalDAV server for Mozilla clients (OK, according to the RFC it's not one because it doesn't implement all the mandatory stuff..).

I notice that events in 2445 are tagged with a TZID (I was a bit slow realizing why; why not just translate everything to UTC).

I presume the intention is that repeating events (10:00 every Wednesday) should be maintained in correct local time, regardless of DST changes. But as I understand it, VTIMEZONE (at least in the Mozilla clients) contains only the DST rules currently in effect (I admit, predicting future rules is impossible and though Dr. Who might schedule meetings in the past, most people don't). So if the rules change, pre-existing repeating events will be wrong. (In Canada/USA, we just went through an annoying and pointless (from an IT point of view) rule change, and the US law leaves open the possibility of putting it all back how it was if no-one saves energy. And Australia as I recall made a special change for the 2000 Olymics. So this is not an unlikely scenario.)

So VTIMEZONE doesn't really work. It would seem more useful to use some defined list of timezones, e.g. Pozix or O/S system rules which hopefully get updated, and then repeating events would be future-proofed against most rule changes, not just for known DST transistions. (Locations might still hop from one zone to another, e.g. a certain locality suddenly decides to opt out of its parent zone's DST)

Perhaps the optional TZURL element is a solution to this.
if so, how many people are actually implementing it ?



--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------040607070302040107030309-- --===============1795021441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============1795021441==-- From ietf-calsify-bounces@osafoundation.org Tue Dec 04 13:54:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izcv2-0003mZ-Ca for calsify-archive-Feit0ahl@lists.ietf.org; Tue, 04 Dec 2007 13:54:56 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izcv1-0000mB-Cl for calsify-archive-Feit0ahl@lists.ietf.org; Tue, 04 Dec 2007 13:54:56 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 372B880CE1; Tue, 4 Dec 2007 10:54:54 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DF49880CDB for ; Tue, 4 Dec 2007 10:54:52 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DE1B6142209 for ; Tue, 4 Dec 2007 10:54:53 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[AWL=0.000, BAYES_00=-2.599] 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 YCMVfICsy14e for ; Tue, 4 Dec 2007 10:54:48 -0800 (PST) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EAD391421FD for ; Tue, 4 Dec 2007 10:54:45 -0800 (PST) Received: from dhcp-14db.ietf70.org (dhcp-14db.ietf70.org [130.129.20.219]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lB4IsbIE017782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 13:54:40 -0500 Date: Tue, 04 Dec 2007 10:54:36 -0800 From: Cyrus Daboo To: Andrew Daviel , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Future-proofing VTIMEZONE Message-ID: In-Reply-To: References: 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-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi Andrew, --On December 3, 2007 4:01:28 PM -0800 Andrew Daviel wrote: > I presume the intention is that repeating events (10:00 every Wednesday) > should be maintained in correct local time, regardless of DST changes. > But as I understand it, VTIMEZONE (at least in the Mozilla clients) > contains only the DST rules currently in effect (I admit, predicting > future rules is impossible and though Dr. Who might schedule meetings in > the past, most people don't). So if the rules change, pre-existing > repeating events will be wrong. (In Canada/USA, we just went through an > annoying and pointless (from an IT point of view) rule change, and the US > law leaves open the possibility of putting it all back how it was if > no-one saves energy. And Australia as I recall made a special change for > the 2000 Olymics. So this is not an unlikely scenario.) > > So VTIMEZONE doesn't really work. It would seem more useful to use some > defined list of timezones, e.g. Pozix or O/S system rules which hopefully > get updated, and then repeating events would be future-proofed against > most rule changes, not just for known DST transistions. (Locations might > still hop from one zone to another, e.g. a certain locality suddenly > decides to opt out of its parent zone's DST) Mostly what you are seeing is a client implementation detail. Its true that some clients truncate the full timezone data to just that portion needed to cover the events they are attached too. Whilst that is OK for those events as they stand at that time, as you note, it breaks if you try to change any of those events to a date outside of the truncated timezone. Other clients do send a complete representation of the timezone with the event data that does cover the future. However, changes to dst rules made in the future will cause a similar problem. To help resolve these issues the Calendaring and Scheduling Consortium (Calconnect) is working on the concept of a standard timezone registry and service that could be used to alleviate many of the current problems. The goals for this are: 1) Provide a standard namespace for timezones names (via an IANA registry). This would allow "formal" standardization of e.g. Olson TZ names, and names from other sources. 2) Define a protocol whereby a client can retrieve timezone data given just the name of a timezone. i.e. timezones can be passed "by reference" instead of "by value" in iCalendar data. 3) Provide a simple update mechanism by which clients can ensure their timezone data caches are up to date with the latest timezone information. Calconnect is still working on the preliminary requirements for this effort. The goal is to bring all this work to the IETF for formal specifications in an appropriate venue. Note that right now the focus of the Calsify WG is to revise the current specs, so we are all focussing on completing that work right now. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Dec 05 16:23:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01iZ-00044J-D4 for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 05 Dec 2007 16:23:43 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J01iW-0004ci-Mu for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 05 Dec 2007 16:23:43 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 74F0A80C39; Wed, 5 Dec 2007 13:23:39 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3BFFB80C04 for ; Wed, 5 Dec 2007 13:23:34 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 46C5E1422FB for ; Wed, 5 Dec 2007 13:23:35 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-50 required=4 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 DhfSeOq3UvmI for ; Wed, 5 Dec 2007 13:23:29 -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 84A25142212 for ; Wed, 5 Dec 2007 13:23:29 -0800 (PST) Received: from [75.111.50.119] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.68) (envelope-from ) id 1J01iL-0005JG-Lp; Wed, 05 Dec 2007 13:23:29 -0800 Message-ID: <475716CC.8010104@calconnect.org> Date: Wed, 05 Dec 2007 13:23:24 -0800 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ietf-calsify list 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 - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-calsify] Registration is now open for CalConnect Roundtable XI and IOP Test Event, February 4-8, 2008 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2116968512==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 This is a multi-part message in MIME format. --===============2116968512== Content-Type: multipart/alternative; boundary="------------070402090508060406030505" This is a multi-part message in MIME format. --------------070402090508060406030505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable /This message is being sent to the IETF calendaring-related lists. My=20 apologies if you receive it multiple times; nearly everyone seems to be=20 on nearly all of these lists. Dave Thewlis./ *CalConnect Roundtable XI and IOP Test Event Registration is now open* Registration is now open for CalConnect Roundtable XI and IOP Test=20 Event, February 4-8, 2008, hosted by Sun Microsystems in Menlo Park,=20 California (San Francisco South Bay Area). Logistics information and=20 links to the registration pages may be found at=20 http://www.calconnect.org/roundtable11.shtml The IOP Test Event will occur from noon Monday the 4th through noon=20 Wednesday the 6th; the Roundtable from noon Wednesday the 6th through=20 (at least) noon Friday the 8th.=20 Non-members of CalConnect are invited to attend a single Roundtable as=20 an observer to determine whether or not joining CalConnect would be of=20 benefit to you. Non-members may also attend a single CalConnect=20 Interoperability Test Event as observers, as well. Information on=20 observer status and registration is also linked from the above page. Registration for both member representatives and observer=20 representatives is $350 for the Roundtable through January 15th, and=20 $395 thereafter. Observer registration for the IOP test event is also $3= 50. If you have any questions please contact me, and we hope to see you in=20 February. Best Regards, Dave Thewlis --=20 *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) =B7 +1 707 498 2238 (mobile) http://www.calconnect.org =B7 Dave.Thewlis@calconnect.org=20 --------------070402090508060406030505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This message is being sent to the IETF calendaring-related lists.  My apologies if you receive it multiple times; nearly everyone seems to be on nearly all of these lists.  Dave Thewlis.

CalConnect Roundtable XI and IOP Test Event Registration is now open

Registration is now open for CalConnect Roundtable XI and IOP Test Event, February 4-8, 2008, hosted by Sun Microsystems in Menlo Park, California (San Francisco South Bay Area).  Logistics information and links to the registration pages may be found at http://www.calconnect.org/roundtable11.shtml

The IOP Test Event will occur from noon Monday the 4th through noon Wednesday the 6th; the Roundtable from noon Wednesday the 6th through (at least) noon Friday the 8th. 

Non-members of CalConnect are invited to attend a single Roundtable as an observer to determine whether or not joining CalConnect would be of benefit to you.  Non-members may also attend a single CalConnect Interoperability Test Event as observers, as well.  Information on observer status and registration is also linked from the above page.

Registration for both member representatives and observer representatives is $350 for the Roundtable through January 15th, and $395 thereafter.  Observer registration for the IOP test event is also $350.

If you have any questions please contact me, and we hope to see you in February.

Best Regards,

Dave Thewlis
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------070402090508060406030505-- --===============2116968512== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============2116968512==-- From ietf-calsify-bounces@osafoundation.org Tue Dec 11 06:45:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J23Xr-0004TD-F1 for calsify-archive-Feit0ahl@lists.ietf.org; Tue, 11 Dec 2007 06:45:03 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J23Xq-0006Sm-IW for calsify-archive-Feit0ahl@lists.ietf.org; Tue, 11 Dec 2007 06:45:03 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 1419C80A1F; Tue, 11 Dec 2007 03:45:02 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 34EDB8094B for ; Tue, 11 Dec 2007 03:45:00 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5835014220C for ; Tue, 11 Dec 2007 03:45:01 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-50 required=4 tests=[AWL=0.501, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] 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 NXdmU9ktu4eL for ; Tue, 11 Dec 2007 03:44: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 7CCE6142217 for ; Tue, 11 Dec 2007 03:44:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.24,151,1196636400"; d="scan'208";a="559871" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2007 12:44:52 +0100 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 lBBBiqSh003706 for ; Tue, 11 Dec 2007 12:44:52 +0100 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp398.cisco.com [10.61.65.142]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBBBinmc000558 for ; Tue, 11 Dec 2007 11:44:52 GMT Message-ID: <475E7831.90901@cisco.com> Date: Tue, 11 Dec 2007 12:44:49 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=969; t=1197373492; x=1198237492; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20driving=20to=20conclusion |Sender:=20; bh=Sa9Mm4NtsQXF1jXoG0CD3nAwh0nQsVavpA5EyqaXrqw=; b=a4aCe8+UxXbbiAYH1KopK4O86soW5igtArh44Eei9ny/2TajRdCtwrF/e4 SGcfmMl9WgSc1G0lg2udhoS2OAw/WYb0YvcwyFbXnQB2o17BocuIjSWt4LIs jja3vpBxfp; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Ietf-calsify] driving to conclusion X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Dear all, We held a fairly productive discussion last week in Vancouver. The minutes will be made available in due course. This having been said, the chairs would like to host conference calls for the purpose of discussing open issues for our open documents. Any decision claimed to be made in such a call would of course be subject to verification of consensus on this list. These calls are proposed to be held weekly on Wednesdays at 9:30am US/New_York with the exception of the weeks of December 24th and 31st. We will hold our first meeting next Wednesday, December 19 from 9:30am - 10:30am. All are welcome, but RSVPs are requested so I can arrange enough ports on the conference bridge. The agenda for the next call will be as follows: 1. Shepherd comments on RFC2445bis (Aki) 2. Any open issues with RFC2445bis 3. Open issues with RFC2446bis. If you are interested in participating, please send me an email. Thanks, Eliot _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Dec 14 12:06:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3E02-0003kZ-So for calsify-archive-Feit0ahl@lists.ietf.org; Fri, 14 Dec 2007 12:06:58 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3Dzy-0002VY-T2 for calsify-archive-Feit0ahl@lists.ietf.org; Fri, 14 Dec 2007 12:06:58 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id B7D077FCD3; Fri, 14 Dec 2007 09:06:53 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 873547FCD2 for ; Fri, 14 Dec 2007 09:06:52 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E5D231421FD for ; Fri, 14 Dec 2007 09:06:53 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] 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 DBJC2u0PDsHJ for ; Fri, 14 Dec 2007 09:06:45 -0800 (PST) Received: from mail.uk.scalix.com (mail.uk.scalix.com [85.118.4.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3D977142217 for ; Fri, 14 Dec 2007 09:06:44 -0800 (PST) Received: from mail.uk.scalix.com (localhost.localdomain [127.0.0.1]) by mail.uk.scalix.com (8.13.8/8.13.8) with ESMTP id lBEH6aTL027307 for ; Fri, 14 Dec 2007 17:06:36 GMT Received: from crowley.uk.scalix.com (crowley.uk.scalix.com [10.11.108.213]) by mail.uk.scalix.com (Scalix SMTP Relay 11.3.0.11333) via ESMTP; Fri, 14 Dec 2007 17:06:36 +0000 (GMT) Date: Fri, 14 Dec 2007 17:06:35 +0000 From: Gren Elliot To: ietf-calsify@osafoundation.org Message-ID: <4762B81B.4090806@scalix.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Ietf-calsify] rfc2445/rfc2446/rfc2447 confusion ATTENDEE: TYPE= or CUTYPE= X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Hi, There appears to be a contradiction between RFC 2445 (ICalendar) on one hand and RFC2446 (iTIP) / RFC2447 (iMIP) on the other, which still seems to be true in the latest calsify drafts I can see : http://tools.ietf.org/id/draft-ietf-calsify-rfc2445bis-07.txt 3.2.3. Calendar User Type Parameter Name: CUTYPE Purpose: To specify the type of calendar user specified by the property. Format Definition: This property parameter is defined by the following notation: cutypeparam = "CUTYPE" "=" ("INDIVIDUAL" ; An individual / "GROUP" ; A group of individuals / "RESOURCE" ; A physical resource / "ROOM" ; A room resource / "UNKNOWN" ; Otherwise not known / x-name ; Experimental type / iana-token) ; Other IANA registered ; type ; Default is INDIVIDUAL Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter identifies the type of calendar user specified by the property. If not specified on a property that allows this parameter, the default is INDIVIDUAL. Applications MUST treat x-name and iana-token value they don't recognized the same way as the INDIVIDUAL value. Example: ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org In particular, nowhere is a parameter with token "TYPE" defined. However, http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-04.txt Refers to a TYPE parameter and gives several examples, for instance : ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com RFC 2447 gives similar examples to the RFC 2446 form. It seems to me that RFC 2446 and RFC 2447 are out of step with common usage, although I am seeing the odd message using TYPE instead of CUTYPE? I would like to see the drafts resolve this contradiction. Any thoughts? Regards, Gren. _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Fri Dec 14 15:28:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3H8e-0007c0-6V for calsify-archive-Feit0ahl@lists.ietf.org; Fri, 14 Dec 2007 15:28:04 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3H8d-00089U-1R for calsify-archive-Feit0ahl@lists.ietf.org; Fri, 14 Dec 2007 15:28:04 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id BA12580440; Fri, 14 Dec 2007 12:28:00 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5BE5E8021C for ; Fri, 14 Dec 2007 12:27:59 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BCFF3142217 for ; Fri, 14 Dec 2007 12:28:00 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-50 required=4 tests=[AWL=1.308, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 O+u-qZG0Oqvp for ; Fri, 14 Dec 2007 12:27:54 -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 47D4614220E for ; Fri, 14 Dec 2007 12:27:54 -0800 (PST) Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id lBEKRkHA015638; Fri, 14 Dec 2007 13:27:46 -0700 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lBEKRiwB017904; Fri, 14 Dec 2007 13:27:44 -0700 Received: from bdesruis-ca.ca.oracle.com by acsmt351.oracle.com with ESMTP id 3443547171197664056; Fri, 14 Dec 2007 12:27:36 -0800 Message-ID: <4762E730.3010409@oracle.com> Date: Fri, 14 Dec 2007 15:27:28 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Gren Elliot Subject: Re: [Ietf-calsify] rfc2445/rfc2446/rfc2447 confusion ATTENDEE: TYPE= or CUTYPE= References: <4762B81B.4090806@scalix.com> In-Reply-To: <4762B81B.4090806@scalix.com> 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 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Both draft-ietf-calsify-2446bis and draft-ietf-calsify-rfc2447bis should replace TYPE by CUTYPE. Cheers, Bernard Gren Elliot wrote: > Hi, > > There appears to be a contradiction between RFC 2445 (ICalendar) on one > hand and RFC2446 (iTIP) / RFC2447 (iMIP) on the other, which still seems > to be true in the latest calsify drafts I can see : > > http://tools.ietf.org/id/draft-ietf-calsify-rfc2445bis-07.txt > > 3.2.3. Calendar User Type > > Parameter Name: CUTYPE > > Purpose: To specify the type of calendar user specified by the > property. > > Format Definition: This property parameter is defined by the > following notation: > > cutypeparam = "CUTYPE" "=" > ("INDIVIDUAL" ; An individual > / "GROUP" ; A group of individuals > / "RESOURCE" ; A physical resource > / "ROOM" ; A room resource > / "UNKNOWN" ; Otherwise not known > / x-name ; Experimental type > / iana-token) ; Other IANA registered > ; type > ; Default is INDIVIDUAL > > Description: This parameter can be specified on properties with a > CAL-ADDRESS value type. The parameter identifies the type of > calendar user specified by the property. If not specified on a > property that allows this parameter, the default is INDIVIDUAL. > Applications MUST treat x-name and iana-token value they don't > recognized the same way as the INDIVIDUAL value. > > Example: > > ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org > > In particular, nowhere is a parameter with token "TYPE" defined. > > However, > http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-04.txt > Refers to a TYPE parameter and gives several examples, for instance : > > ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com > > RFC 2447 gives similar examples to the RFC 2446 form. > > It seems to me that RFC 2446 and RFC 2447 are out of step with common > usage, although I am seeing the odd message using TYPE instead of CUTYPE? > > I would like to see the drafts resolve this contradiction. > > Any thoughts? > Regards, > Gren. > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Dec 19 09:49:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50EO-0001sL-4j for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 19 Dec 2007 09:49:08 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J50EL-0007Ox-NB for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 19 Dec 2007 09:49:08 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id ADDB97F67E; Wed, 19 Dec 2007 06:49:04 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C8B787F66D for ; Wed, 19 Dec 2007 06:49:02 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6B555142274 for ; Wed, 19 Dec 2007 06:49:04 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-50 required=4 tests=[AWL=-0.100, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] 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 1Hv2SVfIXsFq for ; Wed, 19 Dec 2007 06:48:57 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3C700142201 for ; Wed, 19 Dec 2007 06:48:57 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBJEmDQO011144; Wed, 19 Dec 2007 16:48:35 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 16:47:48 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 16:47:47 +0200 Received: from [172.21.43.33] (esdhcp04333.research.nokia.com [172.21.43.33]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lBJEliF7013817; Wed, 19 Dec 2007 16:47:44 +0200 From: Aki Niemi To: Bernard Desruisseaux Content-Type: text/plain Organization: Nokia-TP-MSW/Helsinki Date: Wed, 19 Dec 2007 16:48:37 +0200 Message-Id: <1198075717.13738.82.camel@scotty> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2007 14:47:47.0949 (UTC) FILETIME=[1F43F9D0:01C8424E] X-Nokia-AV: Clean Cc: ietf-calsify Subject: [Ietf-calsify] Chair review of draft-ietf-calsify-rfc2445bis X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 All, I've now reviewed RFC2445-bis, and am currently working on the PROTO writeup, which is a document that accompanies the draft as we request publication. I'll also send some typos and such to Bernard privately. Cheers, Aki Technical: ========== * Sec 3.2.3: an implementation should treat an unrecognized CUTYPE value as UNKNOWN as opposed to INDIVIDUAL: OLD: Applications MUST treat x-name and iana-token value they don't recognized the same way as the INDIVIDUAL value. NEW: Applications MUST treat x-name and iana-token value they don't recognized the same way as the UNKNOWN value. * Section 3.2.19: treating unknown VALUE data types. Rather than treating unrecognized values as TEXT, I think the draft should instruct implementations to ignore them: OLD: Applications MUST treat x-name and iana-token value they don't recognized the same way as the TEXT value. NEW: Applications MUST ignore x-name and iana-token values that they don't recognize. * Sec 3.2.4/3.2.5: the DELEGATED-TO and DELEGATED-FROM parameters say that the cal-address MUST be a mailto URI. However, the actual definition of cal-address is more liberal; it says MUST be a mailto URI but only when email is used as transport. Assuming DELEGATED-* can be used with any transport, either their definition needs to add the same transport disclaimer, or the MUST needs to be removed altogether (and rely only on cal-address definition here) * Sec 3.6.6: alarm component. I think it is useful to add a short note about dealing with alarm components from untrusted sources. I think there used to be some "handwaiving" about that in the security considerations, but I think it got removed. Suggest something like: OLD: The "ACTION" property is used within the "VALARM" calendar component to specify the type of action invoked when the alarm is triggered. The "VALARM" properties provide enough information for a specific action to be invoked. It is typically the responsibility of a "Calendar User Agent" (CUA) to deliver the alarm in the specified fashion. An "ACTION" property value of AUDIO specifies an alarm that causes a sound to be played to alert the user; DISPLAY specifies an alarm that causes a text message to be displayed to the user; and EMAIL specifies an alarm that causes an electronic email message to be delivered to one or more email addresses. NEW: The "ACTION" property is used within the "VALARM" calendar component to specify the type of action invoked when the alarm is triggered. The "VALARM" properties provide enough information for a specific action to be invoked. It is typically the responsibility of a "Calendar User Agent" (CUA) to deliver the alarm in the specified fashion. An "ACTION" property value of AUDIO specifies an alarm that causes a sound to be played to alert the user; DISPLAY specifies an alarm that causes a text message to be displayed to the user; and EMAIL specifies an alarm that causes an electronic email message to be delivered to one or more email addresses. Note: implementations should carefully consider whether they accept alarm components from untrusted sources, e.g., when importing calendar objects from external sources. One reasonable policy is to always ignore alarm components that the calendar user has not set herself, or at least ask for confirmation in such a case. * Section 8.1, 2nd sentence: what does this mean? Suggest removing it. > However, the implementation of the memo is in no way limited solely as > a MIME content type. Structure: ========== * Sec 3: it would help readability a lot to explain in the introduction some basics of iCalendar, and how exactly the section that follows is structured. Currently, it's easy to miss the bigger picture, as the section jumps directly into content lines formatting, and the data types used in properties, without a clear picture as to where and how they will be used. My proposal is to add the following passage to the top of Section 3: OLD: The following sections define the details of a Calendaring and Scheduling Core Object Specification. This information is intended to be an integral part of the MIME content type registration. In addition, this information can be used independent of such content registration. In particular, this memo has direct applicability for use as a calendaring and scheduling exchange format in file-, memory- or network-based transport mechanisms. NEW: The following sections define the details of a Calendaring and Scheduling Core Object Specification. The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of an iCalendar stream with one or more iCalendar objects. The body of the iCalendar object consists of a sequence of calendar properties and one or more calendar components. Section 3.1. defines the content line format; Section 3.2. defines the property parameter format; Section 3.3. defines the data types for property values; Section 3.4. defines the iCalendar object format; Section 3.5. defines the iCalendar property format; Section 3.6. defines the calendar component format; Section 3.7. defines calendar properties; and Sectiopn 3.8. defines calendar component properties. This information is intended to be an integral part of the MIME content type registration. In addition, this information can be used independent of such content registration. In particular, this memo has direct applicability for use as a calendaring and scheduling exchange format in file-, memory- or network-based transport mechanisms. * Sec 3.3.1: > No additional content value encoding (i.e., BACKSLASH character > encoding) is defined for this value type. This is the first time BACKSLASH character encoding is mentioned. What is it? Suggest adding a forward reference to Sec 3.3.11., where it is defined. Nits: ===== * Section 2, first sentence: RFC2119 doesn't have a "NOT RECOMMENDED" key word. (Caught by I-D nits tool) _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Dec 19 10:27:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J50pP-0002LX-HQ for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 19 Dec 2007 10:27:23 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J50pO-0008Qw-IN for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 19 Dec 2007 10:27:23 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 965627F7F1; Wed, 19 Dec 2007 07:27:21 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6548F7F7AA for ; Wed, 19 Dec 2007 07:27:20 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0889C14227E for ; Wed, 19 Dec 2007 07:27:22 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-50 required=4 tests=[AWL=0.120, BAYES_00=-2.599] 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 1PTG5nhXD+3x for ; Wed, 19 Dec 2007 07:27:15 -0800 (PST) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 76300142274 for ; Wed, 19 Dec 2007 07:27:13 -0800 (PST) Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lBJFQ0jM023851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2007 10:26:07 -0500 Date: Wed, 19 Dec 2007 10:25:55 -0500 From: Cyrus Daboo To: Aki Niemi , Bernard Desruisseaux Subject: Re: [Ietf-calsify] Chair review of draft-ietf-calsify-rfc2445bis Message-ID: <8C4EB5714B5008CFA16034ED@caldav.corp.apple.com> In-Reply-To: <1198075717.13738.82.camel@scotty> References: <1198075717.13738.82.camel@scotty> 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 Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi Aki, --On December 19, 2007 4:48:37 PM +0200 Aki Niemi wrote: > * Section 3.2.19: treating unknown VALUE data types. Rather than > treating unrecognized values as TEXT, I think the draft should instruct > implementations to ignore them: > > OLD: > > Applications MUST treat x-name and iana-token value they don't > recognized the same way as the TEXT value. > > NEW: > > Applications MUST ignore x-name and iana-token values that they > don't recognize. I don't like the word "ignore" in this context. It could give an implementor the impression that they can simply not store that property/value at all, and that would be wrong. However, you are right in that it is wrong to treat an unknown value as TEXT. For example, say I had defined a new value type that was almost like TEXT, but did not require the escaping mechanism. Well if a client were to treat that as TEXT, and the value contained some characters that would need escaping in a TEXT value, then when it wrote out the value it would escape the content - that would of course be wrong. Perhaps a better example would be to consider a client that did not understand the RECUR value type - since that value does allow unescaped semi-colons, treating it as TEXT would be wrong. My suggestion for alternative text: Applications MUST preserve the value data for x-name and iana-token values that they don't recognize without attempting to interpret or parse the value data. -- Cyrus Daboo _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Dec 19 10:43:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J514a-0005uK-F3 for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 19 Dec 2007 10:43:04 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J514Y-0000Fv-N2 for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 19 Dec 2007 10:43:04 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id D3B157F7F1; Wed, 19 Dec 2007 07:43:01 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6891D7F7AA for ; Wed, 19 Dec 2007 07:43:01 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0AA5614227E for ; Wed, 19 Dec 2007 07:43:03 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-50 required=4 tests=[AWL=-0.067, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] 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 M1HA-FgbTL+2 for ; Wed, 19 Dec 2007 07:42:56 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 898CE142245 for ; Wed, 19 Dec 2007 07:42:56 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBJFf6Av014236; Wed, 19 Dec 2007 17:41:19 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 17:41:05 +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); Wed, 19 Dec 2007 17:41:04 +0200 Received: from [172.21.43.33] (esdhcp04333.research.nokia.com [172.21.43.33]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lBJFf3Eu031958; Wed, 19 Dec 2007 17:41:03 +0200 Subject: Re: [Ietf-calsify] Chair review of draft-ietf-calsify-rfc2445bis From: Aki Niemi To: ext Cyrus Daboo In-Reply-To: <8C4EB5714B5008CFA16034ED@caldav.corp.apple.com> References: <1198075717.13738.82.camel@scotty> <8C4EB5714B5008CFA16034ED@caldav.corp.apple.com> Content-Type: text/plain Organization: Nokia-TP-MSW/Helsinki Date: Wed, 19 Dec 2007 17:41:57 +0200 Message-Id: <1198078917.13738.89.camel@scotty> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2007 15:41:04.0789 (UTC) FILETIME=[90BB0C50:01C84255] X-Nokia-AV: Clean Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca ke, 2007-12-19 kello 10:25 -0500, ext Cyrus Daboo kirjoitti: > Hi Aki, > > --On December 19, 2007 4:48:37 PM +0200 Aki Niemi > wrote: > > > * Section 3.2.19: treating unknown VALUE data types. Rather than > > treating unrecognized values as TEXT, I think the draft should instruct > > implementations to ignore them: > > > > OLD: > > > > Applications MUST treat x-name and iana-token value they don't > > recognized the same way as the TEXT value. > > > > NEW: > > > > Applications MUST ignore x-name and iana-token values that they > > don't recognize. > > I don't like the word "ignore" in this context. It could give an > implementor the impression that they can simply not store that > property/value at all, and that would be wrong. > > However, you are right in that it is wrong to treat an unknown value as > TEXT. For example, say I had defined a new value type that was almost like > TEXT, but did not require the escaping mechanism. Well if a client were to > treat that as TEXT, and the value contained some characters that would need > escaping in a TEXT value, then when it wrote out the value it would escape > the content - that would of course be wrong. > > Perhaps a better example would be to consider a client that did not > understand the RECUR value type - since that value does allow unescaped > semi-colons, treating it as TEXT would be wrong. > > My suggestion for alternative text: > > Applications MUST preserve the value data for x-name and iana-token > values that they don't recognize without attempting to interpret or > parse the value data. +1 Cheers, Aki _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Dec 19 11:55:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J52D7-0003KI-HM for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 19 Dec 2007 11:55:57 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J52D5-0001uB-2B for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 19 Dec 2007 11:55:57 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id E7E027FDD6; Wed, 19 Dec 2007 08:55:53 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DAFFB7FD07 for ; Wed, 19 Dec 2007 08:55:51 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7C9DD14227E for ; Wed, 19 Dec 2007 08:55:53 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-50 required=4 tests=[AWL=0.785, BAYES_00=-2.599, SPF_PASS=-0.001] 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 y1skMR0nfAIr for ; Wed, 19 Dec 2007 08:55:47 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id B67CA1421FD for ; Wed, 19 Dec 2007 08:55:46 -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 ; Wed, 19 Dec 2007 16:55:33 +0000 Message-ID: <47694CFE.30802@isode.com> Date: Wed, 19 Dec 2007 16:55:26 +0000 From: Alexey Melnikov 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 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Chair review of draft-ietf-calsify-rfc2445bis References: <1198075717.13738.82.camel@scotty> <8C4EB5714B5008CFA16034ED@caldav.corp.apple.com> In-Reply-To: <8C4EB5714B5008CFA16034ED@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cyrus Daboo wrote: > Hi Aki, > > --On December 19, 2007 4:48:37 PM +0200 Aki Niemi > wrote: > >> * Section 3.2.19: treating unknown VALUE data types. Rather than >> treating unrecognized values as TEXT, I think the draft should instruct >> implementations to ignore them: >> >> OLD: >> >> Applications MUST treat x-name and iana-token value they don't >> recognized the same way as the TEXT value. >> >> NEW: >> >> Applications MUST ignore x-name and iana-token values that they >> don't recognize. > > I don't like the word "ignore" in this context. It could give an > implementor the impression that they can simply not store that > property/value at all, and that would be wrong. > > However, you are right in that it is wrong to treat an unknown value > as TEXT. For example, say I had defined a new value type that was > almost like TEXT, but did not require the escaping mechanism. Well if > a client were to treat that as TEXT, and the value contained some > characters that would need escaping in a TEXT value, then when it > wrote out the value it would escape the content - that would of course > be wrong. > > Perhaps a better example would be to consider a client that did not > understand the RECUR value type - since that value does allow > unescaped semi-colons, treating it as TEXT would be wrong. > > My suggestion for alternative text: > > Applications MUST preserve the value data for x-name and iana-token > values that they don't recognize without attempting to interpret or > parse the value data. +1. _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Wed Dec 19 13:11:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J53Oa-0007pp-Oj for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 19 Dec 2007 13:11:52 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J53OY-0003uD-UY for calsify-archive-Feit0ahl@lists.ietf.org; Wed, 19 Dec 2007 13:11:52 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id E909F7F637; Wed, 19 Dec 2007 10:11:49 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F339E7F635 for ; Wed, 19 Dec 2007 10:11:47 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 96D3414244A for ; Wed, 19 Dec 2007 10:11:49 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-50 required=4 tests=[AWL=0.494, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] 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 Cri+DYqaM6+b for ; Wed, 19 Dec 2007 10:11:43 -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 E46B0142274 for ; Wed, 19 Dec 2007 10:11:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.24,185,1196636400"; d="scan'208";a="1343159" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Dec 2007 19:11:35 +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 lBJIBZ8M019207 for ; Wed, 19 Dec 2007 19:11:35 +0100 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4385.cisco.com [10.61.81.32]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBJIBYAC007919 for ; Wed, 19 Dec 2007 18:11:35 GMT Message-ID: <47695ED6.9080008@cisco.com> Date: Wed, 19 Dec 2007 19:11:34 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=400; t=1198087895; x=1198951895; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20next=20call=20three=20weeks=20from=20today,=20= 20January=209th=209=3A30am=20EST |Sender:=20; bh=Au8bbInMaUx47WErDOds3MbFx75QRBgtH/Tvzs9jbAs=; b=AZUDK1mt2Yaoq8ztbU4jGS1x5URvpss8XjZ5hrOTdGpkIOCJm931qAEDH9 iRVAIxcdbmD0w9GgwDpTV5+11CwZ9n6Vqc0N6C1i1IeHAuZ+BUXBE4YLi5nT i7t3S/tOx4; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Ietf-calsify] next call three weeks from today, January 9th 9:30am EST X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Dear all, To give people more time and considering the holiday season, the next call will need to be on the 9th of January. In the meantime, please remember that we would like to close off new issues to RFC2446bis. We are also reviewing the shepherd comments from Aki for RFC2445bis. Please RSVP for the call so that I can get the appropriate number of bridge slots. Thanks, Eliot _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify From ietf-calsify-bounces@osafoundation.org Thu Dec 27 12:27:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7wVq-0007Us-1s for calsify-archive-Feit0ahl@lists.ietf.org; Thu, 27 Dec 2007 12:27:18 -0500 Received: from [2001:4f8:3:ba:230:48ff:fe43:1456] (helo=leilani.osafoundation.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7wVo-0004eu-P4 for calsify-archive-Feit0ahl@lists.ietf.org; Thu, 27 Dec 2007 12:27:18 -0500 Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id C61077FEF9; Thu, 27 Dec 2007 09:27:15 -0800 (PST) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BA48B7FCD8 for ; Thu, 27 Dec 2007 09:27:13 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B9680142254 for ; Thu, 27 Dec 2007 09:27:15 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 HxwVxiiQTgOa for ; Thu, 27 Dec 2007 09:27:09 -0800 (PST) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.238]) by laweleka.osafoundation.org (Postfix) with ESMTP id 16137142217 for ; Thu, 27 Dec 2007 09:27:09 -0800 (PST) Received: by nz-out-0506.google.com with SMTP id r28so670195nza.36 for ; Thu, 27 Dec 2007 09:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=6wrQe+S3GyfpY1JbPLxFNj6gSQNHCBnB7mpHJjajb6Y=; b=FJFrTAJvyl98SeySltuj+KqYPODOpfi8QdyvP/tp2nIAoUDvvNAG7ioPeJpSSebXEK8NX+dWmIM92UYs/ZRYvoyxY0mJ3rHeicIKhtVSC63x4RkOFmtVNRhZwRhDccd2IUx86OlIFyvCrZlT8B+u4mWgxrEMMxFLWpoegWaZHuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=aay9998C4YA0r3+drhWpdQd6AGxwbtDlYuYu5ZfDgu5eNoXe0/dtZIUTdvr4r35V4Gosy/O7zu97ibxGJDkILHIkoKg1SPrHdolnvzwvnRLCcSsKtKVT8IDb4VPGlUIIkhvv4BvfuIkpUB95OF6xdLgHheB+iOrh1G/ZYZ5LovE= Received: by 10.142.47.6 with SMTP id u6mr2584134wfu.29.1198776425954; Thu, 27 Dec 2007 09:27:05 -0800 (PST) Received: by 10.142.49.6 with HTTP; Thu, 27 Dec 2007 09:27:05 -0800 (PST) Message-ID: Date: Thu, 27 Dec 2007 14:27:05 -0300 From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" To: "ietf-calsify@osafoundation.org" MIME-Version: 1.0 Subject: [Ietf-calsify] Imprecise and alternative events for iCalendar and iTIP X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0079949990==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org X-Spam-Score: -4.0 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --===============0079949990== Content-Type: multipart/alternative; boundary="----=_Part_11232_23252415.1198776425948" ------=_Part_11232_23252415.1198776425948 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear all, This is to report the submission of a new version of the draft proposal. Regards, F=E1bio. ---------- Forwarded message ---------- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Date: Fri, 21 Dec 2007 11:15:01 -0500 Subject: I-D ACTION:draft-silva-events-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Imprecise and alternative events for iCalendar and iTIP Author(s) : F. Silva, R. Drummond Filename : draft-silva-events-01.txt Pages : 55 Date : 2007-12-21 This document defines extensions to iCalendar and iTIP that allow the expression of imprecise and multiple alternative events in calendar objects and scheduling messages. Imprecise events can be used to imprecisely describe an event by specifying various ranked periods of time in which it could be scheduled. Alternative events can be used to describe an event in terms of multiple ranked event descriptions, imprecise or not, that could alternatively be scheduled. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-silva-events-01.txt ------=_Part_11232_23252415.1198776425948 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear all,

This is to report the submission of a new version of the d= raft proposal.

Regards,

F=E1bio.

---------- Forwarded = message ----------
From:  Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Date: Fri, 21 Dec 2007 11:15:01 -0500Subject: I-D ACTION:draft-silva-events-01.txt
A New Internet-Draft= is available from the on-line Internet-Drafts
directories.


       Title    =       : Imprecise and alternative events for iCalendar and = iTIP
       Author(s)       : F. Sil= va, R. Drummond
       Filename      = ;  : draft-silva-events-01.txt
       Pages &n= bsp;         : 55
       Date           &nb= sp;: 2007-12-21

This document defines extensions to iCalendar and iT= IP that allow the
  expression of imprecise and multiple alternati= ve events in calendar
  objects and scheduling messages.  Imp= recise events can be used to
  imprecisely describe an event by specifying various ranked peri= ods of
  time in which it could be scheduled.  Alternative ev= ents can be used
  to describe an event in terms of multiple ranke= d event descriptions,
  imprecise or not, that could alternatively be scheduled.
A URL for this Internet-Draft is:
http://www.ietf.org/= internet-drafts/draft-silva-events-01.txt
------=_Part_11232_23252415.1198776425948-- --===============0079949990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ietf-calsify mailing list Ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify --===============0079949990==-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BA48B7FCD8 for ; Thu, 27 Dec 2007 09:27:13 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B9680142254 for ; Thu, 27 Dec 2007 09:27:15 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, HTML_30_40=0.374, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 HxwVxiiQTgOa for ; Thu, 27 Dec 2007 09:27:09 -0800 (PST) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.238]) by laweleka.osafoundation.org (Postfix) with ESMTP id 16137142217 for ; Thu, 27 Dec 2007 09:27:09 -0800 (PST) Received: by nz-out-0506.google.com with SMTP id r28so670195nza.36 for ; Thu, 27 Dec 2007 09:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=6wrQe+S3GyfpY1JbPLxFNj6gSQNHCBnB7mpHJjajb6Y=; b=FJFrTAJvyl98SeySltuj+KqYPODOpfi8QdyvP/tp2nIAoUDvvNAG7ioPeJpSSebXEK8NX+dWmIM92UYs/ZRYvoyxY0mJ3rHeicIKhtVSC63x4RkOFmtVNRhZwRhDccd2IUx86OlIFyvCrZlT8B+u4mWgxrEMMxFLWpoegWaZHuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=aay9998C4YA0r3+drhWpdQd6AGxwbtDlYuYu5ZfDgu5eNoXe0/dtZIUTdvr4r35V4Gosy/O7zu97ibxGJDkILHIkoKg1SPrHdolnvzwvnRLCcSsKtKVT8IDb4VPGlUIIkhvv4BvfuIkpUB95OF6xdLgHheB+iOrh1G/ZYZ5LovE= Received: by 10.142.47.6 with SMTP id u6mr2584134wfu.29.1198776425954; Thu, 27 Dec 2007 09:27:05 -0800 (PST) Received: by 10.142.49.6 with HTTP; Thu, 27 Dec 2007 09:27:05 -0800 (PST) Message-ID: Date: Thu, 27 Dec 2007 14:27:05 -0300 From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" To: "ietf-calsify@osafoundation.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11232_23252415.1198776425948" Subject: [Ietf-calsify] Imprecise and alternative events for iCalendar and iTIP X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 17:27:13 -0000 ------=_Part_11232_23252415.1198776425948 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear all, This is to report the submission of a new version of the draft proposal. Regards, F=E1bio. ---------- Forwarded message ---------- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Date: Fri, 21 Dec 2007 11:15:01 -0500 Subject: I-D ACTION:draft-silva-events-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Imprecise and alternative events for iCalendar and iTIP Author(s) : F. Silva, R. Drummond Filename : draft-silva-events-01.txt Pages : 55 Date : 2007-12-21 This document defines extensions to iCalendar and iTIP that allow the expression of imprecise and multiple alternative events in calendar objects and scheduling messages. Imprecise events can be used to imprecisely describe an event by specifying various ranked periods of time in which it could be scheduled. Alternative events can be used to describe an event in terms of multiple ranked event descriptions, imprecise or not, that could alternatively be scheduled. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-silva-events-01.txt ------=_Part_11232_23252415.1198776425948 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear all,

This is to report the submission of a new version of the d= raft proposal.

Regards,

F=E1bio.

---------- Forwarded = message ----------
From:  Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Date: Fri, 21 Dec 2007 11:15:01 -0500Subject: I-D ACTION:draft-silva-events-01.txt
A New Internet-Draft= is available from the on-line Internet-Drafts
directories.


       Title    =       : Imprecise and alternative events for iCalendar and = iTIP
       Author(s)       : F. Sil= va, R. Drummond
       Filename      = ;  : draft-silva-events-01.txt
       Pages &n= bsp;         : 55
       Date           &nb= sp;: 2007-12-21

This document defines extensions to iCalendar and iT= IP that allow the
  expression of imprecise and multiple alternati= ve events in calendar
  objects and scheduling messages.  Imp= recise events can be used to
  imprecisely describe an event by specifying various ranked peri= ods of
  time in which it could be scheduled.  Alternative ev= ents can be used
  to describe an event in terms of multiple ranke= d event descriptions,
  imprecise or not, that could alternatively be scheduled.
A URL for this Internet-Draft is:
http://www.ietf.org/= internet-drafts/draft-silva-events-01.txt
------=_Part_11232_23252415.1198776425948-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F339E7F635 for ; Wed, 19 Dec 2007 10:11:47 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 96D3414244A for ; Wed, 19 Dec 2007 10:11:49 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-50 required=4 tests=[AWL=0.494, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] 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 Cri+DYqaM6+b for ; Wed, 19 Dec 2007 10:11:43 -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 E46B0142274 for ; Wed, 19 Dec 2007 10:11:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.24,185,1196636400"; d="scan'208";a="1343159" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Dec 2007 19:11:35 +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 lBJIBZ8M019207 for ; Wed, 19 Dec 2007 19:11:35 +0100 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4385.cisco.com [10.61.81.32]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBJIBYAC007919 for ; Wed, 19 Dec 2007 18:11:35 GMT Message-ID: <47695ED6.9080008@cisco.com> Date: Wed, 19 Dec 2007 19:11:34 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=400; t=1198087895; x=1198951895; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20next=20call=20three=20weeks=20from=20today,=20= 20January=209th=209=3A30am=20EST |Sender:=20; bh=Au8bbInMaUx47WErDOds3MbFx75QRBgtH/Tvzs9jbAs=; b=AZUDK1mt2Yaoq8ztbU4jGS1x5URvpss8XjZ5hrOTdGpkIOCJm931qAEDH9 iRVAIxcdbmD0w9GgwDpTV5+11CwZ9n6Vqc0N6C1i1IeHAuZ+BUXBE4YLi5nT i7t3S/tOx4; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Ietf-calsify] next call three weeks from today, January 9th 9:30am EST X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2007 18:11:48 -0000 Dear all, To give people more time and considering the holiday season, the next call will need to be on the 9th of January. In the meantime, please remember that we would like to close off new issues to RFC2446bis. We are also reviewing the shepherd comments from Aki for RFC2445bis. Please RSVP for the call so that I can get the appropriate number of bridge slots. Thanks, Eliot Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DAFFB7FD07 for ; Wed, 19 Dec 2007 08:55:51 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7C9DD14227E for ; Wed, 19 Dec 2007 08:55:53 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-50 required=4 tests=[AWL=0.785, BAYES_00=-2.599, SPF_PASS=-0.001] 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 y1skMR0nfAIr for ; Wed, 19 Dec 2007 08:55:47 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id B67CA1421FD for ; Wed, 19 Dec 2007 08:55:46 -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 ; Wed, 19 Dec 2007 16:55:33 +0000 Message-ID: <47694CFE.30802@isode.com> Date: Wed, 19 Dec 2007 16:55:26 +0000 From: Alexey Melnikov 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 To: Cyrus Daboo Subject: Re: [Ietf-calsify] Chair review of draft-ietf-calsify-rfc2445bis References: <1198075717.13738.82.camel@scotty> <8C4EB5714B5008CFA16034ED@caldav.corp.apple.com> In-Reply-To: <8C4EB5714B5008CFA16034ED@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2007 16:55:52 -0000 Cyrus Daboo wrote: > Hi Aki, > > --On December 19, 2007 4:48:37 PM +0200 Aki Niemi > wrote: > >> * Section 3.2.19: treating unknown VALUE data types. Rather than >> treating unrecognized values as TEXT, I think the draft should instruct >> implementations to ignore them: >> >> OLD: >> >> Applications MUST treat x-name and iana-token value they don't >> recognized the same way as the TEXT value. >> >> NEW: >> >> Applications MUST ignore x-name and iana-token values that they >> don't recognize. > > I don't like the word "ignore" in this context. It could give an > implementor the impression that they can simply not store that > property/value at all, and that would be wrong. > > However, you are right in that it is wrong to treat an unknown value > as TEXT. For example, say I had defined a new value type that was > almost like TEXT, but did not require the escaping mechanism. Well if > a client were to treat that as TEXT, and the value contained some > characters that would need escaping in a TEXT value, then when it > wrote out the value it would escape the content - that would of course > be wrong. > > Perhaps a better example would be to consider a client that did not > understand the RECUR value type - since that value does allow > unescaped semi-colons, treating it as TEXT would be wrong. > > My suggestion for alternative text: > > Applications MUST preserve the value data for x-name and iana-token > values that they don't recognize without attempting to interpret or > parse the value data. +1. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6891D7F7AA for ; Wed, 19 Dec 2007 07:43:01 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0AA5614227E for ; Wed, 19 Dec 2007 07:43:03 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-50 required=4 tests=[AWL=-0.067, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] 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 M1HA-FgbTL+2 for ; Wed, 19 Dec 2007 07:42:56 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 898CE142245 for ; Wed, 19 Dec 2007 07:42:56 -0800 (PST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBJFf6Av014236; Wed, 19 Dec 2007 17:41:19 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 17:41:05 +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); Wed, 19 Dec 2007 17:41:04 +0200 Received: from [172.21.43.33] (esdhcp04333.research.nokia.com [172.21.43.33]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lBJFf3Eu031958; Wed, 19 Dec 2007 17:41:03 +0200 Subject: Re: [Ietf-calsify] Chair review of draft-ietf-calsify-rfc2445bis From: Aki Niemi To: ext Cyrus Daboo In-Reply-To: <8C4EB5714B5008CFA16034ED@caldav.corp.apple.com> References: <1198075717.13738.82.camel@scotty> <8C4EB5714B5008CFA16034ED@caldav.corp.apple.com> Content-Type: text/plain Organization: Nokia-TP-MSW/Helsinki Date: Wed, 19 Dec 2007 17:41:57 +0200 Message-Id: <1198078917.13738.89.camel@scotty> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2007 15:41:04.0789 (UTC) FILETIME=[90BB0C50:01C84255] X-Nokia-AV: Clean Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2007 15:43:01 -0000 ke, 2007-12-19 kello 10:25 -0500, ext Cyrus Daboo kirjoitti: > Hi Aki, > > --On December 19, 2007 4:48:37 PM +0200 Aki Niemi > wrote: > > > * Section 3.2.19: treating unknown VALUE data types. Rather than > > treating unrecognized values as TEXT, I think the draft should instruct > > implementations to ignore them: > > > > OLD: > > > > Applications MUST treat x-name and iana-token value they don't > > recognized the same way as the TEXT value. > > > > NEW: > > > > Applications MUST ignore x-name and iana-token values that they > > don't recognize. > > I don't like the word "ignore" in this context. It could give an > implementor the impression that they can simply not store that > property/value at all, and that would be wrong. > > However, you are right in that it is wrong to treat an unknown value as > TEXT. For example, say I had defined a new value type that was almost like > TEXT, but did not require the escaping mechanism. Well if a client were to > treat that as TEXT, and the value contained some characters that would need > escaping in a TEXT value, then when it wrote out the value it would escape > the content - that would of course be wrong. > > Perhaps a better example would be to consider a client that did not > understand the RECUR value type - since that value does allow unescaped > semi-colons, treating it as TEXT would be wrong. > > My suggestion for alternative text: > > Applications MUST preserve the value data for x-name and iana-token > values that they don't recognize without attempting to interpret or > parse the value data. +1 Cheers, Aki Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6548F7F7AA for ; Wed, 19 Dec 2007 07:27:20 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0889C14227E for ; Wed, 19 Dec 2007 07:27:22 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-50 required=4 tests=[AWL=0.120, BAYES_00=-2.599] 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 1PTG5nhXD+3x for ; Wed, 19 Dec 2007 07:27:15 -0800 (PST) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 76300142274 for ; Wed, 19 Dec 2007 07:27:13 -0800 (PST) Received: from caldav.corp.apple.com ([17.101.32.44]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lBJFQ0jM023851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Dec 2007 10:26:07 -0500 Date: Wed, 19 Dec 2007 10:25:55 -0500 From: Cyrus Daboo To: Aki Niemi , Bernard Desruisseaux Subject: Re: [Ietf-calsify] Chair review of draft-ietf-calsify-rfc2445bis Message-ID: <8C4EB5714B5008CFA16034ED@caldav.corp.apple.com> In-Reply-To: <1198075717.13738.82.camel@scotty> References: <1198075717.13738.82.camel@scotty> 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 Cc: ietf-calsify X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2007 15:27:20 -0000 Hi Aki, --On December 19, 2007 4:48:37 PM +0200 Aki Niemi wrote: > * Section 3.2.19: treating unknown VALUE data types. Rather than > treating unrecognized values as TEXT, I think the draft should instruct > implementations to ignore them: > > OLD: > > Applications MUST treat x-name and iana-token value they don't > recognized the same way as the TEXT value. > > NEW: > > Applications MUST ignore x-name and iana-token values that they > don't recognize. I don't like the word "ignore" in this context. It could give an implementor the impression that they can simply not store that property/value at all, and that would be wrong. However, you are right in that it is wrong to treat an unknown value as TEXT. For example, say I had defined a new value type that was almost like TEXT, but did not require the escaping mechanism. Well if a client were to treat that as TEXT, and the value contained some characters that would need escaping in a TEXT value, then when it wrote out the value it would escape the content - that would of course be wrong. Perhaps a better example would be to consider a client that did not understand the RECUR value type - since that value does allow unescaped semi-colons, treating it as TEXT would be wrong. My suggestion for alternative text: Applications MUST preserve the value data for x-name and iana-token values that they don't recognize without attempting to interpret or parse the value data. -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C8B787F66D for ; Wed, 19 Dec 2007 06:49:02 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6B555142274 for ; Wed, 19 Dec 2007 06:49:04 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-50 required=4 tests=[AWL=-0.100, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2] 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 1Hv2SVfIXsFq for ; Wed, 19 Dec 2007 06:48:57 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3C700142201 for ; Wed, 19 Dec 2007 06:48:57 -0800 (PST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBJEmDQO011144; Wed, 19 Dec 2007 16:48:35 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 16:47:48 +0200 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 16:47:47 +0200 Received: from [172.21.43.33] (esdhcp04333.research.nokia.com [172.21.43.33]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lBJEliF7013817; Wed, 19 Dec 2007 16:47:44 +0200 From: Aki Niemi To: Bernard Desruisseaux Content-Type: text/plain Organization: Nokia-TP-MSW/Helsinki Date: Wed, 19 Dec 2007 16:48:37 +0200 Message-Id: <1198075717.13738.82.camel@scotty> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2007 14:47:47.0949 (UTC) FILETIME=[1F43F9D0:01C8424E] X-Nokia-AV: Clean Cc: ietf-calsify Subject: [Ietf-calsify] Chair review of draft-ietf-calsify-rfc2445bis X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2007 14:49:02 -0000 All, I've now reviewed RFC2445-bis, and am currently working on the PROTO writeup, which is a document that accompanies the draft as we request publication. I'll also send some typos and such to Bernard privately. Cheers, Aki Technical: ========== * Sec 3.2.3: an implementation should treat an unrecognized CUTYPE value as UNKNOWN as opposed to INDIVIDUAL: OLD: Applications MUST treat x-name and iana-token value they don't recognized the same way as the INDIVIDUAL value. NEW: Applications MUST treat x-name and iana-token value they don't recognized the same way as the UNKNOWN value. * Section 3.2.19: treating unknown VALUE data types. Rather than treating unrecognized values as TEXT, I think the draft should instruct implementations to ignore them: OLD: Applications MUST treat x-name and iana-token value they don't recognized the same way as the TEXT value. NEW: Applications MUST ignore x-name and iana-token values that they don't recognize. * Sec 3.2.4/3.2.5: the DELEGATED-TO and DELEGATED-FROM parameters say that the cal-address MUST be a mailto URI. However, the actual definition of cal-address is more liberal; it says MUST be a mailto URI but only when email is used as transport. Assuming DELEGATED-* can be used with any transport, either their definition needs to add the same transport disclaimer, or the MUST needs to be removed altogether (and rely only on cal-address definition here) * Sec 3.6.6: alarm component. I think it is useful to add a short note about dealing with alarm components from untrusted sources. I think there used to be some "handwaiving" about that in the security considerations, but I think it got removed. Suggest something like: OLD: The "ACTION" property is used within the "VALARM" calendar component to specify the type of action invoked when the alarm is triggered. The "VALARM" properties provide enough information for a specific action to be invoked. It is typically the responsibility of a "Calendar User Agent" (CUA) to deliver the alarm in the specified fashion. An "ACTION" property value of AUDIO specifies an alarm that causes a sound to be played to alert the user; DISPLAY specifies an alarm that causes a text message to be displayed to the user; and EMAIL specifies an alarm that causes an electronic email message to be delivered to one or more email addresses. NEW: The "ACTION" property is used within the "VALARM" calendar component to specify the type of action invoked when the alarm is triggered. The "VALARM" properties provide enough information for a specific action to be invoked. It is typically the responsibility of a "Calendar User Agent" (CUA) to deliver the alarm in the specified fashion. An "ACTION" property value of AUDIO specifies an alarm that causes a sound to be played to alert the user; DISPLAY specifies an alarm that causes a text message to be displayed to the user; and EMAIL specifies an alarm that causes an electronic email message to be delivered to one or more email addresses. Note: implementations should carefully consider whether they accept alarm components from untrusted sources, e.g., when importing calendar objects from external sources. One reasonable policy is to always ignore alarm components that the calendar user has not set herself, or at least ask for confirmation in such a case. * Section 8.1, 2nd sentence: what does this mean? Suggest removing it. > However, the implementation of the memo is in no way limited solely as > a MIME content type. Structure: ========== * Sec 3: it would help readability a lot to explain in the introduction some basics of iCalendar, and how exactly the section that follows is structured. Currently, it's easy to miss the bigger picture, as the section jumps directly into content lines formatting, and the data types used in properties, without a clear picture as to where and how they will be used. My proposal is to add the following passage to the top of Section 3: OLD: The following sections define the details of a Calendaring and Scheduling Core Object Specification. This information is intended to be an integral part of the MIME content type registration. In addition, this information can be used independent of such content registration. In particular, this memo has direct applicability for use as a calendaring and scheduling exchange format in file-, memory- or network-based transport mechanisms. NEW: The following sections define the details of a Calendaring and Scheduling Core Object Specification. The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of an iCalendar stream with one or more iCalendar objects. The body of the iCalendar object consists of a sequence of calendar properties and one or more calendar components. Section 3.1. defines the content line format; Section 3.2. defines the property parameter format; Section 3.3. defines the data types for property values; Section 3.4. defines the iCalendar object format; Section 3.5. defines the iCalendar property format; Section 3.6. defines the calendar component format; Section 3.7. defines calendar properties; and Sectiopn 3.8. defines calendar component properties. This information is intended to be an integral part of the MIME content type registration. In addition, this information can be used independent of such content registration. In particular, this memo has direct applicability for use as a calendaring and scheduling exchange format in file-, memory- or network-based transport mechanisms. * Sec 3.3.1: > No additional content value encoding (i.e., BACKSLASH character > encoding) is defined for this value type. This is the first time BACKSLASH character encoding is mentioned. What is it? Suggest adding a forward reference to Sec 3.3.11., where it is defined. Nits: ===== * Section 2, first sentence: RFC2119 doesn't have a "NOT RECOMMENDED" key word. (Caught by I-D nits tool) Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5BE5E8021C for ; Fri, 14 Dec 2007 12:27:59 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BCFF3142217 for ; Fri, 14 Dec 2007 12:28:00 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-50 required=4 tests=[AWL=1.308, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 O+u-qZG0Oqvp for ; Fri, 14 Dec 2007 12:27:54 -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 47D4614220E for ; Fri, 14 Dec 2007 12:27:54 -0800 (PST) Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id lBEKRkHA015638; Fri, 14 Dec 2007 13:27:46 -0700 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lBEKRiwB017904; Fri, 14 Dec 2007 13:27:44 -0700 Received: from bdesruis-ca.ca.oracle.com by acsmt351.oracle.com with ESMTP id 3443547171197664056; Fri, 14 Dec 2007 12:27:36 -0800 Message-ID: <4762E730.3010409@oracle.com> Date: Fri, 14 Dec 2007 15:27:28 -0500 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Gren Elliot Subject: Re: [Ietf-calsify] rfc2445/rfc2446/rfc2447 confusion ATTENDEE: TYPE= or CUTYPE= References: <4762B81B.4090806@scalix.com> In-Reply-To: <4762B81B.4090806@scalix.com> 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 Cc: ietf-calsify@osafoundation.org X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 20:27:59 -0000 Both draft-ietf-calsify-2446bis and draft-ietf-calsify-rfc2447bis should replace TYPE by CUTYPE. Cheers, Bernard Gren Elliot wrote: > Hi, > > There appears to be a contradiction between RFC 2445 (ICalendar) on one > hand and RFC2446 (iTIP) / RFC2447 (iMIP) on the other, which still seems > to be true in the latest calsify drafts I can see : > > http://tools.ietf.org/id/draft-ietf-calsify-rfc2445bis-07.txt > > 3.2.3. Calendar User Type > > Parameter Name: CUTYPE > > Purpose: To specify the type of calendar user specified by the > property. > > Format Definition: This property parameter is defined by the > following notation: > > cutypeparam = "CUTYPE" "=" > ("INDIVIDUAL" ; An individual > / "GROUP" ; A group of individuals > / "RESOURCE" ; A physical resource > / "ROOM" ; A room resource > / "UNKNOWN" ; Otherwise not known > / x-name ; Experimental type > / iana-token) ; Other IANA registered > ; type > ; Default is INDIVIDUAL > > Description: This parameter can be specified on properties with a > CAL-ADDRESS value type. The parameter identifies the type of > calendar user specified by the property. If not specified on a > property that allows this parameter, the default is INDIVIDUAL. > Applications MUST treat x-name and iana-token value they don't > recognized the same way as the INDIVIDUAL value. > > Example: > > ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org > > In particular, nowhere is a parameter with token "TYPE" defined. > > However, > http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-04.txt > Refers to a TYPE parameter and gives several examples, for instance : > > ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com > > RFC 2447 gives similar examples to the RFC 2446 form. > > It seems to me that RFC 2446 and RFC 2447 are out of step with common > usage, although I am seeing the odd message using TYPE instead of CUTYPE? > > I would like to see the drafts resolve this contradiction. > > Any thoughts? > Regards, > Gren. > > > _______________________________________________ > Ietf-calsify mailing list > Ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 873547FCD2 for ; Fri, 14 Dec 2007 09:06:52 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E5D231421FD for ; Fri, 14 Dec 2007 09:06:53 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] 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 DBJC2u0PDsHJ for ; Fri, 14 Dec 2007 09:06:45 -0800 (PST) Received: from mail.uk.scalix.com (mail.uk.scalix.com [85.118.4.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3D977142217 for ; Fri, 14 Dec 2007 09:06:44 -0800 (PST) Received: from mail.uk.scalix.com (localhost.localdomain [127.0.0.1]) by mail.uk.scalix.com (8.13.8/8.13.8) with ESMTP id lBEH6aTL027307 for ; Fri, 14 Dec 2007 17:06:36 GMT Received: from crowley.uk.scalix.com (crowley.uk.scalix.com [10.11.108.213]) by mail.uk.scalix.com (Scalix SMTP Relay 11.3.0.11333) via ESMTP; Fri, 14 Dec 2007 17:06:36 +0000 (GMT) Date: Fri, 14 Dec 2007 17:06:35 +0000 From: Gren Elliot To: ietf-calsify@osafoundation.org Message-ID: <4762B81B.4090806@scalix.com> x-scalix-Hops: 1 User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Subject: [Ietf-calsify] rfc2445/rfc2446/rfc2447 confusion ATTENDEE: TYPE= or CUTYPE= X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2007 17:06:52 -0000 Hi, There appears to be a contradiction between RFC 2445 (ICalendar) on one hand and RFC2446 (iTIP) / RFC2447 (iMIP) on the other, which still seems to be true in the latest calsify drafts I can see : http://tools.ietf.org/id/draft-ietf-calsify-rfc2445bis-07.txt 3.2.3. Calendar User Type Parameter Name: CUTYPE Purpose: To specify the type of calendar user specified by the property. Format Definition: This property parameter is defined by the following notation: cutypeparam = "CUTYPE" "=" ("INDIVIDUAL" ; An individual / "GROUP" ; A group of individuals / "RESOURCE" ; A physical resource / "ROOM" ; A room resource / "UNKNOWN" ; Otherwise not known / x-name ; Experimental type / iana-token) ; Other IANA registered ; type ; Default is INDIVIDUAL Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter identifies the type of calendar user specified by the property. If not specified on a property that allows this parameter, the default is INDIVIDUAL. Applications MUST treat x-name and iana-token value they don't recognized the same way as the INDIVIDUAL value. Example: ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org In particular, nowhere is a parameter with token "TYPE" defined. However, http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-04.txt Refers to a TYPE parameter and gives several examples, for instance : ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com RFC 2447 gives similar examples to the RFC 2446 form. It seems to me that RFC 2446 and RFC 2447 are out of step with common usage, although I am seeing the odd message using TYPE instead of CUTYPE? I would like to see the drafts resolve this contradiction. Any thoughts? Regards, Gren. Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 34EDB8094B for ; Tue, 11 Dec 2007 03:45:00 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5835014220C for ; Tue, 11 Dec 2007 03:45:01 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-50 required=4 tests=[AWL=0.501, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] 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 NXdmU9ktu4eL for ; Tue, 11 Dec 2007 03:44: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 7CCE6142217 for ; Tue, 11 Dec 2007 03:44:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.24,151,1196636400"; d="scan'208";a="559871" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2007 12:44:52 +0100 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 lBBBiqSh003706 for ; Tue, 11 Dec 2007 12:44:52 +0100 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp398.cisco.com [10.61.65.142]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBBBinmc000558 for ; Tue, 11 Dec 2007 11:44:52 GMT Message-ID: <475E7831.90901@cisco.com> Date: Tue, 11 Dec 2007 12:44:49 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "ietf-calsify@osafoundation.org" X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=969; t=1197373492; x=1198237492; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20driving=20to=20conclusion |Sender:=20; bh=Sa9Mm4NtsQXF1jXoG0CD3nAwh0nQsVavpA5EyqaXrqw=; b=a4aCe8+UxXbbiAYH1KopK4O86soW5igtArh44Eei9ny/2TajRdCtwrF/e4 SGcfmMl9WgSc1G0lg2udhoS2OAw/WYb0YvcwyFbXnQB2o17BocuIjSWt4LIs jja3vpBxfp; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [Ietf-calsify] driving to conclusion X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 11:45:00 -0000 Dear all, We held a fairly productive discussion last week in Vancouver. The minutes will be made available in due course. This having been said, the chairs would like to host conference calls for the purpose of discussing open issues for our open documents. Any decision claimed to be made in such a call would of course be subject to verification of consensus on this list. These calls are proposed to be held weekly on Wednesdays at 9:30am US/New_York with the exception of the weeks of December 24th and 31st. We will hold our first meeting next Wednesday, December 19 from 9:30am - 10:30am. All are welcome, but RSVPs are requested so I can arrange enough ports on the conference bridge. The agenda for the next call will be as follows: 1. Shepherd comments on RFC2445bis (Aki) 2. Any open issues with RFC2445bis 3. Open issues with RFC2446bis. If you are interested in participating, please send me an email. Thanks, Eliot Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3BFFB80C04 for ; Wed, 5 Dec 2007 13:23:34 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 46C5E1422FB for ; Wed, 5 Dec 2007 13:23:35 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-50 required=4 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 DhfSeOq3UvmI for ; Wed, 5 Dec 2007 13:23:29 -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 84A25142212 for ; Wed, 5 Dec 2007 13:23:29 -0800 (PST) Received: from [75.111.50.119] (helo=[192.168.0.103]) by redwood.morsemedia.net with esmtpa (Exim 4.68) (envelope-from ) id 1J01iL-0005JG-Lp; Wed, 05 Dec 2007 13:23:29 -0800 Message-ID: <475716CC.8010104@calconnect.org> Date: Wed, 05 Dec 2007 13:23:24 -0800 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ietf-calsify list Content-Type: multipart/alternative; boundary="------------070402090508060406030505" 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 - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: Subject: [Ietf-calsify] Registration is now open for CalConnect Roundtable XI and IOP Test Event, February 4-8, 2008 X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2007 21:23:35 -0000 This is a multi-part message in MIME format. --------------070402090508060406030505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit /This message is being sent to the IETF calendaring-related lists. My apologies if you receive it multiple times; nearly everyone seems to be on nearly all of these lists. Dave Thewlis./ *CalConnect Roundtable XI and IOP Test Event Registration is now open* Registration is now open for CalConnect Roundtable XI and IOP Test Event, February 4-8, 2008, hosted by Sun Microsystems in Menlo Park, California (San Francisco South Bay Area). Logistics information and links to the registration pages may be found at http://www.calconnect.org/roundtable11.shtml The IOP Test Event will occur from noon Monday the 4th through noon Wednesday the 6th; the Roundtable from noon Wednesday the 6th through (at least) noon Friday the 8th. Non-members of CalConnect are invited to attend a single Roundtable as an observer to determine whether or not joining CalConnect would be of benefit to you. Non-members may also attend a single CalConnect Interoperability Test Event as observers, as well. Information on observer status and registration is also linked from the above page. Registration for both member representatives and observer representatives is $350 for the Roundtable through January 15th, and $395 thereafter. Observer registration for the IOP test event is also $350. If you have any questions please contact me, and we hope to see you in February. Best Regards, Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------070402090508060406030505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This message is being sent to the IETF calendaring-related lists.  My apologies if you receive it multiple times; nearly everyone seems to be on nearly all of these lists.  Dave Thewlis.

CalConnect Roundtable XI and IOP Test Event Registration is now open

Registration is now open for CalConnect Roundtable XI and IOP Test Event, February 4-8, 2008, hosted by Sun Microsystems in Menlo Park, California (San Francisco South Bay Area).  Logistics information and links to the registration pages may be found at http://www.calconnect.org/roundtable11.shtml

The IOP Test Event will occur from noon Monday the 4th through noon Wednesday the 6th; the Roundtable from noon Wednesday the 6th through (at least) noon Friday the 8th. 

Non-members of CalConnect are invited to attend a single Roundtable as an observer to determine whether or not joining CalConnect would be of benefit to you.  Non-members may also attend a single CalConnect Interoperability Test Event as observers, as well.  Information on observer status and registration is also linked from the above page.

Registration for both member representatives and observer representatives is $350 for the Roundtable through January 15th, and $395 thereafter.  Observer registration for the IOP test event is also $350.

If you have any questions please contact me, and we hope to see you in February.

Best Regards,

Dave Thewlis
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------070402090508060406030505-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DF49880CDB for ; Tue, 4 Dec 2007 10:54:52 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DE1B6142209 for ; Tue, 4 Dec 2007 10:54:53 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[AWL=0.000, BAYES_00=-2.599] 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 YCMVfICsy14e for ; Tue, 4 Dec 2007 10:54:48 -0800 (PST) Received: from mulberrymail.com (piper.mulberrymail.com [151.201.22.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EAD391421FD for ; Tue, 4 Dec 2007 10:54:45 -0800 (PST) Received: from dhcp-14db.ietf70.org (dhcp-14db.ietf70.org [130.129.20.219]) (authenticated bits=0) by mulberrymail.com (8.13.6/8.13.6) with ESMTP id lB4IsbIE017782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 13:54:40 -0500 Date: Tue, 04 Dec 2007 10:54:36 -0800 From: Cyrus Daboo To: Andrew Daviel , ietf-calsify@osafoundation.org Subject: Re: [Ietf-calsify] Future-proofing VTIMEZONE Message-ID: In-Reply-To: References: 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-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2007 18:54:53 -0000 Hi Andrew, --On December 3, 2007 4:01:28 PM -0800 Andrew Daviel wrote: > I presume the intention is that repeating events (10:00 every Wednesday) > should be maintained in correct local time, regardless of DST changes. > But as I understand it, VTIMEZONE (at least in the Mozilla clients) > contains only the DST rules currently in effect (I admit, predicting > future rules is impossible and though Dr. Who might schedule meetings in > the past, most people don't). So if the rules change, pre-existing > repeating events will be wrong. (In Canada/USA, we just went through an > annoying and pointless (from an IT point of view) rule change, and the US > law leaves open the possibility of putting it all back how it was if > no-one saves energy. And Australia as I recall made a special change for > the 2000 Olymics. So this is not an unlikely scenario.) > > So VTIMEZONE doesn't really work. It would seem more useful to use some > defined list of timezones, e.g. Pozix or O/S system rules which hopefully > get updated, and then repeating events would be future-proofed against > most rule changes, not just for known DST transistions. (Locations might > still hop from one zone to another, e.g. a certain locality suddenly > decides to opt out of its parent zone's DST) Mostly what you are seeing is a client implementation detail. Its true that some clients truncate the full timezone data to just that portion needed to cover the events they are attached too. Whilst that is OK for those events as they stand at that time, as you note, it breaks if you try to change any of those events to a date outside of the truncated timezone. Other clients do send a complete representation of the timezone with the event data that does cover the future. However, changes to dst rules made in the future will cause a similar problem. To help resolve these issues the Calendaring and Scheduling Consortium (Calconnect) is working on the concept of a standard timezone registry and service that could be used to alleviate many of the current problems. The goals for this are: 1) Provide a standard namespace for timezones names (via an IANA registry). This would allow "formal" standardization of e.g. Olson TZ names, and names from other sources. 2) Define a protocol whereby a client can retrieve timezone data given just the name of a timezone. i.e. timezones can be passed "by reference" instead of "by value" in iCalendar data. 3) Provide a simple update mechanism by which clients can ensure their timezone data caches are up to date with the latest timezone information. Calconnect is still working on the preliminary requirements for this effort. The goal is to bring all this work to the IETF for formal specifications in an appropriate venue. Note that right now the focus of the Calsify WG is to revise the current specs, so we are all focussing on completing that work right now. -- Cyrus Daboo Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 05E02808BE for ; Mon, 3 Dec 2007 19:50:23 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EF99814220C for ; Mon, 3 Dec 2007 19:50:23 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-50 required=4 tests=[AWL=0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 EeA1kcuMPiya for ; Mon, 3 Dec 2007 19:50:18 -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 1EC7D1421F1 for ; Mon, 3 Dec 2007 19:50:17 -0800 (PST) Received: from [75.111.50.119] (helo=[192.168.0.102]) by redwood.morsemedia.net with esmtpa (Exim 4.68) (envelope-from ) id 1IzOnc-0004EZ-SD; Mon, 03 Dec 2007 19:50:21 -0800 Message-ID: <4754CE7B.607@calconnect.org> Date: Mon, 03 Dec 2007 19:50:19 -0800 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ietf-calsify list Subject: Re: [Ietf-calsify] Future-proofing VTIMEZONE References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040607070302040107030309" 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 - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2007 03:50:23 -0000 This is a multi-part message in MIME format. --------------040607070302040107030309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Andrew, You might take a look at http://www.calconnect.org/publications/icalendartimezoneproblemsandrecommendationsv1.0.pdf http://www.calconnect.org/publications/timezoneregistryandservicerecommendationsv1.0.pdf http://www.calconnect.org/tc-timezone.shtml Cheers, Dave Thewlis Andrew Daviel wrote: > > Apologies if this has been hammered to death already... I just joined, > and grepping archives for an unknown keyword is not always fruitful > > I've been trying to write a CalDAV server for Mozilla clients (OK, > according to the RFC it's not one because it doesn't implement all the > mandatory stuff..). > > I notice that events in 2445 are tagged with a TZID (I was a bit slow > realizing why; why not just translate everything to UTC). > > I presume the intention is that repeating events (10:00 every > Wednesday) should be maintained in correct local time, regardless of > DST changes. But as I understand it, VTIMEZONE (at least in the > Mozilla clients) contains only the DST rules currently in effect (I > admit, predicting future rules is impossible and though Dr. Who might > schedule meetings in the past, most people don't). So if the rules > change, pre-existing repeating events will be wrong. (In Canada/USA, > we just went through an annoying and pointless (from an IT point of > view) rule change, and the US law leaves open the possibility of > putting it all back how it was if no-one saves energy. And Australia > as I recall made a special change for the 2000 Olymics. So this is not > an unlikely scenario.) > > So VTIMEZONE doesn't really work. It would seem more useful to use > some defined list of timezones, e.g. Pozix or O/S system rules which > hopefully get updated, and then repeating events would be > future-proofed against most rule changes, not just for known DST > transistions. (Locations might still hop from one zone to another, > e.g. a certain locality suddenly decides to opt out of its parent > zone's DST) > > Perhaps the optional TZURL element is a solution to this. > if so, how many people are actually implementing it ? > -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------040607070302040107030309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Andrew,

You might take a look at

http://www.calconnect.org/publications/icalendartimezoneproblemsandrecommendationsv1.0.pdf

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

http://www.calconnect.org/tc-timezone.shtml

Cheers,

Dave Thewlis


Andrew Daviel wrote:

Apologies if this has been hammered to death already... I just joined, and grepping archives for an unknown keyword is not always fruitful

I've been trying to write a CalDAV server for Mozilla clients (OK, according to the RFC it's not one because it doesn't implement all the mandatory stuff..).

I notice that events in 2445 are tagged with a TZID (I was a bit slow realizing why; why not just translate everything to UTC).

I presume the intention is that repeating events (10:00 every Wednesday) should be maintained in correct local time, regardless of DST changes. But as I understand it, VTIMEZONE (at least in the Mozilla clients) contains only the DST rules currently in effect (I admit, predicting future rules is impossible and though Dr. Who might schedule meetings in the past, most people don't). So if the rules change, pre-existing repeating events will be wrong. (In Canada/USA, we just went through an annoying and pointless (from an IT point of view) rule change, and the US law leaves open the possibility of putting it all back how it was if no-one saves energy. And Australia as I recall made a special change for the 2000 Olymics. So this is not an unlikely scenario.)

So VTIMEZONE doesn't really work. It would seem more useful to use some defined list of timezones, e.g. Pozix or O/S system rules which hopefully get updated, and then repeating events would be future-proofed against most rule changes, not just for known DST transistions. (Locations might still hop from one zone to another, e.g. a certain locality suddenly decides to opt out of its parent zone's DST)

Perhaps the optional TZURL element is a solution to this.
if so, how many people are actually implementing it ?



--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------040607070302040107030309-- Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B63FE80CAC for ; Mon, 3 Dec 2007 16:01:53 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A1B58142206 for ; Mon, 3 Dec 2007 16:01:54 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-50 required=4 tests=[AWL=0.239, BAYES_00=-2.599] 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 loUOKuOr3S1a for ; Mon, 3 Dec 2007 16:01:30 -0800 (PST) Received: from andrew.triumf.ca (andrew.triumf.ca [142.90.106.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id EA4EA142209 for ; Mon, 3 Dec 2007 16:01:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by andrew.triumf.ca (8.12.11.20060308/8.12.8) with ESMTP id lB401S0x022024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 Dec 2007 16:01:28 -0800 Date: Mon, 3 Dec 2007 16:01:28 -0800 (PST) From: Andrew Daviel X-X-Sender: andrew@andrew.triumf.ca To: ietf-calsify@osafoundation.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [Ietf-calsify] Future-proofing VTIMEZONE X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2007 00:01:54 -0000 Apologies if this has been hammered to death already... I just joined, and grepping archives for an unknown keyword is not always fruitful I've been trying to write a CalDAV server for Mozilla clients (OK, according to the RFC it's not one because it doesn't implement all the mandatory stuff..). I notice that events in 2445 are tagged with a TZID (I was a bit slow realizing why; why not just translate everything to UTC). I presume the intention is that repeating events (10:00 every Wednesday) should be maintained in correct local time, regardless of DST changes. But as I understand it, VTIMEZONE (at least in the Mozilla clients) contains only the DST rules currently in effect (I admit, predicting future rules is impossible and though Dr. Who might schedule meetings in the past, most people don't). So if the rules change, pre-existing repeating events will be wrong. (In Canada/USA, we just went through an annoying and pointless (from an IT point of view) rule change, and the US law leaves open the possibility of putting it all back how it was if no-one saves energy. And Australia as I recall made a special change for the 2000 Olymics. So this is not an unlikely scenario.) So VTIMEZONE doesn't really work. It would seem more useful to use some defined list of timezones, e.g. Pozix or O/S system rules which hopefully get updated, and then repeating events would be future-proofed against most rule changes, not just for known DST transistions. (Locations might still hop from one zone to another, e.g. a certain locality suddenly decides to opt out of its parent zone's DST) Perhaps the optional TZURL element is a solution to this. if so, how many people are actually implementing it ? -- Andrew Daviel, TRIUMF, Canada Tel. +1 (604) 222-7376 (Pacific Time) Network Security Manager Return-Path: X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F3129808F6 for ; Sun, 2 Dec 2007 18:01:00 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DE84C142202 for ; Sun, 2 Dec 2007 18:01:01 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-50 required=4 tests=[AWL=0.246, BAYES_00=-2.599, HTML_00_10=0.795, HTML_MESSAGE=0.001] 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 jT4VWZJNfWiY for ; Sun, 2 Dec 2007 18:00:56 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8F8AC1421FF for ; Sun, 2 Dec 2007 18:00:56 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j40so5107568wah for ; Sun, 02 Dec 2007 18:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=jDew9kOx5N7rq7E+a891fyk3jNh15lXThva/t+S2YcM=; b=RYzIXgUc+m0y104S5ScAafJ00KN7eJb8e0/EeOph9K4Ww6KB/96G2LtJQvULF0FRB2g6U0l775kK9gI5pOZWGc6GamqxQQtRKilenTTlXkjkn7ygAvrE5rkuSb4SLWydV+d69HXOWC9ZdmbSCPYRL/5PgMLhL2MTwL/aXUGwuak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:mime-version:content-type; b=UZ807QKr2cUjSAT/NolL9We/jRS4hf81a53xNf2e8L3oEyUhOIl4fxJmUZ9bunwsDh7rYgEIKv5hvrjAEhpKIBGK4qRAj49MN0qhJkhYJiIpyyw1AtM8Ubywww2/95nAWmY17jUnXwlGf8qGzMBVL4BfRuOhKwxHutwS2C7wCEE= Received: by 10.142.171.6 with SMTP id t6mr276178wfe.1196645604175; Sun, 02 Dec 2007 17:33:24 -0800 (PST) Received: by 10.142.49.6 with HTTP; Sun, 2 Dec 2007 17:33:24 -0800 (PST) Message-ID: Date: Sun, 2 Dec 2007 22:33:24 -0300 From: "=?ISO-8859-1?Q?F=E1bio_Henrique_da_Silva?=" To: "ietf-calsify@osafoundation.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6579_26767612.1196645604165" Subject: [Ietf-calsify] Patterns on restriction tables for 2446bis X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 02:01:01 -0000 ------=_Part_6579_26767612.1196645604165 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, There is not a clear pattern on the order of the properties and components (lexicographic / by presence), or on the text of the comments among the several restriction tables that describe iTIP methods (similar behaviors ar= e described in different ways). Is there any intention of organizing the restriction tables in this sense? Regards, F=E1bio Silva. ------=_Part_6579_26767612.1196645604165 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all,

There is not a clear pattern on the order of the properties = and components (lexicographic / by presence), or on the text of the comment= s among the several restriction tables that describe iTIP methods (similar = behaviors are described in different ways).
Is there any intention of organizing the restriction tables in this sen= se?

Regards,

F=E1bio Silva.
------=_Part_6579_26767612.1196645604165--