From ietf-calsify-bounces@osafoundation.org Tue Jun 9 08:41:13 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6777528C163 for ; Tue, 9 Jun 2009 08:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgscNY5EWOPZ for ; Tue, 9 Jun 2009 08:41:11 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id D54FC3A69D1 for ; Tue, 9 Jun 2009 08:41:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 85EBA794040; Tue, 9 Jun 2009 08:41:14 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG0wg9557tAC; Tue, 9 Jun 2009 08:41:07 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id B5E6579403F; Tue, 9 Jun 2009 08:41:03 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id C23CE794037 for ; Tue, 9 Jun 2009 08:41:00 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ6WFX1FfGRR for ; Tue, 9 Jun 2009 08:40:51 -0700 (PDT) Received: from mail.uk.scalix.com (mail.uk.scalix.com [82.111.253.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id C84D779403F for ; Tue, 9 Jun 2009 08:40:50 -0700 (PDT) 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 n59FefYp003769 for ; Tue, 9 Jun 2009 16:40:41 +0100 Received: from copper.uk.scalix.com (copper.uk.scalix.com [10.11.108.128]) by mail.uk.scalix.com (Scalix SMTP Relay 11.4.4.12886) via ESMTP; Tue, 09 Jun 2009 16:40:40 +0100 (BST) Date: Tue, 9 Jun 2009 16:40:40 +0100 From: Gren Elliot To: ietf-calsify@osafoundation.org Message-ID: <4A2E8278.90808@scalix.com> x-scalix-Hops: 1 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 X-SMP-CT-RefID: str=0001.0A0B0209.4A2E8278.0299,ss=1,fgs=0 MIME-Version: 1.0 Subject: [ietf-calsify] DTSTART in VTIMEZONE STANDARD and DAYLIGHT sub-components - localtime, but which localtime? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0050352173==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --===============0050352173== Content-Type: multipart/alternative; boundary="------------080400070708020400030901" --------------080400070708020400030901 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Hi, I'm looking for clarification as to what localtime means inside a STANDARD or DAYLIGHT component in the context of the value to assign to DTSTART, and also hoping that draft-ietf-calsify-rfc2445bis-10 will get updated to make it clearer in this area. Specifically, if the localtime is changing from 2am to 3am at the onset time for a VTIMEZONE sub-component, should DTSTART reflect the 2am time or the 3am time? I've ended up thinking about this because I'm in the process of testing out the latest libical code for our use (http://sourceforge.net/projects/freeassociation/) With our previous cut of the libical code, timezone information corresponding to, say, Europe/Zurich used to come from one of libical's own files : .../zoneinfo/Europe/Zurich.ics The new code appears to work from a combination of /usr/share/zoneinfo/zone.tab and /usr/share/zoneinfo/Europe/Zurich - which are part of the linux system "tzdata" package. Great, I thought. I can rely on the OS to keep the timezone info up to date. However, the timezone I'm getting from this differs from the timezone I used to get. This is the new version : BEGIN:VTIMEZONE TZID:/freeassociation.sourceforge.net/Tzfile/Europe/Zurich X-LIC-LOCATION:Europe/Zurich BEGIN:STANDARD TZNAME:CET DTSTART:19701025T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 END:STANDARD BEGIN:DAYLIGHT TZNAME:CEST DTSTART:19700328T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 END:DAYLIGHT END:VTIMEZONE The only difference (apart from component and property ordering) from the old version is that the DTSTART in the STANDARD component used to be : DTSTART:19701025T030000 and in the DAYLIGHT component it used to be : DTSTART:19700329T020000 i.e. The opposite way around to the above... Looking at http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-10 Section 3.6.5, you get this description of what DTSTART should look like in a VTIMEZONE (section 3.8.2.4 on DTSTART in isolation is similar) : The mandatory "DTSTART" property gives the effective onset date and local time for the time zone sub-component definition. "DTSTART" in this usage MUST be specified as a date with local time value. The problem with this is that there are 2 fairly common sense ways of thinking about what the localtime is at this point. If I want to know when to change my clock from STANDARD to DAYLIGHT time, I wait until the time of the change in STANDARD time (say 2am) and spring my clock forward to 3am at that point. If, however, I'm looking at the DAYLIGHT component, I'm tempted to think that localtime for that instant is the localtime in the DAYLIGHT component - i.e. 3am. This difference in view seems consistent with the difference between the new and old VTIMEZONE definitions, however I haven't noticed anything yet which shouts out which is correct. Thoughts? Regards, Gren Elliot P.S. http://www.timeanddate.com/worldclock/city.html?n=268 says that DST started on Sunday, 29 March 2009, 02:00 local standard time DST ends on Sunday, 25 October 2009, 03:00 local daylight time which would imply that the time is the time just before the onset, which would imply a world view where the old code was correct. --------------080400070708020400030901 Content-Type: text/html; charset="US-ASCII" Content-Disposition: inline Hi,

I'm looking for clarification as to what localtime means inside a STANDARD or DAYLIGHT component in the context of the value to assign to DTSTART, and also hoping that draft-ietf-calsify-rfc2445bis-10 will get updated to make it clearer in this area.  Specifically, if the localtime is changing from 2am to 3am at the onset time for a VTIMEZONE sub-component, should DTSTART reflect the 2am time or the 3am time?

I've ended up thinking about this because I'm in the process of testing out the latest libical code for our use (http://sourceforge.net/projects/freeassociation/)

With our previous cut of the libical code, timezone information corresponding to, say, Europe/Zurich used to come from one of libical's own files :
     .../zoneinfo/Europe/Zurich.ics

The new code appears to work from a combination of /usr/share/zoneinfo/zone.tab and /usr/share/zoneinfo/Europe/Zurich - which are part of the linux system "tzdata" package.  Great, I thought.  I can rely on the OS to keep the timezone info up to date.  However, the timezone I'm getting from this differs from the timezone I used to get.

This is the new version :

BEGIN:VTIMEZONE
TZID:/freeassociation.sourceforge.net/Tzfile/Europe/Zurich
X-LIC-LOCATION:Europe/Zurich
BEGIN:STANDARD
TZNAME:CET
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CEST
DTSTART:19700328T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE

The only difference (apart from component and property ordering) from the old version is that the DTSTART in the STANDARD component used to be :
    DTSTART:19701025T030000
and in the DAYLIGHT component it used to be :
    DTSTART:19700329T020000
i.e.  The opposite way around to the above...

Looking at http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-10 Section 3.6.5, you get this description of what DTSTART should look like in a VTIMEZONE  (section 3.8.2.4 on DTSTART in isolation is similar) :
      The mandatory "DTSTART" property gives the effective onset date
      and local time for the time zone sub-component definition.
      "DTSTART" in this usage MUST be specified as a date with local
      time value.

The problem with this is that there are 2 fairly common sense ways of thinking about what the localtime is at this point.  If I want to know when to change my clock from STANDARD to DAYLIGHT time, I wait until the time of the change in STANDARD time (say 2am) and spring my clock forward to 3am at that point.
If, however, I'm looking at the DAYLIGHT component, I'm tempted to think that localtime for that instant is the localtime in the DAYLIGHT component - i.e. 3am.

This difference in view seems consistent with the difference between the new and old VTIMEZONE definitions, however I haven't noticed anything yet which shouts out which is correct.

Thoughts?

Regards,
Gren Elliot

P.S.
http://www.timeanddate.com/worldclock/city.html?n=268
says that
DST started on Sunday, 29 March 2009, 02:00 local standard time
DST ends on Sunday, 25 October 2009, 03:00 local daylight time
which would imply that the time is the time just before the onset, which would imply a world view where the old code was correct.
--------------080400070708020400030901-- --===============0050352173== 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 --===============0050352173==-- From calsify-bounces@ietf.org Tue Jun 9 11:49:08 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E03128C1CA for ; Tue, 9 Jun 2009 11:49:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Welcome to the "calsify" mailing list From: calsify-request@ietf.org To: calsify-archive-feit0ahl@lists.ietf.org X-No-Archive: yes Message-ID: Date: Tue, 09 Jun 2009 11:49:07 -0700 Precedence: bulk X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org Welcome to the calsify@ietf.org mailing list! Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public. To post to this list, send your email to: calsify@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/calsify If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://www.ietf.org/mailman/options/calsify/calsify-archive-feit0ahl%40lists.ietf.org You can also make such adjustments via email by sending a message to: calsify-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: SjASj+HN Normally, Mailman will remind you of your ietf.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. From ietf-calsify-bounces@osafoundation.org Tue Jun 9 12:08:39 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921483A6D64 for ; Tue, 9 Jun 2009 12:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1XrlMCgEXfn for ; Tue, 9 Jun 2009 12:08:38 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 5CEB93A6818 for ; Tue, 9 Jun 2009 12:08:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 38742794042; Tue, 9 Jun 2009 12:08:44 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGMGNWDB0HvP; Tue, 9 Jun 2009 12:08:38 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 7F34A794040; Tue, 9 Jun 2009 12:08:36 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 25070794040 for ; Tue, 9 Jun 2009 12:08:34 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHQ-fZfW4J4Q for ; Tue, 9 Jun 2009 12:08:26 -0700 (PDT) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 1F81D79403F for ; Tue, 9 Jun 2009 12:08:25 -0700 (PDT) Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59J9DQK021234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 9 Jun 2009 19:09:14 GMT Received: from hqdfmt01.oracle.com (hqdfmt01.oracle.com [148.87.35.11]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n59J8UGt001184; Tue, 9 Jun 2009 19:08:37 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Jun 2009 12:08:12 -0700 Message-ID: <4A2EB317.40403@oracle.com> Date: Tue, 09 Jun 2009 15:08:07 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gren Elliot References: <4A2E8278.90808@scalix.com> In-Reply-To: <4A2E8278.90808@scalix.com> X-Source-IP: hqdfmt01.oracle.com [148.87.35.11] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4A2EB324.01B3:SCFSTAT3499757,ss=1,fgs=0 Cc: ietf-calsify@osafoundation.org Subject: Re: [ietf-calsify] DTSTART in VTIMEZONE STANDARD and DAYLIGHT sub-components - localtime, but which localtime? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi Gren, See Section 3.6.5. Time Zone Component: > The mandatory "DTSTART" property gives the effective onset date > and local time for the time zone sub-component definition. > "DTSTART" in this usage MUST be specified as a date with local > time value. > > The mandatory "TZOFFSETFROM" property gives the UTC offset which > is in use when the onset of this time zone observance begins. > "TZOFFSETFROM" is combined with "DTSTART" to define the effective > onset for the time zone sub-component definition. For example, > the following represents the time at which the observance of > Standard Time took effect in Fall 1967 for New York City: > > DTSTART:19671029T020000 > > TZOFFSETFROM:-0400 Cheers, Bernard Gren Elliot wrote: > Hi, > > I'm looking for clarification as to what localtime means inside a > STANDARD or DAYLIGHT component in the context of the value to assign to > DTSTART, and also hoping that draft-ietf-calsify-rfc2445bis-10 will get > updated to make it clearer in this area. Specifically, if the localtime > is changing from 2am to 3am at the onset time for a VTIMEZONE > sub-component, should DTSTART reflect the 2am time or the 3am time? > > I've ended up thinking about this because I'm in the process of testing > out the latest libical code for our use > (http://sourceforge.net/projects/freeassociation/) > > With our previous cut of the libical code, timezone information > corresponding to, say, Europe/Zurich used to come from one of libical's > own files : > .../zoneinfo/Europe/Zurich.ics > > The new code appears to work from a combination of > /usr/share/zoneinfo/zone.tab and /usr/share/zoneinfo/Europe/Zurich - > which are part of the linux system "tzdata" package. Great, I thought. > I can rely on the OS to keep the timezone info up to date. However, the > timezone I'm getting from this differs from the timezone I used to get. > > This is the new version : > > BEGIN:VTIMEZONE > TZID:/freeassociation.sourceforge.net/Tzfile/Europe/Zurich > X-LIC-LOCATION:Europe/Zurich > BEGIN:STANDARD > TZNAME:CET > DTSTART:19701025T020000 > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 > TZOFFSETFROM:+0200 > TZOFFSETTO:+0100 > END:STANDARD > BEGIN:DAYLIGHT > TZNAME:CEST > DTSTART:19700328T030000 > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 > TZOFFSETFROM:+0100 > TZOFFSETTO:+0200 > END:DAYLIGHT > END:VTIMEZONE > > The only difference (apart from component and property ordering) from > the old version is that the DTSTART in the STANDARD component used to be : > DTSTART:19701025T030000 > and in the DAYLIGHT component it used to be : > DTSTART:19700329T020000 > i.e. The opposite way around to the above... > > Looking at http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-10 > Section 3.6.5, you get this description of what DTSTART should look like > in a VTIMEZONE (section 3.8.2.4 on DTSTART in isolation is similar) : > The mandatory "DTSTART" property gives the effective onset date > and local time for the time zone sub-component definition. > "DTSTART" in this usage MUST be specified as a date with local > time value. > > The problem with this is that there are 2 fairly common sense ways of > thinking about what the localtime is at this point. If I want to know > when to change my clock from STANDARD to DAYLIGHT time, I wait until the > time of the change in STANDARD time (say 2am) and spring my clock > forward to 3am at that point. > If, however, I'm looking at the DAYLIGHT component, I'm tempted to think > that localtime for that instant is the localtime in the DAYLIGHT > component - i.e. 3am. > > This difference in view seems consistent with the difference between the > new and old VTIMEZONE definitions, however I haven't noticed anything > yet which shouts out which is correct. > > Thoughts? > > Regards, > Gren Elliot > > P.S. > http://www.timeanddate.com/worldclock/city.html?n=268 > says that > DST started > on > Sunday, 29 March 2009, 02:00 local standard time > DST ends > on Sunday, 25 October 2009, 03:00 local daylight time > which would imply that the time is the time just before the onset, which > would imply a world view where the old code was correct. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Tue Jun 9 14:26:51 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3713A6CBE for ; Tue, 9 Jun 2009 14:26:51 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "References" X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un1aFYFAPxnu for ; Tue, 9 Jun 2009 14:26:50 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 68D6B3A6C6B for ; Tue, 9 Jun 2009 14:26:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 9BD1979403F; Tue, 9 Jun 2009 14:26:56 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvbQEdE8RnH3; Tue, 9 Jun 2009 14:26:49 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 4F71F794040; Tue, 9 Jun 2009 14:26:47 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 66EE2794040 for ; Tue, 9 Jun 2009 14:26:44 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHZF13wSi5Ag for ; Tue, 9 Jun 2009 14:26:33 -0700 (PDT) Received: from mail.uk.scalix.com (mail.uk.scalix.com [82.111.253.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 55C6579403F for ; Tue, 9 Jun 2009 14:26:33 -0700 (PDT) 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 n59LQA19009535; Tue, 9 Jun 2009 22:26:11 +0100 Received: from grens-macbook.local (i-195-137-42-164.freedom2surf.net [195.137.42.164]) by mail.uk.scalix.com (Scalix SMTP Relay 11.4.4.12886) via ESMTP; Tue, 09 Jun 2009 22:26:08 +0100 (BST) Date: Tue, 9 Jun 2009 22:26:06 +0100 From: Gren Elliot To: Bernard Desruisseaux Message-ID: <4A2ED36E.1010201@scalix.com> In-Reply-To: <4A2EB317.40403@oracle.com> References: <4A2E8278.90808@scalix.com> References: <4A2EB317.40403@oracle.com> x-scalix-Hops: 1 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 X-SMP-CT-RefID: str=0001.0A0B0203.4A2ED371.01DA,ss=1,fgs=0 MIME-Version: 1.0 Content-Disposition: inline Cc: ietf-calsify@osafoundation.org, calsify@ietf.org Subject: Re: [ietf-calsify] DTSTART in VTIMEZONE STANDARD and DAYLIGHT sub-components - localtime, but which localtime? X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hi Bernard, Thanks for your response to my query - originally posted to ietf-calsify@osafoundation.org. I assume I was posting to the wrong place, as I received a couple of new invites to ietf.org mailing lists (Thank you to whoever initiated that). Ok, I think I understand that now. Wording of these things is really tricky! A possible re-phrasing might be : The mandatory "DTSTART" property gives the effective onset date and local time for the time zone sub-component definition. "DTSTART" in this usage MUST be specified as a date with local time value. The UTC offset associated with "DTSTART" is specified in the "TZOFFSETFROM" property. The mandatory "TZOFFSETFROM" property gives the UTC offset which is in use immediately before the onset of this time zone observance begins. For example, the following represents the time at which the observance of Standard Time took effect in Fall 1967 for New York City: ... Regards, Gren. On 9/6/09 20:08, Bernard Desruisseaux wrote: > Hi Gren, > > See Section 3.6.5. Time Zone Component: > > > The mandatory "DTSTART" property gives the effective onset date > > and local time for the time zone sub-component definition. > > "DTSTART" in this usage MUST be specified as a date with local > > time value. > > > > The mandatory "TZOFFSETFROM" property gives the UTC offset which > > is in use when the onset of this time zone observance begins. > > "TZOFFSETFROM" is combined with "DTSTART" to define the effective > > onset for the time zone sub-component definition. For example, > > the following represents the time at which the observance of > > Standard Time took effect in Fall 1967 for New York City: > > > > DTSTART:19671029T020000 > > > > TZOFFSETFROM:-0400 > > Cheers, > Bernard > > > Gren Elliot wrote: >> Hi, >> >> I'm looking for clarification as to what localtime means inside a >> STANDARD or DAYLIGHT component in the context of the value to assign >> to DTSTART, and also hoping that draft-ietf-calsify-rfc2445bis-10 >> will get updated to make it clearer in this area. Specifically, if >> the localtime is changing from 2am to 3am at the onset time for a >> VTIMEZONE sub-component, should DTSTART reflect the 2am time or the >> 3am time? >> >> I've ended up thinking about this because I'm in the process of >> testing out the latest libical code for our use >> (http://sourceforge.net/projects/freeassociation/) >> >> With our previous cut of the libical code, timezone information >> corresponding to, say, Europe/Zurich used to come from one of >> libical's own files : >> .../zoneinfo/Europe/Zurich.ics >> >> The new code appears to work from a combination of >> /usr/share/zoneinfo/zone.tab and /usr/share/zoneinfo/Europe/Zurich - >> which are part of the linux system "tzdata" package. Great, I >> thought. I can rely on the OS to keep the timezone info up to date. >> However, the timezone I'm getting from this differs from the timezone >> I used to get. >> >> This is the new version : >> >> BEGIN:VTIMEZONE >> TZID:/freeassociation.sourceforge.net/Tzfile/Europe/Zurich >> X-LIC-LOCATION:Europe/Zurich >> BEGIN:STANDARD >> TZNAME:CET >> DTSTART:19701025T020000 >> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 >> TZOFFSETFROM:+0200 >> TZOFFSETTO:+0100 >> END:STANDARD >> BEGIN:DAYLIGHT >> TZNAME:CEST >> DTSTART:19700328T030000 >> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 >> TZOFFSETFROM:+0100 >> TZOFFSETTO:+0200 >> END:DAYLIGHT >> END:VTIMEZONE >> >> The only difference (apart from component and property ordering) from >> the old version is that the DTSTART in the STANDARD component used to >> be : >> DTSTART:19701025T030000 >> and in the DAYLIGHT component it used to be : >> DTSTART:19700329T020000 >> i.e. The opposite way around to the above... >> >> Looking at >> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-10 Section >> 3.6.5, you get this description of what DTSTART should look like in a >> VTIMEZONE (section 3.8.2.4 on DTSTART in isolation is similar) : >> The mandatory "DTSTART" property gives the effective onset date >> and local time for the time zone sub-component definition. >> "DTSTART" in this usage MUST be specified as a date with local >> time value. >> >> The problem with this is that there are 2 fairly common sense ways of >> thinking about what the localtime is at this point. If I want to >> know when to change my clock from STANDARD to DAYLIGHT time, I wait >> until the time of the change in STANDARD time (say 2am) and spring my >> clock forward to 3am at that point. >> If, however, I'm looking at the DAYLIGHT component, I'm tempted to >> think that localtime for that instant is the localtime in the >> DAYLIGHT component - i.e. 3am. >> >> This difference in view seems consistent with the difference between >> the new and old VTIMEZONE definitions, however I haven't noticed >> anything yet which shouts out which is correct. >> >> Thoughts? >> >> Regards, >> Gren Elliot >> >> P.S. >> http://www.timeanddate.com/worldclock/city.html?n=268 >> says that >> DST started >> on >> Sunday, 29 March 2009, 02:00 local standard time >> DST ends >> on >> Sunday, 25 October 2009, 03:00 local daylight time >> which would imply that the time is the time just before the onset, >> which would imply a world view where the old code was correct. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 gren.elliot@scalix.com Tue Jun 9 14:26:21 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9883A6C6B for ; Tue, 9 Jun 2009 14:26:21 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "References" X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQF3ZC81vdso for ; Tue, 9 Jun 2009 14:26:20 -0700 (PDT) Received: from mail.uk.scalix.com (mail.uk.scalix.com [82.111.253.243]) by core3.amsl.com (Postfix) with ESMTP id E52073A698C for ; Tue, 9 Jun 2009 14:26:16 -0700 (PDT) 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 n59LQA19009535; Tue, 9 Jun 2009 22:26:11 +0100 Received: from grens-macbook.local (i-195-137-42-164.freedom2surf.net [195.137.42.164]) by mail.uk.scalix.com (Scalix SMTP Relay 11.4.4.12886) via ESMTP; Tue, 09 Jun 2009 22:26:08 +0100 (BST) Date: Tue, 9 Jun 2009 22:26:06 +0100 From: Gren Elliot To: Bernard Desruisseaux Message-ID: <4A2ED36E.1010201@scalix.com> In-Reply-To: <4A2EB317.40403@oracle.com> References: <4A2E8278.90808@scalix.com> References: <4A2EB317.40403@oracle.com> x-scalix-Hops: 1 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 X-SMP-CT-RefID: str=0001.0A0B0203.4A2ED371.01DA,ss=1,fgs=0 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format="flowed" Content-Disposition: inline Cc: ietf-calsify@osafoundation.org, calsify@ietf.org Subject: Re: [calsify] [ietf-calsify] DTSTART in VTIMEZONE STANDARD and DAYLIGHT sub-components - localtime, but which localtime? X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 21:27:53 -0000 Hi Bernard, Thanks for your response to my query - originally posted to ietf-calsify@osafoundation.org. I assume I was posting to the wrong place, as I received a couple of new invites to ietf.org mailing lists (Thank you to whoever initiated that). Ok, I think I understand that now. Wording of these things is really tricky! A possible re-phrasing might be : The mandatory "DTSTART" property gives the effective onset date and local time for the time zone sub-component definition. "DTSTART" in this usage MUST be specified as a date with local time value. The UTC offset associated with "DTSTART" is specified in the "TZOFFSETFROM" property. The mandatory "TZOFFSETFROM" property gives the UTC offset which is in use immediately before the onset of this time zone observance begins. For example, the following represents the time at which the observance of Standard Time took effect in Fall 1967 for New York City: ... Regards, Gren. On 9/6/09 20:08, Bernard Desruisseaux wrote: > Hi Gren, > > See Section 3.6.5. Time Zone Component: > > > The mandatory "DTSTART" property gives the effective onset date > > and local time for the time zone sub-component definition. > > "DTSTART" in this usage MUST be specified as a date with local > > time value. > > > > The mandatory "TZOFFSETFROM" property gives the UTC offset which > > is in use when the onset of this time zone observance begins. > > "TZOFFSETFROM" is combined with "DTSTART" to define the effective > > onset for the time zone sub-component definition. For example, > > the following represents the time at which the observance of > > Standard Time took effect in Fall 1967 for New York City: > > > > DTSTART:19671029T020000 > > > > TZOFFSETFROM:-0400 > > Cheers, > Bernard > > > Gren Elliot wrote: >> Hi, >> >> I'm looking for clarification as to what localtime means inside a >> STANDARD or DAYLIGHT component in the context of the value to assign >> to DTSTART, and also hoping that draft-ietf-calsify-rfc2445bis-10 >> will get updated to make it clearer in this area. Specifically, if >> the localtime is changing from 2am to 3am at the onset time for a >> VTIMEZONE sub-component, should DTSTART reflect the 2am time or the >> 3am time? >> >> I've ended up thinking about this because I'm in the process of >> testing out the latest libical code for our use >> (http://sourceforge.net/projects/freeassociation/) >> >> With our previous cut of the libical code, timezone information >> corresponding to, say, Europe/Zurich used to come from one of >> libical's own files : >> .../zoneinfo/Europe/Zurich.ics >> >> The new code appears to work from a combination of >> /usr/share/zoneinfo/zone.tab and /usr/share/zoneinfo/Europe/Zurich - >> which are part of the linux system "tzdata" package. Great, I >> thought. I can rely on the OS to keep the timezone info up to date. >> However, the timezone I'm getting from this differs from the timezone >> I used to get. >> >> This is the new version : >> >> BEGIN:VTIMEZONE >> TZID:/freeassociation.sourceforge.net/Tzfile/Europe/Zurich >> X-LIC-LOCATION:Europe/Zurich >> BEGIN:STANDARD >> TZNAME:CET >> DTSTART:19701025T020000 >> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 >> TZOFFSETFROM:+0200 >> TZOFFSETTO:+0100 >> END:STANDARD >> BEGIN:DAYLIGHT >> TZNAME:CEST >> DTSTART:19700328T030000 >> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 >> TZOFFSETFROM:+0100 >> TZOFFSETTO:+0200 >> END:DAYLIGHT >> END:VTIMEZONE >> >> The only difference (apart from component and property ordering) from >> the old version is that the DTSTART in the STANDARD component used to >> be : >> DTSTART:19701025T030000 >> and in the DAYLIGHT component it used to be : >> DTSTART:19700329T020000 >> i.e. The opposite way around to the above... >> >> Looking at >> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-10 Section >> 3.6.5, you get this description of what DTSTART should look like in a >> VTIMEZONE (section 3.8.2.4 on DTSTART in isolation is similar) : >> The mandatory "DTSTART" property gives the effective onset date >> and local time for the time zone sub-component definition. >> "DTSTART" in this usage MUST be specified as a date with local >> time value. >> >> The problem with this is that there are 2 fairly common sense ways of >> thinking about what the localtime is at this point. If I want to >> know when to change my clock from STANDARD to DAYLIGHT time, I wait >> until the time of the change in STANDARD time (say 2am) and spring my >> clock forward to 3am at that point. >> If, however, I'm looking at the DAYLIGHT component, I'm tempted to >> think that localtime for that instant is the localtime in the >> DAYLIGHT component - i.e. 3am. >> >> This difference in view seems consistent with the difference between >> the new and old VTIMEZONE definitions, however I haven't noticed >> anything yet which shouts out which is correct. >> >> Thoughts? >> >> Regards, >> Gren Elliot >> >> P.S. >> http://www.timeanddate.com/worldclock/city.html?n=268 >> says that >> DST started >> on >> Sunday, 29 March 2009, 02:00 local standard time >> DST ends >> on >> Sunday, 25 October 2009, 03:00 local daylight time >> which would imply that the time is the time just before the onset, >> which would imply a world view where the old code was correct. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> ietf-calsify mailing list >> ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > From calsify-bounces@ietf.org Tue Jun 9 14:27:59 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D8C3A6DCB; Tue, 9 Jun 2009 14:27:59 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE9883A6C6B for ; Tue, 9 Jun 2009 14:26:21 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "References" X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQF3ZC81vdso for ; Tue, 9 Jun 2009 14:26:20 -0700 (PDT) Received: from mail.uk.scalix.com (mail.uk.scalix.com [82.111.253.243]) by core3.amsl.com (Postfix) with ESMTP id E52073A698C for ; Tue, 9 Jun 2009 14:26:16 -0700 (PDT) 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 n59LQA19009535; Tue, 9 Jun 2009 22:26:11 +0100 Received: from grens-macbook.local (i-195-137-42-164.freedom2surf.net [195.137.42.164]) by mail.uk.scalix.com (Scalix SMTP Relay 11.4.4.12886) via ESMTP; Tue, 09 Jun 2009 22:26:08 +0100 (BST) Date: Tue, 9 Jun 2009 22:26:06 +0100 From: Gren Elliot To: Bernard Desruisseaux Message-ID: <4A2ED36E.1010201@scalix.com> In-Reply-To: <4A2EB317.40403@oracle.com> References: <4A2E8278.90808@scalix.com> References: <4A2EB317.40403@oracle.com> x-scalix-Hops: 1 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 X-SMP-CT-RefID: str=0001.0A0B0203.4A2ED371.01DA,ss=1,fgs=0 MIME-Version: 1.0 Content-Disposition: inline Cc: ietf-calsify@osafoundation.org, calsify@ietf.org Subject: Re: [calsify] [ietf-calsify] DTSTART in VTIMEZONE STANDARD and DAYLIGHT sub-components - localtime, but which localtime? X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org Hi Bernard, Thanks for your response to my query - originally posted to ietf-calsify@osafoundation.org. I assume I was posting to the wrong place, as I received a couple of new invites to ietf.org mailing lists (Thank you to whoever initiated that). Ok, I think I understand that now. Wording of these things is really tricky! A possible re-phrasing might be : The mandatory "DTSTART" property gives the effective onset date and local time for the time zone sub-component definition. "DTSTART" in this usage MUST be specified as a date with local time value. The UTC offset associated with "DTSTART" is specified in the "TZOFFSETFROM" property. The mandatory "TZOFFSETFROM" property gives the UTC offset which is in use immediately before the onset of this time zone observance begins. For example, the following represents the time at which the observance of Standard Time took effect in Fall 1967 for New York City: ... Regards, Gren. On 9/6/09 20:08, Bernard Desruisseaux wrote: > Hi Gren, > > See Section 3.6.5. Time Zone Component: > > > The mandatory "DTSTART" property gives the effective onset date > > and local time for the time zone sub-component definition. > > "DTSTART" in this usage MUST be specified as a date with local > > time value. > > > > The mandatory "TZOFFSETFROM" property gives the UTC offset which > > is in use when the onset of this time zone observance begins. > > "TZOFFSETFROM" is combined with "DTSTART" to define the effective > > onset for the time zone sub-component definition. For example, > > the following represents the time at which the observance of > > Standard Time took effect in Fall 1967 for New York City: > > > > DTSTART:19671029T020000 > > > > TZOFFSETFROM:-0400 > > Cheers, > Bernard > > > Gren Elliot wrote: >> Hi, >> >> I'm looking for clarification as to what localtime means inside a >> STANDARD or DAYLIGHT component in the context of the value to assign >> to DTSTART, and also hoping that draft-ietf-calsify-rfc2445bis-10 >> will get updated to make it clearer in this area. Specifically, if >> the localtime is changing from 2am to 3am at the onset time for a >> VTIMEZONE sub-component, should DTSTART reflect the 2am time or the >> 3am time? >> >> I've ended up thinking about this because I'm in the process of >> testing out the latest libical code for our use >> (http://sourceforge.net/projects/freeassociation/) >> >> With our previous cut of the libical code, timezone information >> corresponding to, say, Europe/Zurich used to come from one of >> libical's own files : >> .../zoneinfo/Europe/Zurich.ics >> >> The new code appears to work from a combination of >> /usr/share/zoneinfo/zone.tab and /usr/share/zoneinfo/Europe/Zurich - >> which are part of the linux system "tzdata" package. Great, I >> thought. I can rely on the OS to keep the timezone info up to date. >> However, the timezone I'm getting from this differs from the timezone >> I used to get. >> >> This is the new version : >> >> BEGIN:VTIMEZONE >> TZID:/freeassociation.sourceforge.net/Tzfile/Europe/Zurich >> X-LIC-LOCATION:Europe/Zurich >> BEGIN:STANDARD >> TZNAME:CET >> DTSTART:19701025T020000 >> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 >> TZOFFSETFROM:+0200 >> TZOFFSETTO:+0100 >> END:STANDARD >> BEGIN:DAYLIGHT >> TZNAME:CEST >> DTSTART:19700328T030000 >> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 >> TZOFFSETFROM:+0100 >> TZOFFSETTO:+0200 >> END:DAYLIGHT >> END:VTIMEZONE >> >> The only difference (apart from component and property ordering) from >> the old version is that the DTSTART in the STANDARD component used to >> be : >> DTSTART:19701025T030000 >> and in the DAYLIGHT component it used to be : >> DTSTART:19700329T020000 >> i.e. The opposite way around to the above... >> >> Looking at >> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-10 Section >> 3.6.5, you get this description of what DTSTART should look like in a >> VTIMEZONE (section 3.8.2.4 on DTSTART in isolation is similar) : >> The mandatory "DTSTART" property gives the effective onset date >> and local time for the time zone sub-component definition. >> "DTSTART" in this usage MUST be specified as a date with local >> time value. >> >> The problem with this is that there are 2 fairly common sense ways of >> thinking about what the localtime is at this point. If I want to >> know when to change my clock from STANDARD to DAYLIGHT time, I wait >> until the time of the change in STANDARD time (say 2am) and spring my >> clock forward to 3am at that point. >> If, however, I'm looking at the DAYLIGHT component, I'm tempted to >> think that localtime for that instant is the localtime in the >> DAYLIGHT component - i.e. 3am. >> >> This difference in view seems consistent with the difference between >> the new and old VTIMEZONE definitions, however I haven't noticed >> anything yet which shouts out which is correct. >> >> Thoughts? >> >> Regards, >> Gren Elliot >> >> P.S. >> http://www.timeanddate.com/worldclock/city.html?n=268 >> says that >> DST started >> on >> Sunday, 29 March 2009, 02:00 local standard time >> DST ends >> on >> Sunday, 25 October 2009, 03:00 local daylight time >> which would imply that the time is the time just before the onset, >> which would imply a world view where the old code was correct. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> ietf-calsify mailing list >> ietf-calsify@osafoundation.org >> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From Steven.Lees@microsoft.com Fri Jun 12 16:36:56 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C853A6A1D for ; Fri, 12 Jun 2009 16:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCcFGzPOxq+B for ; Fri, 12 Jun 2009 16:36:49 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 4B9F43A63EC for ; Fri, 12 Jun 2009 16:36:49 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 12 Jun 2009 16:36:57 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.49]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Fri, 12 Jun 2009 16:36:57 -0700 From: Steven Lees To: "ietf-calsify@osafoundation.org" , "calsify@ietf.org" Thread-Topic: New iCalendar XML format draft Thread-Index: AcnrtqrOE6Qm9pe1RaKi6H58cn/4EA== Date: Fri, 12 Jun 2009 23:36:53 +0000 Message-ID: <854B3F17B7AF524E9E6CB4A9004F8C6C1197831C@tk5ex14mbxc105.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_" MIME-Version: 1.0 Subject: [calsify] New iCalendar XML format draft X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 23:36:56 -0000 --_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Last week Cyrus Daboo, Mike Douglas and I submitted an Internet Draft that = specifies an XML format for iCalendar. The draft was developed by the XML t= echnical committee in CalConnect (http://calconnect.org), with input from r= epresentatives from Sun, RPI, Apple, Microsoft, and others. (The draft is h= ere: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icalendar-in-xml= -00.txt.) As you probably know, there have been some prior attempts to create an XML = iCalendar specification, such as http://tools.ietf.org/html/draft-hare-xcal= endar-03 and http://tools.ietf.org/html/draft-royer-calsch-xcal-03. There w= as a consensus among CalConnect members that there is enough use of one-off= XML formatted calendar data to make it worth giving this another try. My question for you all is whether you're interested in working on an XML i= Calendar format specification at this time. There's a vCard XML format draf= t currently under discussion in the vcarddav group (http://tools.ietf.org/h= tml/draft-perreault-vcarddav-vcardxml-01) and it would be great to develop = an iCal XML format at the same time. I created a sample iCal to XML converter based on our spec on http://xcal.c= loudapp.net. When you have a chance, take a look at the draft and try out t= he converter, and let us know what you think. Thanks! Steven Lees --_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Last week Cyrus Daboo, Mike Douglas and I submitted an Internet Draft that specifies an XML format for iCalendar. The draft was developed by the XML technical committee in CalConnect (http://calconnect.o= rg), with input from representatives from Sun, RPI, Apple, Microsoft, and others= . (The draft is here: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icalendar= -in-xml-00.txt.)

 

As you probably know, there have been some prior attem= pts to create an XML iCalendar specification, such as http://tools.ie= tf.org/html/draft-hare-xcalendar-03 and http:= //tools.ietf.org/html/draft-royer-calsch-xcal-03. There was a consensus among CalConnect members that there is enough use of one-off XML formatted calendar data to make it worth giving this another tr= y.

 

My question for you all is whether you're interested i= n working on an XML iCalendar format specification at this time. There's a vCard XML format draft currently under discussion in the vcarddav group (ht= tp://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-01) and it would be great to develop an iCal XML format at the same time.<= /o:p>

 

I created a sample iCal to XML converter based on our = spec on http://xcal.cloudapp.net. When = you have a chance, take a look at the draft and try out the converter, and let = us know what you think.

 

Thanks!

Steven Lees

--_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_-- From calsify-bounces@ietf.org Fri Jun 12 16:36:57 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91A43A6A1D; Fri, 12 Jun 2009 16:36:57 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C853A6A1D for ; Fri, 12 Jun 2009 16:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCcFGzPOxq+B for ; Fri, 12 Jun 2009 16:36:49 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 4B9F43A63EC for ; Fri, 12 Jun 2009 16:36:49 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 12 Jun 2009 16:36:57 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.49]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Fri, 12 Jun 2009 16:36:57 -0700 From: Steven Lees To: "ietf-calsify@osafoundation.org" , "calsify@ietf.org" Thread-Topic: New iCalendar XML format draft Thread-Index: AcnrtqrOE6Qm9pe1RaKi6H58cn/4EA== Date: Fri, 12 Jun 2009 23:36:53 +0000 Message-ID: <854B3F17B7AF524E9E6CB4A9004F8C6C1197831C@tk5ex14mbxc105.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Subject: [calsify] New iCalendar XML format draft X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1072286059==" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org --===============1072286059== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_" --_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Last week Cyrus Daboo, Mike Douglas and I submitted an Internet Draft that = specifies an XML format for iCalendar. The draft was developed by the XML t= echnical committee in CalConnect (http://calconnect.org), with input from r= epresentatives from Sun, RPI, Apple, Microsoft, and others. (The draft is h= ere: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icalendar-in-xml= -00.txt.) As you probably know, there have been some prior attempts to create an XML = iCalendar specification, such as http://tools.ietf.org/html/draft-hare-xcal= endar-03 and http://tools.ietf.org/html/draft-royer-calsch-xcal-03. There w= as a consensus among CalConnect members that there is enough use of one-off= XML formatted calendar data to make it worth giving this another try. My question for you all is whether you're interested in working on an XML i= Calendar format specification at this time. There's a vCard XML format draf= t currently under discussion in the vcarddav group (http://tools.ietf.org/h= tml/draft-perreault-vcarddav-vcardxml-01) and it would be great to develop = an iCal XML format at the same time. I created a sample iCal to XML converter based on our spec on http://xcal.c= loudapp.net. When you have a chance, take a look at the draft and try out t= he converter, and let us know what you think. Thanks! Steven Lees --_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Last week Cyrus Daboo, Mike Douglas and I submitted an Internet Draft that specifies an XML format for iCalendar. The draft was developed by the XML technical committee in CalConnect (http://calconnect.o= rg), with input from representatives from Sun, RPI, Apple, Microsoft, and others= . (The draft is here: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icalendar= -in-xml-00.txt.)

 

As you probably know, there have been some prior attem= pts to create an XML iCalendar specification, such as http://tools.ie= tf.org/html/draft-hare-xcalendar-03 and http:= //tools.ietf.org/html/draft-royer-calsch-xcal-03. There was a consensus among CalConnect members that there is enough use of one-off XML formatted calendar data to make it worth giving this another tr= y.

 

My question for you all is whether you're interested i= n working on an XML iCalendar format specification at this time. There's a vCard XML format draft currently under discussion in the vcarddav group (ht= tp://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-01) and it would be great to develop an iCal XML format at the same time.<= /o:p>

 

I created a sample iCal to XML converter based on our = spec on http://xcal.cloudapp.net. When = you have a chance, take a look at the draft and try out the converter, and let = us know what you think.

 

Thanks!

Steven Lees

--_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_-- --===============1072286059== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --===============1072286059==-- From ietf-calsify-bounces@osafoundation.org Fri Jun 12 16:37:18 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93F9E3A6A85 for ; Fri, 12 Jun 2009 16:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiWk4P0mPXaz for ; Fri, 12 Jun 2009 16:37:12 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 5B1763A63EC for ; Fri, 12 Jun 2009 16:37:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 037E177D71C; Fri, 12 Jun 2009 16:37:21 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWM-VmeubEAz; Fri, 12 Jun 2009 16:37:15 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 9DFFA77D70F; Fri, 12 Jun 2009 16:37:10 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 7CC8477D70F for ; Fri, 12 Jun 2009 16:37:07 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAzvZu1Uh0lH for ; Fri, 12 Jun 2009 16:36:58 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 1E10577D704 for ; Fri, 12 Jun 2009 16:36:58 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Fri, 12 Jun 2009 16:36:57 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.49]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Fri, 12 Jun 2009 16:36:57 -0700 From: Steven Lees To: "ietf-calsify@osafoundation.org" , "calsify@ietf.org" Thread-Topic: New iCalendar XML format draft Thread-Index: AcnrtqrOE6Qm9pe1RaKi6H58cn/4EA== Date: Fri, 12 Jun 2009 23:36:53 +0000 Message-ID: <854B3F17B7AF524E9E6CB4A9004F8C6C1197831C@tk5ex14mbxc105.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 Subject: [ietf-calsify] New iCalendar XML format draft X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1415755352==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org --===============1415755352== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_" --_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Last week Cyrus Daboo, Mike Douglas and I submitted an Internet Draft that = specifies an XML format for iCalendar. The draft was developed by the XML t= echnical committee in CalConnect (http://calconnect.org), with input from r= epresentatives from Sun, RPI, Apple, Microsoft, and others. (The draft is h= ere: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icalendar-in-xml= -00.txt.) As you probably know, there have been some prior attempts to create an XML = iCalendar specification, such as http://tools.ietf.org/html/draft-hare-xcal= endar-03 and http://tools.ietf.org/html/draft-royer-calsch-xcal-03. There w= as a consensus among CalConnect members that there is enough use of one-off= XML formatted calendar data to make it worth giving this another try. My question for you all is whether you're interested in working on an XML i= Calendar format specification at this time. There's a vCard XML format draf= t currently under discussion in the vcarddav group (http://tools.ietf.org/h= tml/draft-perreault-vcarddav-vcardxml-01) and it would be great to develop = an iCal XML format at the same time. I created a sample iCal to XML converter based on our spec on http://xcal.c= loudapp.net. When you have a chance, take a look at the draft and try out t= he converter, and let us know what you think. Thanks! Steven Lees --_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Last week Cyrus Daboo, Mike Douglas and I submitted an Internet Draft that specifies an XML format for iCalendar. The draft was developed by the XML technical committee in CalConnect (http://calconnect.o= rg), with input from representatives from Sun, RPI, Apple, Microsoft, and others= . (The draft is here: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icalendar= -in-xml-00.txt.)

 

As you probably know, there have been some prior attem= pts to create an XML iCalendar specification, such as http://tools.ie= tf.org/html/draft-hare-xcalendar-03 and http:= //tools.ietf.org/html/draft-royer-calsch-xcal-03. There was a consensus among CalConnect members that there is enough use of one-off XML formatted calendar data to make it worth giving this another tr= y.

 

My question for you all is whether you're interested i= n working on an XML iCalendar format specification at this time. There's a vCard XML format draft currently under discussion in the vcarddav group (ht= tp://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-01) and it would be great to develop an iCal XML format at the same time.<= /o:p>

 

I created a sample iCal to XML converter based on our = spec on http://xcal.cloudapp.net. When = you have a chance, take a look at the draft and try out the converter, and let = us know what you think.

 

Thanks!

Steven Lees

--_000_854B3F17B7AF524E9E6CB4A9004F8C6C1197831Ctk5ex14mbxc105r_-- --===============1415755352== 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 --===============1415755352==-- From timhare@comcast.net Sat Jun 13 08:42:01 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313D428B23E for ; Sat, 13 Jun 2009 08:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQWusvO3umli for ; Sat, 13 Jun 2009 08:41:55 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 9599B3A6BF8 for ; Sat, 13 Jun 2009 08:41:55 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 3Nxj1c0041HzFnQ54Ti4pC; Sat, 13 Jun 2009 15:42:04 +0000 Received: from THare ([71.203.105.66]) by OMTA14.westchester.pa.mail.comcast.net with comcast id 3Ti31c00B1RyUCv3aTi4sL; Sat, 13 Jun 2009 15:42:04 +0000 From: "Tim Hare" To: "'Steven Lees'" , , Date: Sat, 13 Jun 2009 11:42:05 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C9EC1B.FAC8B720" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcnrtqrOE6Qm9pe1RaKi6H58cn/4EAAhKQ+Q In-Reply-To: <854B3F17B7AF524E9E6CB4A9004F8C6C1197831C@tk5ex14mbxc105.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Message-Id: <20090613154155.9599B3A6BF8@core3.amsl.com> Subject: Re: [calsify] New iCalendar XML format draft X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 15:42:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C9EC1B.FAC8B720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit One of the best use cases for iCalendar-as-XML is for providing calendar "feeds", I think, and as the draft says leveraging the available XML tools. At a minimum it would shorten development time for handling calendar data. Jon Udell (also of Microsoft) has been writing a lot recently about gathering calendar information from many different sources (for example: http://blog.jonudell.net/2009/06/08/scribbling-in-the-margins-of-icalendar/ ) - I believe one of the goals of an XML form should be to provide an Atom/RSS-compatible set of XML to further that type of thing. While not as critical to organizations internally, as say, meeting scheduling, publishing of calendar information can be critical. My current employer, a US state transportation department, is required to hold many public hearings and public bid-openings in regard to large construction projects. Providing that calendar information in a format useful to the citizenry would be a major plus (I suppose I should post a disclaimer here that I'm speaking my own opinions, not those of my employer). I think it would also be useful to discuss the opposite (but simpler?) transform: from XML-based calendar info to iCalendar. It seems to me that once something is available in XML, much development work centers around that because of smaller development cost. That means that more established tools built around the iCalendar format will need a method of creating an iCalendar input from an XML document, to allow for interoperability. Tim Hare Interested Bystander, Non-Inc. _____ From: calsify-bounces@ietf.org [mailto:calsify-bounces@ietf.org] On Behalf Of Steven Lees Sent: Friday, June 12, 2009 7:37 PM To: ietf-calsify@osafoundation.org; calsify@ietf.org Subject: [calsify] New iCalendar XML format draft Hello, Last week Cyrus Daboo, Mike Douglas and I submitted an Internet Draft that specifies an XML format for iCalendar. The draft was developed by the XML technical committee in CalConnect (http://calconnect.org), with input from representatives from Sun, RPI, Apple, Microsoft, and others. (The draft is here: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icalendar-in-xml-00.tx t.) As you probably know, there have been some prior attempts to create an XML iCalendar specification, such as http://tools.ietf.org/html/draft-hare-xcalendar-03 and http://tools.ietf.org/html/draft-royer-calsch-xcal-03. There was a consensus among CalConnect members that there is enough use of one-off XML formatted calendar data to make it worth giving this another try. My question for you all is whether you're interested in working on an XML iCalendar format specification at this time. There's a vCard XML format draft currently under discussion in the vcarddav group (http://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-01) and it would be great to develop an iCal XML format at the same time. I created a sample iCal to XML converter based on our spec on http://xcal.cloudapp.net. When you have a chance, take a look at the draft and try out the converter, and let us know what you think. Thanks! Steven Lees ------=_NextPart_000_004C_01C9EC1B.FAC8B720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
One of the best use cases for iCalendar-as-XML = is for=20 providing calendar "feeds", I think, and as the draft says leveraging = the=20 available XML tools. At a minimum it would shorten development time = for=20 handling calendar data. 
 
Jon Udell (also of Microsoft) has been writing = a lot=20 recently about gathering calendar information from many different = sources (for=20 example: http://blog.jonudell.net/2009/06/08/scribbling-in-the-margins= -of-icalendar/ ) =20 - I believe one of the goals of an XML form should be to provide an = Atom/RSS-compatible set of XML to further that type of = thing. While=20 not as critical to organizations internally, as say, meeting=20 scheduling, publishing of calendar information can be = critical.  My=20 current employer, a US state transportation department, = is required to=20 hold many public hearings and public bid-openings in regard = to  large=20 construction projects.  Providing that calendar information in a = format=20 useful to the citizenry would be a major plus (I suppose I should post a = disclaimer here that I'm speaking my own opinions, not those of my=20 employer).
 
I think it would also be useful to discuss the = opposite=20 (but simpler?) transform: from XML-based calendar info to = iCalendar.  It=20 seems to me that once something is available in XML, much development = work=20 centers around that because of smaller development cost.   = That means=20 that more established tools built around the iCalendar format will need = a method=20 of creating an iCalendar input from an XML document, to allow for=20 interoperability.
 
Tim Hare
Interested Bystander,=20 Non-Inc.
 

From: calsify-bounces@ietf.org=20 [mailto:calsify-bounces@ietf.org] On Behalf Of Steven=20 Lees
Sent: Friday, June 12, 2009 7:37 PM
To:=20 ietf-calsify@osafoundation.org; calsify@ietf.org
Subject: = [calsify]=20 New iCalendar XML format draft

Hello,

 

Last week Cyrus Daboo, Mike Douglas and I submitted = an=20 Internet Draft that specifies an XML format for iCalendar. The draft was = developed by the XML technical committee in CalConnect = (http://calconnect.org),=20 with input from representatives from Sun, RPI, Apple, Microsoft, and = others.=20 (The draft is here: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icale= ndar-in-xml-00.txt.)=20

 

As you probably know, there have been some prior = attempts to=20 create an XML iCalendar specification, such as http://tools.= ietf.org/html/draft-hare-xcalendar-03=20 and http://too= ls.ietf.org/html/draft-royer-calsch-xcal-03.=20 There was a consensus among CalConnect members that there is enough use = of=20 one-off XML formatted calendar data to make it worth giving this another = try.

 

My question for you all is whether you're = interested in=20 working on an XML iCalendar format specification at this time. There's a = vCard=20 XML format draft currently under discussion in the vcarddav group (= http://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-01)=20 and it would be great to develop an iCal XML format at the same=20 time.

 

I created a sample iCal to XML converter based on = our spec on=20 http://xcal.cloudapp.net. When = you have a=20 chance, take a look at the draft and try out the converter, and let us = know what=20 you think.

 

Thanks!

Steven Lees

------=_NextPart_000_004C_01C9EC1B.FAC8B720-- From calsify-bounces@ietf.org Sat Jun 13 08:42:02 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D92343A6BFB; Sat, 13 Jun 2009 08:42:02 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313D428B23E for ; Sat, 13 Jun 2009 08:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQWusvO3umli for ; Sat, 13 Jun 2009 08:41:55 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 9599B3A6BF8 for ; Sat, 13 Jun 2009 08:41:55 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 3Nxj1c0041HzFnQ54Ti4pC; Sat, 13 Jun 2009 15:42:04 +0000 Received: from THare ([71.203.105.66]) by OMTA14.westchester.pa.mail.comcast.net with comcast id 3Ti31c00B1RyUCv3aTi4sL; Sat, 13 Jun 2009 15:42:04 +0000 From: "Tim Hare" To: "'Steven Lees'" , , Date: Sat, 13 Jun 2009 11:42:05 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcnrtqrOE6Qm9pe1RaKi6H58cn/4EAAhKQ+Q In-Reply-To: <854B3F17B7AF524E9E6CB4A9004F8C6C1197831C@tk5ex14mbxc105.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Message-Id: <20090613154155.9599B3A6BF8@core3.amsl.com> Subject: Re: [calsify] New iCalendar XML format draft X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0515063417==" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org This is a multi-part message in MIME format. --===============0515063417== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C9EC1B.FAC8B720" This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C9EC1B.FAC8B720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit One of the best use cases for iCalendar-as-XML is for providing calendar "feeds", I think, and as the draft says leveraging the available XML tools. At a minimum it would shorten development time for handling calendar data. Jon Udell (also of Microsoft) has been writing a lot recently about gathering calendar information from many different sources (for example: http://blog.jonudell.net/2009/06/08/scribbling-in-the-margins-of-icalendar/ ) - I believe one of the goals of an XML form should be to provide an Atom/RSS-compatible set of XML to further that type of thing. While not as critical to organizations internally, as say, meeting scheduling, publishing of calendar information can be critical. My current employer, a US state transportation department, is required to hold many public hearings and public bid-openings in regard to large construction projects. Providing that calendar information in a format useful to the citizenry would be a major plus (I suppose I should post a disclaimer here that I'm speaking my own opinions, not those of my employer). I think it would also be useful to discuss the opposite (but simpler?) transform: from XML-based calendar info to iCalendar. It seems to me that once something is available in XML, much development work centers around that because of smaller development cost. That means that more established tools built around the iCalendar format will need a method of creating an iCalendar input from an XML document, to allow for interoperability. Tim Hare Interested Bystander, Non-Inc. _____ From: calsify-bounces@ietf.org [mailto:calsify-bounces@ietf.org] On Behalf Of Steven Lees Sent: Friday, June 12, 2009 7:37 PM To: ietf-calsify@osafoundation.org; calsify@ietf.org Subject: [calsify] New iCalendar XML format draft Hello, Last week Cyrus Daboo, Mike Douglas and I submitted an Internet Draft that specifies an XML format for iCalendar. The draft was developed by the XML technical committee in CalConnect (http://calconnect.org), with input from representatives from Sun, RPI, Apple, Microsoft, and others. (The draft is here: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icalendar-in-xml-00.tx t.) As you probably know, there have been some prior attempts to create an XML iCalendar specification, such as http://tools.ietf.org/html/draft-hare-xcalendar-03 and http://tools.ietf.org/html/draft-royer-calsch-xcal-03. There was a consensus among CalConnect members that there is enough use of one-off XML formatted calendar data to make it worth giving this another try. My question for you all is whether you're interested in working on an XML iCalendar format specification at this time. There's a vCard XML format draft currently under discussion in the vcarddav group (http://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-01) and it would be great to develop an iCal XML format at the same time. I created a sample iCal to XML converter based on our spec on http://xcal.cloudapp.net. When you have a chance, take a look at the draft and try out the converter, and let us know what you think. Thanks! Steven Lees ------=_NextPart_000_004C_01C9EC1B.FAC8B720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
One of the best use cases for iCalendar-as-XML = is for=20 providing calendar "feeds", I think, and as the draft says leveraging = the=20 available XML tools. At a minimum it would shorten development time = for=20 handling calendar data. 
 
Jon Udell (also of Microsoft) has been writing = a lot=20 recently about gathering calendar information from many different = sources (for=20 example: http://blog.jonudell.net/2009/06/08/scribbling-in-the-margins= -of-icalendar/ ) =20 - I believe one of the goals of an XML form should be to provide an = Atom/RSS-compatible set of XML to further that type of = thing. While=20 not as critical to organizations internally, as say, meeting=20 scheduling, publishing of calendar information can be = critical.  My=20 current employer, a US state transportation department, = is required to=20 hold many public hearings and public bid-openings in regard = to  large=20 construction projects.  Providing that calendar information in a = format=20 useful to the citizenry would be a major plus (I suppose I should post a = disclaimer here that I'm speaking my own opinions, not those of my=20 employer).
 
I think it would also be useful to discuss the = opposite=20 (but simpler?) transform: from XML-based calendar info to = iCalendar.  It=20 seems to me that once something is available in XML, much development = work=20 centers around that because of smaller development cost.   = That means=20 that more established tools built around the iCalendar format will need = a method=20 of creating an iCalendar input from an XML document, to allow for=20 interoperability.
 
Tim Hare
Interested Bystander,=20 Non-Inc.
 

From: calsify-bounces@ietf.org=20 [mailto:calsify-bounces@ietf.org] On Behalf Of Steven=20 Lees
Sent: Friday, June 12, 2009 7:37 PM
To:=20 ietf-calsify@osafoundation.org; calsify@ietf.org
Subject: = [calsify]=20 New iCalendar XML format draft

Hello,

 

Last week Cyrus Daboo, Mike Douglas and I submitted = an=20 Internet Draft that specifies an XML format for iCalendar. The draft was = developed by the XML technical committee in CalConnect = (http://calconnect.org),=20 with input from representatives from Sun, RPI, Apple, Microsoft, and = others.=20 (The draft is here: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icale= ndar-in-xml-00.txt.)=20

 

As you probably know, there have been some prior = attempts to=20 create an XML iCalendar specification, such as http://tools.= ietf.org/html/draft-hare-xcalendar-03=20 and http://too= ls.ietf.org/html/draft-royer-calsch-xcal-03.=20 There was a consensus among CalConnect members that there is enough use = of=20 one-off XML formatted calendar data to make it worth giving this another = try.

 

My question for you all is whether you're = interested in=20 working on an XML iCalendar format specification at this time. There's a = vCard=20 XML format draft currently under discussion in the vcarddav group (= http://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-01)=20 and it would be great to develop an iCal XML format at the same=20 time.

 

I created a sample iCal to XML converter based on = our spec on=20 http://xcal.cloudapp.net. When = you have a=20 chance, take a look at the draft and try out the converter, and let us = know what=20 you think.

 

Thanks!

Steven Lees

------=_NextPart_000_004C_01C9EC1B.FAC8B720-- --===============0515063417== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --===============0515063417==-- From ietf-calsify-bounces@osafoundation.org Sat Jun 13 08:42:26 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307C93A67E4 for ; Sat, 13 Jun 2009 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71IwD0IQDqRx for ; Sat, 13 Jun 2009 08:42:23 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 586C728C0EE for ; Sat, 13 Jun 2009 08:42:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 55BD777D704; Sat, 13 Jun 2009 08:42:32 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRxuU0PMkQZo; Sat, 13 Jun 2009 08:42:20 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id B60B177D71C; Sat, 13 Jun 2009 08:42:17 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 9C6A577D71C for ; Sat, 13 Jun 2009 08:42:14 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1Ml3XSHVhxK for ; Sat, 13 Jun 2009 08:42:05 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by leka.osafoundation.org (Postfix) with ESMTP id C459477D704 for ; Sat, 13 Jun 2009 08:42:04 -0700 (PDT) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA05.westchester.pa.mail.comcast.net with comcast id 3RLV1c00B1HzFnQ55Ti4JS; Sat, 13 Jun 2009 15:42:04 +0000 Received: from THare ([71.203.105.66]) by OMTA14.westchester.pa.mail.comcast.net with comcast id 3Ti31c00B1RyUCv3aTi4sL; Sat, 13 Jun 2009 15:42:04 +0000 From: "Tim Hare" To: "'Steven Lees'" , , Date: Sat, 13 Jun 2009 11:42:05 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcnrtqrOE6Qm9pe1RaKi6H58cn/4EAAhKQ+Q In-Reply-To: <854B3F17B7AF524E9E6CB4A9004F8C6C1197831C@tk5ex14mbxc105.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Message-Id: <20090613154204.C459477D704@leka.osafoundation.org> Subject: Re: [ietf-calsify] [calsify] New iCalendar XML format draft X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0173547212==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --===============0173547212== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C9EC1B.FAC8B720" This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C9EC1B.FAC8B720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit One of the best use cases for iCalendar-as-XML is for providing calendar "feeds", I think, and as the draft says leveraging the available XML tools. At a minimum it would shorten development time for handling calendar data. Jon Udell (also of Microsoft) has been writing a lot recently about gathering calendar information from many different sources (for example: http://blog.jonudell.net/2009/06/08/scribbling-in-the-margins-of-icalendar/ ) - I believe one of the goals of an XML form should be to provide an Atom/RSS-compatible set of XML to further that type of thing. While not as critical to organizations internally, as say, meeting scheduling, publishing of calendar information can be critical. My current employer, a US state transportation department, is required to hold many public hearings and public bid-openings in regard to large construction projects. Providing that calendar information in a format useful to the citizenry would be a major plus (I suppose I should post a disclaimer here that I'm speaking my own opinions, not those of my employer). I think it would also be useful to discuss the opposite (but simpler?) transform: from XML-based calendar info to iCalendar. It seems to me that once something is available in XML, much development work centers around that because of smaller development cost. That means that more established tools built around the iCalendar format will need a method of creating an iCalendar input from an XML document, to allow for interoperability. Tim Hare Interested Bystander, Non-Inc. _____ From: calsify-bounces@ietf.org [mailto:calsify-bounces@ietf.org] On Behalf Of Steven Lees Sent: Friday, June 12, 2009 7:37 PM To: ietf-calsify@osafoundation.org; calsify@ietf.org Subject: [calsify] New iCalendar XML format draft Hello, Last week Cyrus Daboo, Mike Douglas and I submitted an Internet Draft that specifies an XML format for iCalendar. The draft was developed by the XML technical committee in CalConnect (http://calconnect.org), with input from representatives from Sun, RPI, Apple, Microsoft, and others. (The draft is here: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icalendar-in-xml-00.tx t.) As you probably know, there have been some prior attempts to create an XML iCalendar specification, such as http://tools.ietf.org/html/draft-hare-xcalendar-03 and http://tools.ietf.org/html/draft-royer-calsch-xcal-03. There was a consensus among CalConnect members that there is enough use of one-off XML formatted calendar data to make it worth giving this another try. My question for you all is whether you're interested in working on an XML iCalendar format specification at this time. There's a vCard XML format draft currently under discussion in the vcarddav group (http://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-01) and it would be great to develop an iCal XML format at the same time. I created a sample iCal to XML converter based on our spec on http://xcal.cloudapp.net. When you have a chance, take a look at the draft and try out the converter, and let us know what you think. Thanks! Steven Lees ------=_NextPart_000_004C_01C9EC1B.FAC8B720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
One of the best use cases for iCalendar-as-XML = is for=20 providing calendar "feeds", I think, and as the draft says leveraging = the=20 available XML tools. At a minimum it would shorten development time = for=20 handling calendar data. 
 
Jon Udell (also of Microsoft) has been writing = a lot=20 recently about gathering calendar information from many different = sources (for=20 example: http://blog.jonudell.net/2009/06/08/scribbling-in-the-margins= -of-icalendar/ ) =20 - I believe one of the goals of an XML form should be to provide an = Atom/RSS-compatible set of XML to further that type of = thing. While=20 not as critical to organizations internally, as say, meeting=20 scheduling, publishing of calendar information can be = critical.  My=20 current employer, a US state transportation department, = is required to=20 hold many public hearings and public bid-openings in regard = to  large=20 construction projects.  Providing that calendar information in a = format=20 useful to the citizenry would be a major plus (I suppose I should post a = disclaimer here that I'm speaking my own opinions, not those of my=20 employer).
 
I think it would also be useful to discuss the = opposite=20 (but simpler?) transform: from XML-based calendar info to = iCalendar.  It=20 seems to me that once something is available in XML, much development = work=20 centers around that because of smaller development cost.   = That means=20 that more established tools built around the iCalendar format will need = a method=20 of creating an iCalendar input from an XML document, to allow for=20 interoperability.
 
Tim Hare
Interested Bystander,=20 Non-Inc.
 

From: calsify-bounces@ietf.org=20 [mailto:calsify-bounces@ietf.org] On Behalf Of Steven=20 Lees
Sent: Friday, June 12, 2009 7:37 PM
To:=20 ietf-calsify@osafoundation.org; calsify@ietf.org
Subject: = [calsify]=20 New iCalendar XML format draft

Hello,

 

Last week Cyrus Daboo, Mike Douglas and I submitted = an=20 Internet Draft that specifies an XML format for iCalendar. The draft was = developed by the XML technical committee in CalConnect = (http://calconnect.org),=20 with input from representatives from Sun, RPI, Apple, Microsoft, and = others.=20 (The draft is here: http://www.ietf.org/internet-drafts/draft-daboo-et-al-icale= ndar-in-xml-00.txt.)=20

 

As you probably know, there have been some prior = attempts to=20 create an XML iCalendar specification, such as http://tools.= ietf.org/html/draft-hare-xcalendar-03=20 and http://too= ls.ietf.org/html/draft-royer-calsch-xcal-03.=20 There was a consensus among CalConnect members that there is enough use = of=20 one-off XML formatted calendar data to make it worth giving this another = try.

 

My question for you all is whether you're = interested in=20 working on an XML iCalendar format specification at this time. There's a = vCard=20 XML format draft currently under discussion in the vcarddav group (= http://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-01)=20 and it would be great to develop an iCal XML format at the same=20 time.

 

I created a sample iCal to XML converter based on = our spec on=20 http://xcal.cloudapp.net. When = you have a=20 chance, take a look at the draft and try out the converter, and let us = know what=20 you think.

 

Thanks!

Steven Lees

------=_NextPart_000_004C_01C9EC1B.FAC8B720-- --===============0173547212== 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 --===============0173547212==-- From bernard.desruisseaux@oracle.com Tue Jun 23 08:30:35 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025AE28C370; Tue, 23 Jun 2009 08:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=2.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omceK+3eDu9M; Tue, 23 Jun 2009 08:30:33 -0700 (PDT) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by core3.amsl.com (Postfix) with ESMTP id 9CA1628C374; Tue, 23 Jun 2009 08:30:30 -0700 (PDT) Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5NFVa7I000995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jun 2009 15:31:38 GMT Received: from hqdfmt02.oracle.com (hqdfmt02.oracle.com [148.87.35.12]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5NFUomK022561; Tue, 23 Jun 2009 15:30:52 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jun 2009 08:30:27 -0700 Message-ID: <4A40F50F.3030002@oracle.com> Date: Tue, 23 Jun 2009 11:30:23 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: caldav@ietf.org, calsify@ietf.org, w3c-dist-auth@w3.org Content-Type: multipart/mixed; boundary="------------000700060904030503070805" X-Source-IP: hqdfmt02.oracle.com [148.87.35.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4A40F516.00B8:SCFSTAT3499757,ss=1,fgs=0 Cc: Lisa Dusseault Subject: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 15:30:35 -0000 This is a multi-part message in MIME format. --------------000700060904030503070805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF last week. See Internet-Draft announcement below. Before requesting the IESG to consider this Internet-Draft as a Proposed Standard, we would like to get as much feedback as possible from the participants of the "caldav" mailing list as well as from the members of the WebDAV and Calsify Working Groups. Please review the document and send your comments to the caldav@ietf.org mailing list by July 7th, 2009. We would like to submit draft -08 before July 13, 2009, i.e., the final submission cut-off for the 75th IETF in Stockholm, Sweden. Thanks, Bernard P.S. Draft -07 is available in .xml, .txt., .html, and .pdf format: http://tools.ietf.org/id/draft-desruisseaux-caldav-sched-07.xml http://tools.ietf.org/id/draft-desruisseaux-caldav-sched-07.txt http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-07 http://tools.ietf.org/pdf/draft-desruisseaux-caldav-sched-07.pdf -------- Original Message -------- Subject: I-D Action:draft-desruisseaux-caldav-sched-07.txt Date: Fri, 19 Jun 2009 19:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CalDAV Scheduling Extensions to WebDAV Author(s) : C. Daboo, B. Desruisseaux Filename : draft-desruisseaux-caldav-sched-07.txt Pages : 94 Date : 2009-06-19 This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------000700060904030503070805 Content-Type: Message/External-body; name="draft-desruisseaux-caldav-sched-07.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-desruisseaux-caldav-sched-07.txt" Content-Type: text/plain Content-ID: <2009-06-19190523.I-D@ietf.org> --------------000700060904030503070805 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------000700060904030503070805-- From calsify-bounces@ietf.org Tue Jun 23 08:30:38 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FF828C370; Tue, 23 Jun 2009 08:30:38 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025AE28C370; Tue, 23 Jun 2009 08:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=2.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omceK+3eDu9M; Tue, 23 Jun 2009 08:30:33 -0700 (PDT) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by core3.amsl.com (Postfix) with ESMTP id 9CA1628C374; Tue, 23 Jun 2009 08:30:30 -0700 (PDT) Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5NFVa7I000995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jun 2009 15:31:38 GMT Received: from hqdfmt02.oracle.com (hqdfmt02.oracle.com [148.87.35.12]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5NFUomK022561; Tue, 23 Jun 2009 15:30:52 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jun 2009 08:30:27 -0700 Message-ID: <4A40F50F.3030002@oracle.com> Date: Tue, 23 Jun 2009 11:30:23 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: caldav@ietf.org, calsify@ietf.org, w3c-dist-auth@w3.org Content-Type: multipart/mixed; boundary="------------000700060904030503070805" X-Source-IP: hqdfmt02.oracle.com [148.87.35.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4A40F516.00B8:SCFSTAT3499757,ss=1,fgs=0 Cc: Lisa Dusseault Subject: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org This is a multi-part message in MIME format. --------------000700060904030503070805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF last week. See Internet-Draft announcement below. Before requesting the IESG to consider this Internet-Draft as a Proposed Standard, we would like to get as much feedback as possible from the participants of the "caldav" mailing list as well as from the members of the WebDAV and Calsify Working Groups. Please review the document and send your comments to the caldav@ietf.org mailing list by July 7th, 2009. We would like to submit draft -08 before July 13, 2009, i.e., the final submission cut-off for the 75th IETF in Stockholm, Sweden. Thanks, Bernard P.S. Draft -07 is available in .xml, .txt., .html, and .pdf format: http://tools.ietf.org/id/draft-desruisseaux-caldav-sched-07.xml http://tools.ietf.org/id/draft-desruisseaux-caldav-sched-07.txt http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-07 http://tools.ietf.org/pdf/draft-desruisseaux-caldav-sched-07.pdf -------- Original Message -------- Subject: I-D Action:draft-desruisseaux-caldav-sched-07.txt Date: Fri, 19 Jun 2009 19:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CalDAV Scheduling Extensions to WebDAV Author(s) : C. Daboo, B. Desruisseaux Filename : draft-desruisseaux-caldav-sched-07.txt Pages : 94 Date : 2009-06-19 This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------000700060904030503070805 Content-Type: Message/External-body; name="draft-desruisseaux-caldav-sched-07.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-desruisseaux-caldav-sched-07.txt" Content-Type: text/plain Content-ID: <2009-06-19190523.I-D@ietf.org> --------------000700060904030503070805 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------000700060904030503070805 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --------------000700060904030503070805-- From bernard.desruisseaux@oracle.com Tue Jun 23 08:46:29 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63ED028C34B; Tue, 23 Jun 2009 08:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2ju95kPjhLr; Tue, 23 Jun 2009 08:46:28 -0700 (PDT) Received: from mail384c25.carrierzone.com (mail384c25.carrierzone.com [209.235.146.154]) by core3.amsl.com (Postfix) with ESMTP id 547713A6CFC; Tue, 23 Jun 2009 08:46:28 -0700 (PDT) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail384c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n5NFkYm9021428; Tue, 23 Jun 2009 15:46:36 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Jun 2009 11:46:33 -0400 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG06232009-114552-8917.MMD@TencoAssembliesInc.local; Tue, 23 Jun 2009 11:45:52 -0400 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail362c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n5NFXKtC011848 for ; Tue, 23 Jun 2009 11:33:22 -0400 Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1MJ7yF-0003zL-CF for w3c-dist-auth-dist@listhub.w3.org; Tue, 23 Jun 2009 15:31:39 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MJ7yE-0003y1-FR for w3c-dist-auth@listhub.w3.org; Tue, 23 Jun 2009 15:31:38 +0000 Received: from acsinet11.oracle.com ([141.146.126.233]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MJ7xz-0005s8-J4 for w3c-dist-auth@w3.org; Tue, 23 Jun 2009 15:31:38 +0000 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5NFVa7I000995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jun 2009 15:31:38 GMT Received: from hqdfmt02.oracle.com (hqdfmt02.oracle.com [148.87.35.12]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5NFUomK022561; Tue, 23 Jun 2009 15:30:52 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jun 2009 08:30:27 -0700 Message-ID: <4A40F50F.3030002@oracle.com> Date: Tue, 23 Jun 2009 11:30:23 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: caldav@ietf.org, calsify@ietf.org, w3c-dist-auth@w3.org Content-Type: multipart/mixed; boundary="------------000700060904030503070805" X-Source-IP: hqdfmt02.oracle.com [148.87.35.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4A40F516.00B8:SCFSTAT3499757,ss=1,fgs=0 Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: bart.w3.org 1MJ7xz-0005s8-J4 97e8fd22a93f7aee8fee365d90d3c01b X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13132 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Tue, 23 Jun 2009 15:31:39 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 23 Jun 2009 15:46:33.0593 (UTC) FILETIME=[C8BC8E90:01C9F419] Cc: Lisa Dusseault Subject: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 15:46:29 -0000 This is a multi-part message in MIME format. --------------000700060904030503070805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF last week. See Internet-Draft announcement below. Before requesting the IESG to consider this Internet-Draft as a Proposed Standard, we would like to get as much feedback as possible from the participants of the "caldav" mailing list as well as from the members of the WebDAV and Calsify Working Groups. Please review the document and send your comments to the caldav@ietf.org mailing list by July 7th, 2009. We would like to submit draft -08 before July 13, 2009, i.e., the final submission cut-off for the 75th IETF in Stockholm, Sweden. Thanks, Bernard P.S. Draft -07 is available in .xml, .txt., .html, and .pdf format: http://tools.ietf.org/id/draft-desruisseaux-caldav-sched-07.xml http://tools.ietf.org/id/draft-desruisseaux-caldav-sched-07.txt http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-07 http://tools.ietf.org/pdf/draft-desruisseaux-caldav-sched-07.pdf -------- Original Message -------- Subject: I-D Action:draft-desruisseaux-caldav-sched-07.txt Date: Fri, 19 Jun 2009 19:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CalDAV Scheduling Extensions to WebDAV Author(s) : C. Daboo, B. Desruisseaux Filename : draft-desruisseaux-caldav-sched-07.txt Pages : 94 Date : 2009-06-19 This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------000700060904030503070805 Content-Type: Message/External-body; name="draft-desruisseaux-caldav-sched-07.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-desruisseaux-caldav-sched-07.txt" Content-Type: text/plain Content-ID: <2009-06-19190523.I-D@ietf.org> --------------000700060904030503070805 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------000700060904030503070805-- From calsify-bounces@ietf.org Tue Jun 23 08:46:30 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E3228C37A; Tue, 23 Jun 2009 08:46:30 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63ED028C34B; Tue, 23 Jun 2009 08:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2ju95kPjhLr; Tue, 23 Jun 2009 08:46:28 -0700 (PDT) Received: from mail384c25.carrierzone.com (mail384c25.carrierzone.com [209.235.146.154]) by core3.amsl.com (Postfix) with ESMTP id 547713A6CFC; Tue, 23 Jun 2009 08:46:28 -0700 (PDT) X-Authenticated-User: master.tencoassemblies.com Received: from TENCOSERVER.TencoAssembliesInc.local (static-68-162-87-75.phil.east.verizon.net [68.162.87.75]) (authenticated bits=0) by mail384c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n5NFkYm9021428; Tue, 23 Jun 2009 15:46:36 GMT Received: from TENCOSERVER.TencoAssembliesInc.local ([10.0.0.2]) by TENCOSERVER.TencoAssembliesInc.local with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Jun 2009 11:46:33 -0400 Received: by TENCOSERVER.TencoAssembliesInc.local (Microsoft Connector for POP3 Mailboxes 5.00.2195) with SMTP (Global POP3 Download) id MSG06232009-114552-8917.MMD@TencoAssembliesInc.local; Tue, 23 Jun 2009 11:45:52 -0400 X-Envelope-From: w3c-dist-auth-request@frink.w3.org Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by mail362c25.carrierzone.com (8.13.6/8.13.1) with ESMTP id n5NFXKtC011848 for ; Tue, 23 Jun 2009 11:33:22 -0400 Received: from lists by frink.w3.org with local (Exim 4.63) (envelope-from ) id 1MJ7yF-0003zL-CF for w3c-dist-auth-dist@listhub.w3.org; Tue, 23 Jun 2009 15:31:39 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MJ7yE-0003y1-FR for w3c-dist-auth@listhub.w3.org; Tue, 23 Jun 2009 15:31:38 +0000 Received: from acsinet11.oracle.com ([141.146.126.233]) by bart.w3.org with esmtp (Exim 4.63) (envelope-from ) id 1MJ7xz-0005s8-J4 for w3c-dist-auth@w3.org; Tue, 23 Jun 2009 15:31:38 +0000 Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5NFVa7I000995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Jun 2009 15:31:38 GMT Received: from hqdfmt02.oracle.com (hqdfmt02.oracle.com [148.87.35.12]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5NFUomK022561; Tue, 23 Jun 2009 15:30:52 GMT Received: from [10.156.43.80] (/10.156.43.80) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jun 2009 08:30:27 -0700 Message-ID: <4A40F50F.3030002@oracle.com> Date: Tue, 23 Jun 2009 11:30:23 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: caldav@ietf.org, calsify@ietf.org, w3c-dist-auth@w3.org Content-Type: multipart/mixed; boundary="------------000700060904030503070805" X-Source-IP: hqdfmt02.oracle.com [148.87.35.12] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4A40F516.00B8:SCFSTAT3499757,ss=1,fgs=0 Received-SPF: none X-SPF-Guess: pass X-W3C-Hub-Spam-Status: No, score=-6.6 X-W3C-Hub-Spam-Report: BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 X-W3C-Scan-Sig: bart.w3.org 1MJ7xz-0005s8-J4 97e8fd22a93f7aee8fee365d90d3c01b X-Original-To: w3c-dist-auth@w3.org Archived-At: Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/13132 X-Loop: w3c-dist-auth@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Tue, 23 Jun 2009 15:31:39 +0000 X-MMR: 0 X-Antivirus: Scanned by F-Prot Antivirus (http://www.f-prot.com) X-OriginalArrivalTime: 23 Jun 2009 15:46:33.0593 (UTC) FILETIME=[C8BC8E90:01C9F419] Cc: Lisa Dusseault Subject: [calsify] Informal Last Call: CalDAV Scheduling Extensions to WebDAV [Fwd: I-D Action:draft-desruisseaux-caldav-sched-07.txt] X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org This is a multi-part message in MIME format. --------------000700060904030503070805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cyrus and I submitted draft-desruisseaux-caldav-sched-07 to the IETF last week. See Internet-Draft announcement below. Before requesting the IESG to consider this Internet-Draft as a Proposed Standard, we would like to get as much feedback as possible from the participants of the "caldav" mailing list as well as from the members of the WebDAV and Calsify Working Groups. Please review the document and send your comments to the caldav@ietf.org mailing list by July 7th, 2009. We would like to submit draft -08 before July 13, 2009, i.e., the final submission cut-off for the 75th IETF in Stockholm, Sweden. Thanks, Bernard P.S. Draft -07 is available in .xml, .txt., .html, and .pdf format: http://tools.ietf.org/id/draft-desruisseaux-caldav-sched-07.xml http://tools.ietf.org/id/draft-desruisseaux-caldav-sched-07.txt http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-07 http://tools.ietf.org/pdf/draft-desruisseaux-caldav-sched-07.pdf -------- Original Message -------- Subject: I-D Action:draft-desruisseaux-caldav-sched-07.txt Date: Fri, 19 Jun 2009 19:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CalDAV Scheduling Extensions to WebDAV Author(s) : C. Daboo, B. Desruisseaux Filename : draft-desruisseaux-caldav-sched-07.txt Pages : 94 Date : 2009-06-19 This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-desruisseaux-caldav-sched-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------000700060904030503070805 Content-Type: Message/External-body; name="draft-desruisseaux-caldav-sched-07.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-desruisseaux-caldav-sched-07.txt" Content-Type: text/plain Content-ID: <2009-06-19190523.I-D@ietf.org> --------------000700060904030503070805 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------000700060904030503070805 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --------------000700060904030503070805-- From calsify-bounces@ietf.org Mon Jun 29 21:04:16 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10DB03A6C85; Mon, 29 Jun 2009 21:04:16 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF2A3A69CD for ; Mon, 29 Jun 2009 21:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85cqnhHn+LXa for ; Mon, 29 Jun 2009 21:04:14 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 525BD28C1F2 for ; Mon, 29 Jun 2009 21:04:08 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA05.westchester.pa.mail.comcast.net with comcast id A4491c0050cZkys5544WeP; Tue, 30 Jun 2009 04:04:30 +0000 Received: from THare ([71.203.105.66]) by OMTA10.westchester.pa.mail.comcast.net with comcast id A44V1c0011RyUCv3W44Vp0; Tue, 30 Jun 2009 04:04:30 +0000 From: "Tim Hare" To: , Date: Tue, 30 Jun 2009 00:04:27 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Acn5N9wXxCKZRCzbSFSX8zqpeB90wQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Message-Id: <20090630040409.525BD28C1F2@core3.amsl.com> Subject: [calsify] Question re: RFC 2445 and VJOURNAL X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0514287481==" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org This is a multi-part message in MIME format. --===============0514287481== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C9F916.5AAAA7A0" This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C9F916.5AAAA7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I went looking for VJOURNAL info in the 2445 spec and I noticed there is no DTEND or DURATION mentioned. Some use cases (recording phone call time for billing ) need a duration. Is this an oversight or an intentional omission? I've not found VJOURNAL mentioned in the thread index back into 2006. Is there, somewhere, a search function to search the text of message posting? -------------------------------------------------- snip ---------------------------------------------------------- Format Definition: A "VJOURNAL" calendar component is defined by the following notation: journalc = "BEGIN" ":" "VJOURNAL" CRLF jourprop "END" ":" "VJOURNAL" CRLF jourprop = *( ; ; the following are REQUIRED, ; but MUST NOT occur more than once ; dtstamp / uid / ; ; the following are OPTIONAL, ; but MUST NOT occur more than once ; class / created / dtstart / last-mod / organizer / recurid / seq / status / summary / url / ; ; the following is OPTIONAL, ; but SHOULD NOT occur more than once ; rrule / ; ; the following are OPTIONAL, ; and MAY occur more than once ; attach / attendee / categories / comment / contact / description / exdate / related / rdate / rstatus / x-prop / iana-prop ; ) -------------------------------------------------- snip ---------------------------------------------------------- Tim Hare Interested Bystander, Non-Inc. ------=_NextPart_000_0023_01C9F916.5AAAA7A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I went = looking for=20 VJOURNAL info in the 2445 spec and I noticed there is no DTEND or = DURATION =20 mentioned. Some use cases (recording phone call time for billing ) need = a=20 duration.  Is this an oversight or an intentional omission?  = I've not=20 found VJOURNAL mentioned in the thread index back into 2006.  Is = there,=20 somewhere, a search function to search the text of message=20 posting?
 
-------------------------------------------------- snip=20 ----------------------------------------------------------<= /DIV> 
   Format Definition:  A =
"VJOURNAL" calendar component is defined by the
      following notation:

        journalc   =3D "BEGIN" ":" "VJOURNAL" CRLF
                     jourprop
                     "END" ":" "VJOURNAL" CRLF

        jourprop   =3D *(
                   ;
                   ; the following are REQUIRED,
                   ; but MUST NOT occur more than once
                   ;
                   dtstamp / uid /
                   ;
                   ; the following are OPTIONAL,
                   ; but MUST NOT occur more than once
                   ;
                   class / created / dtstart /
                   last-mod / organizer / recurid / seq /
                   status / summary / url /
                   ;
                   ; the following is OPTIONAL,
                   ; but SHOULD NOT occur more than once
                   ;
                   rrule /
                   ;
                   ; the following are OPTIONAL,
                   ; and MAY occur more than once
                   ;
                   attach / attendee / categories / comment /
                   contact / description / exdate / related / rdate /
                   rstatus / x-prop / iana-prop
                   ;
                   )
-------------------------------------------------- snip =
----------------------------------------------------------<=
/PRE>
Tim Hare
Interested =
Bystander, Non-Inc.
------=_NextPart_000_0023_01C9F916.5AAAA7A0-- --===============0514287481== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --===============0514287481==-- From timhare@comcast.net Mon Jun 29 21:04:15 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF2A3A69CD for ; Mon, 29 Jun 2009 21:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85cqnhHn+LXa for ; Mon, 29 Jun 2009 21:04:14 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 525BD28C1F2 for ; Mon, 29 Jun 2009 21:04:08 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA05.westchester.pa.mail.comcast.net with comcast id A4491c0050cZkys5544WeP; Tue, 30 Jun 2009 04:04:30 +0000 Received: from THare ([71.203.105.66]) by OMTA10.westchester.pa.mail.comcast.net with comcast id A44V1c0011RyUCv3W44Vp0; Tue, 30 Jun 2009 04:04:30 +0000 From: "Tim Hare" To: , Date: Tue, 30 Jun 2009 00:04:27 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C9F916.5AAAA7A0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Acn5N9wXxCKZRCzbSFSX8zqpeB90wQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Message-Id: <20090630040409.525BD28C1F2@core3.amsl.com> Subject: [calsify] Question re: RFC 2445 and VJOURNAL X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 04:04:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C9F916.5AAAA7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I went looking for VJOURNAL info in the 2445 spec and I noticed there is no DTEND or DURATION mentioned. Some use cases (recording phone call time for billing ) need a duration. Is this an oversight or an intentional omission? I've not found VJOURNAL mentioned in the thread index back into 2006. Is there, somewhere, a search function to search the text of message posting? -------------------------------------------------- snip ---------------------------------------------------------- Format Definition: A "VJOURNAL" calendar component is defined by the following notation: journalc = "BEGIN" ":" "VJOURNAL" CRLF jourprop "END" ":" "VJOURNAL" CRLF jourprop = *( ; ; the following are REQUIRED, ; but MUST NOT occur more than once ; dtstamp / uid / ; ; the following are OPTIONAL, ; but MUST NOT occur more than once ; class / created / dtstart / last-mod / organizer / recurid / seq / status / summary / url / ; ; the following is OPTIONAL, ; but SHOULD NOT occur more than once ; rrule / ; ; the following are OPTIONAL, ; and MAY occur more than once ; attach / attendee / categories / comment / contact / description / exdate / related / rdate / rstatus / x-prop / iana-prop ; ) -------------------------------------------------- snip ---------------------------------------------------------- Tim Hare Interested Bystander, Non-Inc. ------=_NextPart_000_0023_01C9F916.5AAAA7A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I went = looking for=20 VJOURNAL info in the 2445 spec and I noticed there is no DTEND or = DURATION =20 mentioned. Some use cases (recording phone call time for billing ) need = a=20 duration.  Is this an oversight or an intentional omission?  = I've not=20 found VJOURNAL mentioned in the thread index back into 2006.  Is = there,=20 somewhere, a search function to search the text of message=20 posting?
 
-------------------------------------------------- snip=20 ----------------------------------------------------------<= /DIV> 
   Format Definition:  A =
"VJOURNAL" calendar component is defined by the
      following notation:

        journalc   =3D "BEGIN" ":" "VJOURNAL" CRLF
                     jourprop
                     "END" ":" "VJOURNAL" CRLF

        jourprop   =3D *(
                   ;
                   ; the following are REQUIRED,
                   ; but MUST NOT occur more than once
                   ;
                   dtstamp / uid /
                   ;
                   ; the following are OPTIONAL,
                   ; but MUST NOT occur more than once
                   ;
                   class / created / dtstart /
                   last-mod / organizer / recurid / seq /
                   status / summary / url /
                   ;
                   ; the following is OPTIONAL,
                   ; but SHOULD NOT occur more than once
                   ;
                   rrule /
                   ;
                   ; the following are OPTIONAL,
                   ; and MAY occur more than once
                   ;
                   attach / attendee / categories / comment /
                   contact / description / exdate / related / rdate /
                   rstatus / x-prop / iana-prop
                   ;
                   )
-------------------------------------------------- snip =
----------------------------------------------------------<=
/PRE>
Tim Hare
Interested =
Bystander, Non-Inc.
------=_NextPart_000_0023_01C9F916.5AAAA7A0-- From ietf-calsify-bounces@osafoundation.org Mon Jun 29 21:04:36 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3AE928C0DD for ; Mon, 29 Jun 2009 21:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_05=-1.11, HTML_MESSAGE=0.001, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqXAhz1fwgiF for ; Mon, 29 Jun 2009 21:04:35 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id 982CF28C178 for ; Mon, 29 Jun 2009 21:04:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 4958F79401B; Mon, 29 Jun 2009 21:04:55 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiXgg6d4F-tI; Mon, 29 Jun 2009 21:04:48 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id D341777D719; Mon, 29 Jun 2009 21:04:44 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 0EA1177D719 for ; Mon, 29 Jun 2009 21:04:40 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuSvknq5k5uR for ; Mon, 29 Jun 2009 21:04:30 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by leka.osafoundation.org (Postfix) with ESMTP id 403FA77D702 for ; Mon, 29 Jun 2009 21:04:29 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA03.westchester.pa.mail.comcast.net with comcast id A3yi1c0020cZkys5344WFY; Tue, 30 Jun 2009 04:04:30 +0000 Received: from THare ([71.203.105.66]) by OMTA10.westchester.pa.mail.comcast.net with comcast id A44V1c0011RyUCv3W44Vp0; Tue, 30 Jun 2009 04:04:30 +0000 From: "Tim Hare" To: , Date: Tue, 30 Jun 2009 00:04:27 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Acn5N9wXxCKZRCzbSFSX8zqpeB90wQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Message-Id: <20090630040430.403FA77D702@leka.osafoundation.org> Subject: [ietf-calsify] Question re: RFC 2445 and VJOURNAL X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1336175560==" Mime-version: 1.0 Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org This is a multi-part message in MIME format. --===============1336175560== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C9F916.5AAAA7A0" This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C9F916.5AAAA7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I went looking for VJOURNAL info in the 2445 spec and I noticed there is no DTEND or DURATION mentioned. Some use cases (recording phone call time for billing ) need a duration. Is this an oversight or an intentional omission? I've not found VJOURNAL mentioned in the thread index back into 2006. Is there, somewhere, a search function to search the text of message posting? -------------------------------------------------- snip ---------------------------------------------------------- Format Definition: A "VJOURNAL" calendar component is defined by the following notation: journalc = "BEGIN" ":" "VJOURNAL" CRLF jourprop "END" ":" "VJOURNAL" CRLF jourprop = *( ; ; the following are REQUIRED, ; but MUST NOT occur more than once ; dtstamp / uid / ; ; the following are OPTIONAL, ; but MUST NOT occur more than once ; class / created / dtstart / last-mod / organizer / recurid / seq / status / summary / url / ; ; the following is OPTIONAL, ; but SHOULD NOT occur more than once ; rrule / ; ; the following are OPTIONAL, ; and MAY occur more than once ; attach / attendee / categories / comment / contact / description / exdate / related / rdate / rstatus / x-prop / iana-prop ; ) -------------------------------------------------- snip ---------------------------------------------------------- Tim Hare Interested Bystander, Non-Inc. ------=_NextPart_000_0023_01C9F916.5AAAA7A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I went = looking for=20 VJOURNAL info in the 2445 spec and I noticed there is no DTEND or = DURATION =20 mentioned. Some use cases (recording phone call time for billing ) need = a=20 duration.  Is this an oversight or an intentional omission?  = I've not=20 found VJOURNAL mentioned in the thread index back into 2006.  Is = there,=20 somewhere, a search function to search the text of message=20 posting?
 
-------------------------------------------------- snip=20 ----------------------------------------------------------<= /DIV> 
   Format Definition:  A =
"VJOURNAL" calendar component is defined by the
      following notation:

        journalc   =3D "BEGIN" ":" "VJOURNAL" CRLF
                     jourprop
                     "END" ":" "VJOURNAL" CRLF

        jourprop   =3D *(
                   ;
                   ; the following are REQUIRED,
                   ; but MUST NOT occur more than once
                   ;
                   dtstamp / uid /
                   ;
                   ; the following are OPTIONAL,
                   ; but MUST NOT occur more than once
                   ;
                   class / created / dtstart /
                   last-mod / organizer / recurid / seq /
                   status / summary / url /
                   ;
                   ; the following is OPTIONAL,
                   ; but SHOULD NOT occur more than once
                   ;
                   rrule /
                   ;
                   ; the following are OPTIONAL,
                   ; and MAY occur more than once
                   ;
                   attach / attendee / categories / comment /
                   contact / description / exdate / related / rdate /
                   rstatus / x-prop / iana-prop
                   ;
                   )
-------------------------------------------------- snip =
----------------------------------------------------------<=
/PRE>
Tim Hare
Interested =
Bystander, Non-Inc.
------=_NextPart_000_0023_01C9F916.5AAAA7A0-- --===============1336175560== 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 --===============1336175560==-- From calsify-bounces@ietf.org Tue Jun 30 10:42:18 2009 Return-Path: X-Original-To: calsify-archive-feit0ahl@lists.ietf.org Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4678428C438; Tue, 30 Jun 2009 10:42:18 -0700 (PDT) X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4492B3A6C7F for ; Tue, 30 Jun 2009 10:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvq-7Ie6ASWf for ; Tue, 30 Jun 2009 10:42:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 0FD7728C419 for ; Tue, 30 Jun 2009 10:42:14 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so91748fgg.18 for ; Tue, 30 Jun 2009 10:41:50 -0700 (PDT) Received: by 10.86.99.12 with SMTP id w12mr1911840fgb.77.1246383710442; Tue, 30 Jun 2009 10:41:50 -0700 (PDT) Received: from ?192.168.0.100? ([193.86.152.31]) by mx.google.com with ESMTPS id d4sm571355fga.8.2009.06.30.10.41.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Jun 2009 10:41:49 -0700 (PDT) Message-ID: <4A4A4DE6.6090401@apthorpia.com> Date: Tue, 30 Jun 2009 19:39:50 +0200 From: Adrian Apthorp User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: calsify@ietf.org, ietf-calsify@osafoundation.org References: <20090630040409.525BD28C1F2@core3.amsl.com> In-Reply-To: <20090630040409.525BD28C1F2@core3.amsl.com> Subject: Re: [calsify] Question re: RFC 2445 and VJOURNAL X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: calsify-bounces@ietf.org Errors-To: calsify-bounces@ietf.org Hmm, I had a similar question with LOCATION which is also omitted from VJOURNAL Tim Hare wrote: > I went looking for VJOURNAL info in the 2445 spec and I noticed there > is no DTEND or DURATION mentioned. Some use cases (recording phone > call time for billing ) need a duration. Is this an oversight or an > intentional omission? I've not found VJOURNAL mentioned in the thread > index back into 2006. Is there, somewhere, a search function to > search the text of message posting? > > -------------------------------------------------- snip > ---------------------------------------------------------- > Format Definition: A "VJOURNAL" calendar component is defined by the > following notation: > > journalc = "BEGIN" ":" "VJOURNAL" CRLF > jourprop > "END" ":" "VJOURNAL" CRLF > > jourprop = *( > ; > ; the following are REQUIRED, > ; but MUST NOT occur more than once > ; > dtstamp / uid / > ; > ; the following are OPTIONAL, > ; but MUST NOT occur more than once > ; > class / created / dtstart / > last-mod / organizer / recurid / seq / > status / summary / url / > ; > ; the following is OPTIONAL, > ; but SHOULD NOT occur more than once > ; > rrule / > ; > ; the following are OPTIONAL, > ; and MAY occur more than once > ; > attach / attendee / categories / comment / > contact / description / exdate / related / rdate / > rstatus / x-prop / iana-prop > ; > ) > -------------------------------------------------- snip ---------------------------------------------------------- > Tim Hare > Interested Bystander, Non-Inc. > ------------------------------------------------------------------------ > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From adrian@apthorpia.com Tue Jun 30 10:42:16 2009 Return-Path: X-Original-To: calsify@core3.amsl.com Delivered-To: calsify@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4492B3A6C7F for ; Tue, 30 Jun 2009 10:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvq-7Ie6ASWf for ; Tue, 30 Jun 2009 10:42:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 0FD7728C419 for ; Tue, 30 Jun 2009 10:42:14 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so91748fgg.18 for ; Tue, 30 Jun 2009 10:41:50 -0700 (PDT) Received: by 10.86.99.12 with SMTP id w12mr1911840fgb.77.1246383710442; Tue, 30 Jun 2009 10:41:50 -0700 (PDT) Received: from ?192.168.0.100? ([193.86.152.31]) by mx.google.com with ESMTPS id d4sm571355fga.8.2009.06.30.10.41.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Jun 2009 10:41:49 -0700 (PDT) Message-ID: <4A4A4DE6.6090401@apthorpia.com> Date: Tue, 30 Jun 2009 19:39:50 +0200 From: Adrian Apthorp User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: calsify@ietf.org, ietf-calsify@osafoundation.org References: <20090630040409.525BD28C1F2@core3.amsl.com> In-Reply-To: <20090630040409.525BD28C1F2@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [calsify] Question re: RFC 2445 and VJOURNAL X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 17:42:16 -0000 Hmm, I had a similar question with LOCATION which is also omitted from VJOURNAL Tim Hare wrote: > I went looking for VJOURNAL info in the 2445 spec and I noticed there > is no DTEND or DURATION mentioned. Some use cases (recording phone > call time for billing ) need a duration. Is this an oversight or an > intentional omission? I've not found VJOURNAL mentioned in the thread > index back into 2006. Is there, somewhere, a search function to > search the text of message posting? > > -------------------------------------------------- snip > ---------------------------------------------------------- > Format Definition: A "VJOURNAL" calendar component is defined by the > following notation: > > journalc = "BEGIN" ":" "VJOURNAL" CRLF > jourprop > "END" ":" "VJOURNAL" CRLF > > jourprop = *( > ; > ; the following are REQUIRED, > ; but MUST NOT occur more than once > ; > dtstamp / uid / > ; > ; the following are OPTIONAL, > ; but MUST NOT occur more than once > ; > class / created / dtstart / > last-mod / organizer / recurid / seq / > status / summary / url / > ; > ; the following is OPTIONAL, > ; but SHOULD NOT occur more than once > ; > rrule / > ; > ; the following are OPTIONAL, > ; and MAY occur more than once > ; > attach / attendee / categories / comment / > contact / description / exdate / related / rdate / > rstatus / x-prop / iana-prop > ; > ) > -------------------------------------------------- snip ---------------------------------------------------------- > Tim Hare > Interested Bystander, Non-Inc. > ------------------------------------------------------------------------ > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > From ietf-calsify-bounces@osafoundation.org Tue Jun 30 10:42:56 2009 Return-Path: X-Original-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2F93A6E7D for ; Tue, 30 Jun 2009 10:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6okPETKs2HuK for ; Tue, 30 Jun 2009 10:42:54 -0700 (PDT) Received: from leka.osafoundation.org (leka.osafoundation.org [149.20.54.96]) by core3.amsl.com (Postfix) with ESMTP id D5A7B3A6C7F for ; Tue, 30 Jun 2009 10:42:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 8E7F479401E; Tue, 30 Jun 2009 10:42:22 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3HP+Vxc5oxg; Tue, 30 Jun 2009 10:42:19 -0700 (PDT) Received: from leka.osafoundation.org (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id AD88377D726; Tue, 30 Jun 2009 10:42:14 -0700 (PDT) X-Original-To: ietf-calsify@osafoundation.org Delivered-To: ietf-calsify@osafoundation.org Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id F2A5E77D71E for ; Tue, 30 Jun 2009 10:42:11 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBlX0RZDY64X for ; Tue, 30 Jun 2009 10:41:52 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by leka.osafoundation.org (Postfix) with ESMTP id AB16B79401D for ; Tue, 30 Jun 2009 10:41:51 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e21so99287fga.17 for ; Tue, 30 Jun 2009 10:41:50 -0700 (PDT) Received: by 10.86.99.12 with SMTP id w12mr1911840fgb.77.1246383710442; Tue, 30 Jun 2009 10:41:50 -0700 (PDT) Received: from ?192.168.0.100? ([193.86.152.31]) by mx.google.com with ESMTPS id d4sm571355fga.8.2009.06.30.10.41.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 30 Jun 2009 10:41:49 -0700 (PDT) Message-ID: <4A4A4DE6.6090401@apthorpia.com> Date: Tue, 30 Jun 2009 19:39:50 +0200 From: Adrian Apthorp User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: calsify@ietf.org, ietf-calsify@osafoundation.org References: <20090630040409.525BD28C1F2@core3.amsl.com> In-Reply-To: <20090630040409.525BD28C1F2@core3.amsl.com> Subject: Re: [ietf-calsify] [calsify] Question re: RFC 2445 and VJOURNAL X-BeenThere: ietf-calsify@osafoundation.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RFC2445, 2446 and 2447 Discusions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-calsify-bounces@osafoundation.org Errors-To: ietf-calsify-bounces@osafoundation.org Hmm, I had a similar question with LOCATION which is also omitted from VJOURNAL Tim Hare wrote: > I went looking for VJOURNAL info in the 2445 spec and I noticed there > is no DTEND or DURATION mentioned. Some use cases (recording phone > call time for billing ) need a duration. Is this an oversight or an > intentional omission? I've not found VJOURNAL mentioned in the thread > index back into 2006. Is there, somewhere, a search function to > search the text of message posting? > > -------------------------------------------------- snip > ---------------------------------------------------------- > Format Definition: A "VJOURNAL" calendar component is defined by the > following notation: > > journalc = "BEGIN" ":" "VJOURNAL" CRLF > jourprop > "END" ":" "VJOURNAL" CRLF > > jourprop = *( > ; > ; the following are REQUIRED, > ; but MUST NOT occur more than once > ; > dtstamp / uid / > ; > ; the following are OPTIONAL, > ; but MUST NOT occur more than once > ; > class / created / dtstart / > last-mod / organizer / recurid / seq / > status / summary / url / > ; > ; the following is OPTIONAL, > ; but SHOULD NOT occur more than once > ; > rrule / > ; > ; the following are OPTIONAL, > ; and MAY occur more than once > ; > attach / attendee / categories / comment / > contact / description / exdate / related / rdate / > rstatus / x-prop / iana-prop > ; > ) > -------------------------------------------------- snip ---------------------------------------------------------- > Tim Hare > Interested Bystander, Non-Inc. > ------------------------------------------------------------------------ > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > _______________________________________________ ietf-calsify mailing list ietf-calsify@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/ietf-calsify