Subject: Re: [Ietf-caldav] 3.3 Timezones
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Thu, 28 Apr 2005 10:52:19 -0400
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

As can be read in "Comment.2" of the same section, this is still
an open issue.

3.3  Timezones

    Calendar resources in CalDAV MUST be valid iCalendar objects.  As
    such, an individual VTIMEZONE calendar component MUST be specified
    for each unique TZID parameter value specified in an iCalendar
    object.  Unfortunately this mean that the same VTIMEZONE component
    will get sent or retrieved multiple times for each iCalendar object
    that uses the timezone.  This is not efficient in terms of bandwidth
    usage.

    [[Comment.2: Not clear how big an issue that really is.  CalDAV
    already allows clients to retrieve iCalendar objects without their
    VTIMEZONE component with the CALDAV:calendar-query REPORT.  It is
    still not clear whether a client could rely only on the value of the
    TZID parameter, or should it always requests a VTIMEZONE component
    with at least the TZID and TZURL properties and rely on the TZURL as
    a unique identifier for a given time zone.  CalDAV servers have no
    choice but to return complete VTIMEZONE components in iCalendar
    object retrieve with the GET method as their is no way to know if the
    client is a CalDAV client or a simple HTTP client.  On a PUT request
    perhaps a CalDAV server could accept an iCalendar object with a
    VTIMEZONE object that has at least TZURL that points to a calendar
    resource that defines a time zone on the server.  --desruisseaux]]

"There is never any justification for compromising correctness for
the sake of other concerns such as efficiency." -- Bertrand Meyer

CalDAV MUST always return valid iCalendar objects retrieved with the
GET method, that is, with complete VTIMEZONE components when necessary.

With the CALDAV:calendar-query REPORT CalDAV clients are able to
partially retrieve iCalendar objects, as such, clients may retrieve
iCalendar objects without their VTIMEZONE component(s). The draft will
need to specify what the CalDAV client may assume about the returned
TZID if anything (e.g., they can rely on them if they are prefix with
"/" or they can never rely on them).

When a CalDAV client creates or update an iCalendar object with the PUT
method it should provide the complete VTIMEZONE component. The draft
will need to specify whether clients are allowed to submit iCalendar
objects with TZID parameter value specified but no corresponding
VTIMEZONE component(s) (e.g., yes if the TZID is prefixed by "/" or
no otherwise) or whether clients should at least provide a VTIMEZONE
component for each TZID parameter value specified in the iCalendar
object, but allow them to only specify a TZURL property pointing to
a VTIMEZONE component stored in the timezone collection set of the
CalDAV server instead of providing the full definition.

I personally don't think that all this added complexity is required.

"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil." -- Donald E. Knuth

Cheers,
Bernard

Doug Royer wrote:

> 
> Later in that same section it says:
> 
>    The timezone collection is a calendar collection that contains only
>    VTIMEZONE components as separate resources within that collection.
> 
> So when I read it, it looks to me as if that does not sufficiently
> solve the problem.
> 
> I read it as saying that multiple VEVENTs can point to a single
> TZID in a timezone collection? If yes, then without a smart compare
> function it must not be used for externally created VEVENTS.
> As you could not guarantee that Vendor-A TZID-X was the
> same as TZID-X in the timezone collection.
> 
> An later in the draft it says:
> 
>  >  o  any top-level component that references a timezone via a "TZID"
>  >     property MUST include the VTIMEZONE component corresponding to
>  >     that timezone id, as required by iCalendar, unless the timezone is
>  >     one included in the server's timezone collection, as described in
>  >     Section 3.3.
>  >
>  >  For example, given the following iCalendar object:
> 
> Followed by an example that does not have a TZID or VTIMEZONE.
> 
> So, what is that saying? Is it saying that if a TZID is included
> and no such VTIMEZONE is included, go fetch it?
> 
> Or as the example shows, must you use UTC?
> 
> Or is it saying something else ?
> 
> 
> Bernard Desruisseaux wrote:
> 
>> Doug Royer wrote:
>>
>>>
>>> -05 says in part:
>>>
>>>  > 3.3  Timezones
>>>  >
>>> Its more complicated than that. It would need to be one VTIMEZONE
>>> component per unique VTIMEZONE definition.
>>>
>>> Without standardized TZID's, there is no guarantee that TZID-X
>>> is the same as TZID-X from another vendor, ORGANIZER, or ATTENDEE.
>>
>>
>>
>> The sentence « an individual "VTIMEZONE" calendar component MUST be
>> specified for each unique "TZID" parameter value specified in the
>> iCalendar object » was copied verbatim from section 4.2.19 Time Zone
>> Identifier of RFC 2445.
> 
> 
> Which does not have a separate VTIMEZONE container. So it can't have
> a conflict.
> 
>> While I understand what you are trying to say, this sentence is
>> only making reference to "an iCalendar object". I can't believe
>> a single iCalendar object would be making reference to multiple
>> VTIMEZONE definitions with a single TZID.
> 
> 
> 
> 
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

Date: Wed, 27 Apr 2005 18:44:26 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: CalDAV DevList <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-caldav] Have you seen this - WebDAV / CalDAVpatent issue ?

This is a cryptographically signed message in MIME format.

--------------ms020504080502010002060701
Content-Type: multipart/mixed; boundary="------------090007030706060703030908"

This is a multi-part message in MIME format.
--------------090007030706060703030908
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

http://www.frntln.com/Patent.htm

I have nothing to do with it!

They do XML tools of some kind.

April 2003  - Frontline Solutions is proud to announce our patent award:

"Method and System for Allowing Multiple Users to Edit a Hierarchical=20
Data Structure"

Patent No.:  US 6,529,905 B1

Abstract:

A method for locking elements of a hierarchical data structure to allow=20
multiple users at various distributed clients to simultaneously edit=20
unlocked portions of the data structure, and systems.  The method=20
includes check for permission, setting and releasing various kind of=20
locks.  The structured authoring systems of the invention may be=20
distributed and collaborative.  The process of checking for permission=20
to set a lock is unique for each type of lock.

Frontline Solutions strives for innovative and technically advanced=20
approaches in our software products.   Our software program Procura=99  i=
s=20
based on this patented technology.

--=20

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------090007030706060703030908
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consuiting.com
adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-612-4638
tel;fax:866-494-8574
tel;cell:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------090007030706060703030908--

--------------ms020504080502010002060701
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020504080502010002060701--

Date: Wed, 27 Apr 2005 13:56:48 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] 3.3  Timezones
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: CalDAV DevList <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms000603070803090301000902
Content-Type: multipart/mixed; boundary="------------040006000307030107020407"

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

Later in that same section it says:

    The timezone collection is a calendar collection that contains only
    VTIMEZONE components as separate resources within that collection.

So when I read it, it looks to me as if that does not sufficiently
solve the problem.

I read it as saying that multiple VEVENTs can point to a single
TZID in a timezone collection? If yes, then without a smart compare
function it must not be used for externally created VEVENTS.
As you could not guarantee that Vendor-A TZID-X was the
same as TZID-X in the timezone collection.

An later in the draft it says:

 >  o  any top-level component that references a timezone via a "TZID"
 >     property MUST include the VTIMEZONE component corresponding to
 >     that timezone id, as required by iCalendar, unless the timezone is=

 >     one included in the server's timezone collection, as described in
 >     Section 3.3.
 >
 >  For example, given the following iCalendar object:

Followed by an example that does not have a TZID or VTIMEZONE.

So, what is that saying? Is it saying that if a TZID is included
and no such VTIMEZONE is included, go fetch it?

Or as the example shows, must you use UTC?

Or is it saying something else ?

Bernard Desruisseaux wrote:
> Doug Royer wrote:
>=20
>>
>> -05 says in part:
>>
>>  > 3.3  Timezones
>>  >
>> Its more complicated than that. It would need to be one VTIMEZONE
>> component per unique VTIMEZONE definition.
>>
>> Without standardized TZID's, there is no guarantee that TZID-X
>> is the same as TZID-X from another vendor, ORGANIZER, or ATTENDEE.
>=20
>=20
> The sentence =AB an individual "VTIMEZONE" calendar component MUST be
> specified for each unique "TZID" parameter value specified in the
> iCalendar object =BB was copied verbatim from section 4.2.19 Time Zone
> Identifier of RFC 2445.

Which does not have a separate VTIMEZONE container. So it can't have
a conflict.

> While I understand what you are trying to say, this sentence is
> only making reference to "an iCalendar object". I can't believe
> a single iCalendar object would be making reference to multiple
> VTIMEZONE definitions with a single TZID.

--=20

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------040006000307030107020407
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consuiting.com
adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-612-4638
tel;fax:866-494-8574
tel;cell:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------040006000307030107020407--

--------------ms000603070803090301000902
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000603070803090301000902--

Date: Wed, 27 Apr 2005 14:00:52 -0400
From: Bernard Desruisseaux <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] 3.3  Timezones

Doug Royer wrote:

> 
> -05 says in part:
> 
>  > 3.3  Timezones
>  >
>  >   Calendar resources in CalDAV MUST be valid iCalendar objects.  As
>  >   such, an individual VTIMEZONE calendar component MUST be specified
>  >   for each unique TZID parameter value specified in an iCalendar
>  >   object.  Unfortunately this mean that the same VTIMEZONE component
>  >   will get sent or retrieved multiple times for each iCalendar object
> 
> Its more complicated than that. It would need to be one VTIMEZONE
> component per unique VTIMEZONE definition.
> 
> Without standardized TZID's, there is no guarantee that TZID-X
> is the same as TZID-X from another vendor, ORGANIZER, or ATTENDEE.

The sentence « an individual "VTIMEZONE" calendar component MUST be
specified for each unique "TZID" parameter value specified in the
iCalendar object » was copied verbatim from section 4.2.19 Time Zone
Identifier of RFC 2445.

While I understand what you are trying to say, this sentence is
only making reference to "an iCalendar object". I can't believe
a single iCalendar object would be making reference to multiple
VTIMEZONE definitions with a single TZID.

Cheers,
Bernard

Date: Tue, 26 Apr 2005 19:13:47 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: CalDAV DevList <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Subject: [Ietf-caldav] 3.3  Timezones
Reply-To: CalDAV DevList <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms070500000602020404050401
Content-Type: multipart/mixed; boundary="------------070500050704010507030209"

This is a multi-part message in MIME format.
--------------070500050704010507030209
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

-05 says in part:

 > 3.3  Timezones
 >
 >   Calendar resources in CalDAV MUST be valid iCalendar objects.  As
 >   such, an individual VTIMEZONE calendar component MUST be specified
 >   for each unique TZID parameter value specified in an iCalendar
 >   object.  Unfortunately this mean that the same VTIMEZONE component
 >   will get sent or retrieved multiple times for each iCalendar object

Its more complicated than that. It would need to be one VTIMEZONE
component per unique VTIMEZONE definition.

Without standardized TZID's, there is no guarantee that TZID-X
is the same as TZID-X from another vendor, ORGANIZER, or ATTENDEE.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------070500050704010507030209
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consuiting.com
adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-612-4638
tel;fax:866-494-8574
tel;cell:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------070500050704010507030209--

--------------ms070500000602020404050401
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070500000602020404050401--

Date: Mon, 25 Apr 2005 10:24:41 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Further about the Calconnect Recurrence Questionnaire - status, thanks, and future developments
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<i>This message is going to all of the lists where I posted our
original request for responses to the Consortium Recurrence
Questionnaire, so many of you will see it more than once.&nbsp; My apologies
for the duplications.<br>
<br>
</i><br>
Recently I posted a request on several of the calendaring discussion
lists for organizations with calendaring products/implementations to
please respond to our Recurrence Questionnaire.&nbsp; We've had sixteen
formal responses so far, and are delighted at both the number of
responses and the thought and care put into them.<br>
<br>
Our RECURR technical committee is beginning an analysis of the
responses, and may be contacting responders if we have additional
questions.&nbsp; We hope to have our analysis done and a report issued in
the next few weeks.&nbsp; The report will be posted on the Calconnect web
site and will be announced publicly to these discussion lists.&nbsp; As
noted in <br>
my original posting, the report will maintain the confidentiality of
the individual responses and will report results in an aggregate and
narrative fashion.<br>
<br>
We also wanted to let everyone know that there will be some more
questionnaires in the future.&nbsp; Several responders suggested a slightly
different questionnaire tackling recurrence issues at a higher and more
qualitative level, and we have begun work on that questionnare.&nbsp; We
hope to announce it within the next two-three weeks. &nbsp;<br>
<br>
Additionally, other Calconnect technical committes are considering
questionnaires in other areas of the RFCs of particular interest to the
Calsify effort as it develops, so there is a good chance we'll be
announcing these as they become ready for public consumption.&nbsp; We hope
that you will be as supportive of these future questionnaires and help
us with them as well.<br>
<br>
Several responders have remarked that they found the exercise of
filling out the questionnaire to be of help in understanding better
their own&nbsp; implementations, and we hope our future questionnaires,
focusing on other parts of the RFCs, will be as useful to you as we
hope they will be to us.<br>
<br>
Best regards,<br>
<br>
Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium<br>
<br>
</body>
</html>

Date: Mon, 18 Apr 2005 09:31:50 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] General Notification -- June Interop Tests and Roundtable III -- Calconnect:  The Calendaring and Scheduling Consortium
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<!-- Inserted by Calypso -->
<table id="_CalyPrintHeader_" style="display: none; color: black;"
 border="0" cellpadding="0" cellspacing="2" rules="none" width="100%">
  <tbody>
    <tr>
      <td colspan="3">
      <hr color="black" noshade="noshade" size="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Date:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;12/2/2004 07:52<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;From:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;David C. Thewlis<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;To:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Copy:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;"Robert Tolmach - WellGood Group" <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr align="left" valign="top">
      <td nowrap="nowrap" width="1"><b>&nbsp;Subject:</b><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td width="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
      <td>&nbsp;Call for Participantion -- Second Calconnect Interop - 11-12
January 2005 - Seattle, Washington<br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
    <tr>
      <td colspan="3">
      <hr color="black" noshade="noshade" size="1"><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
  </tbody>
</table>
<!-- End Calypso --><!-- Inserted by Calypso -->
<table id="_CalyMsgHeader_" style="display: none; color: rgb(0, 0, 0);"
 bgcolor="#c0c0c0" border="1" cellpadding="2" cellspacing="2"
 rules="none" width="100%">
  <tbody>
    <tr bgcolor="#c0c0c0">
      <td><font color="#000000" face="VERDANA,ARIAL,HELVETICA" size="-2">Received:
from psmtp.com (exprod6mx6.postini.com [64.18.1.146]) by
home.humboldt1.com (8.12.10/8.12.10) with SMTP id iB2Fq3mR014814 for <a
 class="moz-txt-link-rfc2396E" href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Thu, 2 Dec 2004 07:52:03 -0800 (PST)<br>
Received: from source ([208.31.106.91]) by exprod6mx6.postini.com
([64.18.5.10]) with SMTP; Thu, 02 Dec 2004 07:52:02 PST<br>
Received: from aix2.egenconsulting.com (localhost [127.0.0.1]) by
aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP id iB2FlvWi018040
for <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
Thu, 2 Dec 2004
10:47:57 -0500<br>
Received: (from majordom@localhost) by aix2.egenconsulting.com
(8.13.1/8.13.1/Submit) id iB2FlvFI018426 for calconnect-l-list; Thu, 2
Dec 2004 10:47:57 -0500<br>
X-Authentication-Warning: aix2.egenconsulting.com: majordom set sender
to <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>
using -f<br>
Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net
[68.230.241.35]) by aix2.egenconsulting.com (8.13.1/8.13.1) with ESMTP
id iB2FlcTM019480; Thu, 2 Dec 2004 10:47:38 -0500<br>
Received: from davet23 ([24.254.88.112]) by fed1rmmtao04.cox.net
(InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id
&lt;20041202154833.YTO5357.fed1rmmtao04.cox.net@davet23&gt; Thu, 2 Dec
2004 10:48:33 -0500<br>
Message-ID: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
References: <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
X-Mailer: Calypso Version 3.30.00.00 (4)<br>
Date: Thu, 02 Dec 2004 07:48:00 -0800<br>
Reply-To: <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
From: "David C. Thewlis" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
To: "calconnect-l reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-caldav reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"IETF
CALSCH" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"ietf-calsify reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"www-rdf-calendar reflector" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a><br>
Cc: "Robert Tolmach - WellGood Group" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"Brian Dear" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
"John Carbone" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>,
      <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a>, <a
 class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
Subject: Call for Participantion -- Second Calconnect Interop - 11-12
January 2005 - Seattle, Washington<br>
Mime-Version: 1.0<br>
Content-Type: multipart/alternative; boundary="=====_11020024806334=_"<br>
Sender: <a class="moz-txt-link-abbreviated"
 href="mailto:[email-masked]">[email-masked]</a><br>
Precedence: bulk<br>
X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.9108 M:94.8624
C:98.9754 )<br>
X-pstn-settings: 5 (2.0000:2.0000) s gt3 gt2 gt1 r p m c <br>
X-pstn-addresses: from <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a>
forward
(user good) [2395/93] <br>
      </font><br>
      <br>
      <br>
      <br>
      <br>
      <br>
      </td>
    </tr>
  </tbody>
</table>
<!-- End Calypso -->
<div><em>Please note that this announcement is being posted on multiple
calendaring-related reflectors and to the Calconnect mailing lists to
ensure as wide a distribution as possible.&nbsp; Our apologies if you
receive multiple copies.</em></div>
<div><em></em>&nbsp;</div>
<div>&nbsp;</div>
<div><strong>CALL FOR PARTICIPATION -- THIRD INTEROP TESTING EVENT -&nbsp;
1-2 June 2005<br>
<br>
CONSORTIUM ROUNDTABLE III MEMBER MEETINGS 1-3 June 2005<br>
</strong></div>
<div>&nbsp;</div>
<div>The third Interop of The Calendaring and Scheduling Consortium
(CALCONNECT.ORG) will take place Wednesday and Thursday, June 1-2,
2005.&nbsp; It will be hosted by Duke University in Durham, North Carolina.</div>
<div>&nbsp;</div>
<div>This event will feature multiple Interop testing scenarios.&nbsp;
Participating organizations are welcome to test against multiple
scenarios.&nbsp; These scenarios will be going on
simultaneously so you will probably need a person for each scenario you
participate in.</div>
<div>&nbsp;<br>
A Consortium Roundtable will be colocated from
1-3 June 2005 featuring Technical Committee sessions and a full Plenary
of the Consortium.<br>
<br>
</div>
<div>Space will be&nbsp;limited to 40 paticipants in both the Roundtable and
Interop so early&nbsp;notification and registration is advised.</div>
<div>&nbsp;</div>
<div><strong>INTEROP SCENARIOS<br>
<br>
</strong></div>
<br>
The exact scenarios are still being worked on and can certainly change
to meet participants' needs.&nbsp; Current plans include:<br>
<ul>
  <li>Extended CalDAV tests between CalDAV servers and any clients
supporting CalDAV</li>
  <li>iMIP testing</li>
  <li>iCalendar - General tests; clients importing/exporting each
other's data with formal scripts</li>
  <li>Testing to support CalsifySIFY work</li>
  <ul>
    <li>Handling of Timezones</li>
    <li>Recurrence exceptions and Recurrence Rules</li>
    <li>Other specific areas as identified prior to June<br>
    </li>
  </ul>
  <li>Min-IOP (Minimum Interoperable Subset) validation</li>
  <li>Other interop scenarios can be added if there is a specific need,
for example iCalendar&lt;--&gt;RDF<br>
  </li>
</ul>
&nbsp;
<div><strong>WHO MAY PARTICIPATE IN THE INTEROPS</strong></div>
<div>&nbsp;</div>
<div>Any vendors or organizations wishing to test a calendaring and
scheduling implementation are welcome to attend whether or not they are
Consortium members.&nbsp; Consortium members receive a
substantial discount on their Interop participation fee (see below).</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><strong>CONSORTIUM ROUNDTABLE III</strong></div>
<div>&nbsp;</div>
<div>Technical committee meetings&nbsp;of the Calendaring and Scheduling
Consortium are planned for&nbsp;1-2 June at the same location, followed by
an all-hands&nbsp;Consortium Roundtable on Friday 3 June.&nbsp; Interop
participants who are not&nbsp;Consortium members may not particpate in the
other Consortium activities unless their organization indicates that it
wishes to do so as an observer for this Roundtable (a non-member can
participate in a single Roundtable as an observer to determine its
interest in joining the Consortium).&nbsp; A non-member Interop Participant
can also join the Consortium at the event
and become a member immediately and be able to participate in the
technical committee and roundtable meetings.<br>
<br>
Please note that it will probably be impossible for a single
individual to both participate in the Interop and still be able to
participate at all in the TC meetings of hte Roundtable simply due to
the simultaneous nature of the events.<br>
</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><strong>REGISTRATION FEE</strong></div>
<div>&nbsp;</div>
<div><b>Interop:</b> $1500 for Consortium
members and $2500 for non-members.&nbsp; The registration fee covers two
individuals; additional individuals are $275 each for members or
non-members.&nbsp; (If you are planning to participate in more than one
Interop scenario, or participate in all the TC meetings, you will need
more than one person and possibley more than two.)</div>
<div>&nbsp;</div>
<div><strong></strong>The Interop
Registration Fee also covers participation in the&nbsp;Consortium Roundtable
for members or declared observers.</div>
<div>&nbsp;<br>
<b>Roundtable:</b>&nbsp; $275 per individual until 15
May and $325 thereafter.&nbsp; Registration for the Roundtable does <b>not</b>
include Interop participation.<br>
</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><strong>HOW TO REGISTER AND FURTHER INFORMATION</strong></div>
<div>&nbsp;</div>
<div>Logistics, registration and other information may be found on the
Consortium Website:&nbsp; see <a class="moz-txt-link-freetext"
 href="http://www.calconnect.org">http://www.calconnect.org</a> and go
to the Coming
Events area; see "Roundtable III" and "Jun 2005 Interop".<br>
</div>
<div>&nbsp;</div>
<div>For questions or more information, or to inform us of your plan to
participate in the Interop, please contact me at the Consortium.&nbsp; Plan
to register as soon as possible to ensure we will have room.<br>
<br>
</div>
<div>&nbsp;</div>
<div>Best Regards,</div>
<div>&nbsp;</div>
<div>Dave Thewlis</div>
<div>Executive Director</div>
<div>The Calendaring and Scheduling Consortium</div>
<div>
<div>1550 Dena Drive</div>
<div>McKinleyville CA 95519-4146</div>
<div>+1 707 840 9391 (voice)</div>
<div>+1 415 946 3454 (fax)</div>
<div>+1 707 498 2238 (mobile)</div>
<div><a href="mailto:[email-masked]">[email-masked]</a></div>
<div><a href="http://www.calconnect.org">www.calconnect.org</a></div>
</div>
.
</body>
</html>

Date: Fri, 15 Apr 2005 12:59:20 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: "[email-masked]" <[email-masked]>, Calsify <[email-masked]>, CalDAV DevList <[email-masked]>
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: 
Subject: [Ietf-caldav] Document Action: 'Calendar Access Protocol (CAP)' to Experimental RFC 
Reply-To: "[email-masked]" <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms050803010100090309050007
Content-Type: multipart/mixed; boundary="------------090107000606060801060006"

This is a multi-part message in MIME format.
--------------090107000606060801060006
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

It has taken forever - it is on it way!!

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Date: Fri, 15 Apr 2005 13:15:42 -0400
Subject: Document Action: 'Calendar Access Protocol (CAP)' to
  Experimental RFC

The IESG has approved the following document:

- 'Calendar Access Protocol (CAP) '
    <draft-royer-calsch-cap-02.txt> as an Experimental RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Ted Hardie.

IANA Note:

This draft includes registrations under RFC 2445, section 7.1;
these are the first registrations of that type, and a registry will be 
needed
for them. The author of this specification, as well as the original authors
of RFC 2445 should be consulted as to its form.

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

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------090107000606060801060006
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consuiting.com
adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-612-4638
tel;fax:866-494-8574
tel;cell:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------090107000606060801060006--

--------------ms050803010100090309050007
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms050803010100090309050007--

From: Helge Hess <[email-masked]>
Subject: Re: [Ietf-caldav] attendee;cutype
Date: Thu, 7 Apr 2005 22:52:35 +0200
To: CalDAV DevList <[email-masked]>

On Apr 7, 2005, at 22:28, Cyrus Daboo wrote:
> It seems to me that you would probably want to extend the CALADRURI 
> defined in RFC2739 to accept a CUTYPE= parameter to add that 
> information into the vCard.

Sounds reasonable, thanks.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Thu, 07 Apr 2005 16:28:04 -0400
From: Cyrus Daboo <[email-masked]>
To: Helge Hess <[email-masked]>, CalDAV DevList <[email-masked]>
Subject: Re: [Ietf-caldav] attendee;cutype
Cc: 

Hi Helge,

--On April 7, 2005 10:06:32 PM +0200 Helge Hess 
<[email-masked]> wrote:

> we are currently discussing on how to allow booking of resources in
> conjunction with iCalendar and I suppose it matters for CalDAV as well.
>
> iCalendar already supports resources with various approaches, eg
> "attendee;cutype=room" for booking a scheduled room.
> Our assumption is that the attendee fields in CUA are mostly derived from
> either a local vCard or an LDAP directory.
>
> So the question is: How can I derive the 'cutype' from a vCard or an LDAP
> contact record?
>

It seems to me that you would probably want to extend the CALADRURI defined 
in RFC2739 to accept a CUTYPE= parameter to add that information into the 
vCard. I'm not sure what the right approach is for the LDAP attributes 
defined in that document.

-- 
Cyrus Daboo

To: CalDAV DevList <[email-masked]>
From: Helge Hess <[email-masked]>
Date: Thu, 7 Apr 2005 22:06:32 +0200
Subject: [Ietf-caldav] attendee;cutype

Hi,

we are currently discussing on how to allow booking of resources in 
conjunction with iCalendar and I suppose it matters for CalDAV as well.

iCalendar already supports resources with various approaches, eg 
"attendee;cutype=room" for booking a scheduled room.
Our assumption is that the attendee fields in CUA are mostly derived 
from either a local vCard or an LDAP directory.

So the question is: How can I derive the 'cutype' from a vCard or an 
LDAP contact record?

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Date: Wed, 06 Apr 2005 09:34:09 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Calconnect Questionnaire on Recurrence - request responses by 11 April
Reply-To: [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I would like to thank those who have already responded to our request
last week to complete our Recurrence Questionnaire, and to ask for more
responses.&nbsp; If you haven't responded, please do so -- the more
implementations we have information about, the more valuable the
results will be to everyone.<br>
<br>
We really need your responses by <b>Monday evening, 11 April</b>, as
we want to start looking at the results later next week.&nbsp; <br>
<br>
You can find the questionnaire at<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.calconnect.org/recurrencequestionnaire.html">http://www.calconnect.org/recurrencequestionnaire.html</a><br>
<br>
Please contact me with any questions.<br>
<br>
Dave Thewlis<br>
Calconnect - The Calendaring and Scheduling Consortium<br>
+1 707 840 9391<br>
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.calconnnect.org">www.calconnnect.org</a><br>
</body>
</html>

To: CalDAV DevList <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Sun, 3 Apr 2005 17:42:57 -0700
Subject: [Ietf-caldav] Timezone collections

Putting together the whole picture on timezones (for myself as much as 
for anyone):
  - Only components with an RRULE (not regular events, and not exception 
components) require timezone information.  This isn't that much data 
(my work calendar has only 20 recurring events out of about 400 
events).  Bandwidth limits aren't likely to be a problem even if every 
one of those recurring events has the whole VTIMEZONE in it.

  - The advantage to including the whole VTIMEZONE is that the event is 
self-contained.  With the URL to that recurring event, the client can 
download in a single GET request the entire recurring event, the RRULE, 
the timezone in which the RRULE must be evaluated, and all the 
exceptions and their properties.  This seems like a good thing for data 
consistency and for interoperability -- it's easier than requiring 
clients to be aware that they might have to download the timezone 
information from somewhere else.  An existing browser with no special 
CalDAV logic can use that URL, hand the resulting ICS file off to a 
calendar application, and voila, the calendar application has the whole 
event.

  - OTOH, there might also be advantages to having a shared timezone 
collection managed by the server.  For example, if new timezones are 
defined they would only have to be added on the server, rather than 
having users upgrade their clients.

  - Having a shared timezone collection means that the client MUST 
synchronize that collection periodically in case any timezone 
information on the server changes.  So far our only mechanism to do 
that would be to download all the ETags and compare them to the last 
cached set of timezone ETags.  Not a huge problem, but it is another 
thing to get wrong.

  - Having a shared timezone collection adds specification complexity 
(OPTIONS, properties, etc).  I don't think we've quite nailed this yet 
-- for example, do we define a way for a user to browse the set of 
server-defined timezones so that the user can select an appropriate one 
-- AND have this browsing support i18n?  (Or is that needed)?

I guess now that I've learned and thought more about this, I'm leaning 
towards removing the timezone collection.  However, I may well have 
overlooked advantages (or disadvantages, for that matter). Has anybody 
implemented this yet?  Has anybody found any issues or benefits?

Lisa

Date: Sun, 03 Apr 2005 15:17:05 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Sam Roberts <[email-masked]>
Subject: Re: [Ietf-caldav] dtend removed? (Re: draft-royer-ical-basic-01.txt -	sent to IETF)
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Cc: [email-masked], CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010102060608050004010305
Content-Type: multipart/mixed; boundary="------------040500020902040002060007"

This is a multi-part message in MIME format.
--------------040500020902040002060007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

This discussion belongs in CALSIFY - not CALDAV.

Sam Roberts wrote:
> Quoting [email-masked], on Sun, Jan 16, 2005 at 02:11:43PM -0700:
> 
>>I send -01 of iCal-Basis to the IETF. It fixed some problems and
>>typos that were sent to me and the lists. It also deprecates DTEND and
>>replaced the examples and ABNF with DURATION.
> 
> 
> dtstart/dtend and dtstart/duration are equivalent ONLY for single
> non-recurring events.

> A yearly event on that starts at april second   3PM, and goes until
> april 3 6PM will have different durations. This year it falls on
> DST. The duration will be different next year.
> 
> Anything starting on the 25th and going to the "-1th"/last day of the
> month will have a different duration every month. Etc.
> 
> It's also trivial to support doing the calculation of duration/dtend for
> a specific event.
> 
> Do you ever intend to support recurring events again?
> 
> I just hours ago wrote a little server that publishes all the birthdays
> in my address book as text/calendar over http, which is handy because my
> calendar program now subscribes to it. Those birthdays recur!
> 
> Sam
> 
> 
> 
>>Copy at:
>>
>>	http://inet-consulting.com/draft-royer-ical-basic-01.txt
>>
>>And HTML version at:
>>
>>	http://inet-consulting.com/draft-royer-ical-basic-01.html
>>	
>>-- 
>>
>>Doug Royer                     | http://INET-Consulting.com
>>-------------------------------|-----------------------------
>>[email-masked]                 | Office: (208)612-4638
>>http://Royer.com               | Fax:    (866)594-8574
>>                               | Cell:   (208)520-4044
>>
>>              We Do Standards - You Need Standards
>>
> 
> 
> 
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

--------------040500020902040002060007
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consuiting.com
adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-612-4638
tel;fax:866-494-8574
tel;cell:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------040500020902040002060007--

--------------ms010102060608050004010305
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010102060608050004010305--

Date: Sat, 2 Apr 2005 21:27:15 -0500
From: Sam Roberts <[email-masked]>
To: Doug Royer <[email-masked]>
Cc: [email-masked], CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ietf-caldav] dtend removed? (Re: draft-royer-ical-basic-01.txt - sent to IETF)

Quoting [email-masked], on Sun, Jan 16, 2005 at 02:11:43PM -0700:
> I send -01 of iCal-Basis to the IETF. It fixed some problems and
> typos that were sent to me and the lists. It also deprecates DTEND and
> replaced the examples and ABNF with DURATION.

dtstart/dtend and dtstart/duration are equivalent ONLY for single
non-recurring events.

A yearly event on that starts at april second   3PM, and goes until
april 3 6PM will have different durations. This year it falls on
DST. The duration will be different next year.

Anything starting on the 25th and going to the "-1th"/last day of the
month will have a different duration every month. Etc.

It's also trivial to support doing the calculation of duration/dtend for
a specific event.

Do you ever intend to support recurring events again?

I just hours ago wrote a little server that publishes all the birthdays
in my address book as text/calendar over http, which is handy because my
calendar program now subscribes to it. Those birthdays recur!

Sam

> Copy at:
> 
> 	http://inet-consulting.com/draft-royer-ical-basic-01.txt
> 
> And HTML version at:
> 
> 	http://inet-consulting.com/draft-royer-ical-basic-01.html
> 	
> -- 
> 
> Doug Royer                     | http://INET-Consulting.com
> -------------------------------|-----------------------------
> [email-masked]                 | Office: (208)612-4638
> http://Royer.com               | Fax:    (866)594-8574
>                                | Cell:   (208)520-4044
> 
>               We Do Standards - You Need Standards
> 

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked], [email-masked], [email-masked]
Date: Sat, 2 Apr 2005 12:55:50 +0200
Cc: 
Subject: [Ietf-caldav] Re: Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify

--nextPart1376318.2Dl4rzUC5u
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

David C. Thewlis wrote:
> The Recurrence Technical Committee of Calconnect - The Calendaring and
> Scheduling Consortium - needs your help.=A0 The Committee is collecting
> specific informationon how C&S implementations have, or have not,
> implemented the Recurrence Rules of RFCs 2445 and 2446, iCalendar and
> iTIP

Are you talking about creating the iCalendar data or interpreting them? E.g=
=2E=20
4.3.10.b: If an implementation always creates RRULEs with the FREQ part tha=
t=20
would be "Yes" for creating, but if it tries to understand RRULEs without a=
=20
=46REQ part,  it would mean that the implementation disregards the MUST whe=
n=20
reading the data and it would be "No" for reading.

So from which view do you want us to fill out the form?

Cheers,
Reinhold
=2D-=20
=2D-----------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain=
er

--nextPart1376318.2Dl4rzUC5u
Content-Type: application/pgp-signature

--nextPart1376318.2Dl4rzUC5u--

Date: Fri, 01 Apr 2005 08:43:24 -0800
From: "David C. Thewlis" <[email-masked]>
Organization: DCTA Inc.
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Help needed -- questionnaire on implementation of Recurrence Rules -- Calconnect and Calsify
Reply-To: [email-masked], [email-masked]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dear IETF-Caldav:<br>
<br>
This e-mail is going to IETF-Caldav, IETF-Calsify, IETF-Calendar and
www-rdf-calendar.&nbsp; My apologies if you get it more than once (which I'm
afraid most people probably will).<br>
<br>
The Recurrence Technical Committee of Calconnect - The Calendaring and
Scheduling Consortium - needs your help.&nbsp; The Committee is collecting
specific informationon how C&amp;S implementations have, or have not,
<br>
implemented the Recurrence Rules of RFCs 2445 and 2446, iCalendar and
iTIP, as part of its work to compile actual usage informaton and
interoperability issues.
<br>
<br>
The information collected will be analyzed and the results, with
specific product identifications eliminated, will be transmitted to the
incipient CALSIFY Working Group of the IETF as soon as possible.&nbsp; The
results will also be made generally available on the Consortium
website,
and will be input to Technical Committee recommendations to be
formulated once the results are available.<br>
<br>
If you are willing to help, please fill out the questionnaire linked
below.&nbsp; This is <b>absolutely NOT limited</b> <b>to Consortium members</b>;
we need
responses for as many products and implementations as possible for the
<br>
results to be of maximum value.&nbsp; The questionnaire may be found at:<br>
<br>
&nbsp;<a class="moz-txt-link-freetext"
 href="http://www.calconnect.org/recurrencequestionnaire.html">http://www.calconnect.org/recurrencequestionnaire.html</a><br>
<br>
Thank you for participating; I'll post again as soon as results are
available.<br>
<br>
Dave Thewlis, Executive Director<br>
CalConnect - The Calendaring and Scheduling Consortium<br>
<br>
<br>
</body>
</html>