Subject: [Ietf-calsify] Fwd: WG Review: Calendaring and Scheduling Standards Simplification (calsify)

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Wed Jun 29 11:43:21 2005

FYI

Begin forwarded message:

> From: IESG Secretary <[email-masked]>
> Date: June 29, 2005 11:42:13 AM PDT
> To: [email-masked]
> Cc: Subject: WG Review: Calendaring and Scheduling Standards 
> Simplification  (calsify)
>
> A new IETF working group has been proposed in the Applications Area. 
> The IESG
> has not made any determination as yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please 
> send your
> comments to the IESG mailing list ([email-masked]) by July 6th.
>
> +++
>
> Calendaring and Scheduling Standards Simplification (calsify)
> -------------------------------------------------------------
>
> Current Status: Proposed Working Group
>
> Chair(s):
> TBD
>
> Applications Area Director(s):
> Ted Hardie <[email-masked]>
> Scott Hollenbeck <[email-masked]>
>
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: 
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/
>
> Description of Working Group:
>
> The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, 
> and
> 2447 were released in November 1998, and further described in RFC 3283.
> They were designed to progress the level of interoperability between
> dissimilar calendaring and scheduling systems. The Calendaring and
> Scheduling Core Object Specification, iCalendar, succeeded in 
> establishing
> itself as the common format for exchanging calendaring information 
> across
> the Internet. On the other hand, only basic interoperability as been 
> achieved
> between different scheduling systems.
>
> The Calsify working group is chartered to:
>
> (1) Publish the interoperability issues that have arisen between
> calendaring and scheduling systems, as well as document the usage of
> iCalendar by other specifications.
>
> (2) Revise the Calendaring and Scheduling standards to advance the
> state of interoperable calendaring and scheduling by addressing
> the published interoperability issues. As far as it is possible, the
> working group will ensure backwards compatibility with widely deployed
> implementations and other specifications that use it.
>
> (3) Clarify the registration process for iCalendar extensions (i.e.,
> the current core object specification only provides a template
> to register new properties).
>
> (4) Advance the Calendaring and Scheduling standards to Draft Standard.
>
> (5) Work on transition (upgrade or versioning) mechanisms for calendar
> data exchange.
>
> Proposing an XML representation or transformation of iCalendar
> objects is out of the scope of this working group.
>
> Goals and Milestones:
>
> Jul 05 - Submit draft documenting interoperability issues for use in
> progressing RFCs to Draft Standard.
> Sep 05 - Submit iCalendar bis draft 00, with formatting changes from 
> RFC2445.
> Sep 05 - Submit iTIP bis draft 00
> Sep 05 - Submit iMIP bis draft 00
> Oct 05 - Submit revised interoperability issues draft version based on 
> WG
> discussion.
> Dec 05 - WG decision on what document(s) require transition mechanisms 
> and
> hopefully rough idea what these will look like (and add new goals if 
> needed)
> Mar 06 - WG last call on interoperability issues draft.
> May 06 - Submit interoperability issues document to IESG for 
> Informational RFC.
> May 06 - Submit version of iCalendar bis draft that addresses known
> interoperability issues from interop events.
> Jun 06 - Submit versions of iTIP and iMIP that address known
> interoprability issues.
> Jul 06 - Submit version of iCalendar draft that addresses WG open 
> discussions.
> Sep 06 - Submit version of iCalendar draft ready for WG last call.
> Nov 06 - Complete WG last call of iCalendar and submit new draft.
> Nov 06 - Submit versions of iTIP and iMIP ready for last call.
> Jan 07 - Submit iCalendar (bis) to IESG for Draft Standard.
> Jan 07 - Complete WG last call of iTIP
> Feb 07 - Complete WG last call of iMIP
> Mar 07 - Submit iTIP to IESG for Draft Standard.
> Apr 07 - Submit iMIP to IESG for Draft Standard.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4275 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050629/4cfe609b/attachment.bin

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Date: Wed, 29 Jun 2005 11:43:22 -0700
Subject: [Ietf-calsify] Fwd: WG Review: Calendaring and Scheduling Standards Simplification (calsify) 

--Apple-Mail-4-29481670
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

FYI

Begin forwarded message:

> From: IESG Secretary <[email-masked]>
> Date: June 29, 2005 11:42:13 AM PDT
> To: [email-masked]
> Cc: Subject: WG Review: Calendaring and Scheduling Standards 
> Simplification  (calsify)
>
> A new IETF working group has been proposed in the Applications Area. 
> The IESG
> has not made any determination as yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please 
> send your
> comments to the IESG mailing list ([email-masked]) by July 6th.
>
> +++
>
> Calendaring and Scheduling Standards Simplification (calsify)
> -------------------------------------------------------------
>
> Current Status: Proposed Working Group
>
> Chair(s):
> TBD
>
> Applications Area Director(s):
> Ted Hardie <[email-masked]>
> Scott Hollenbeck <[email-masked]>
>
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: 
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/
>
> Description of Working Group:
>
> The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, 
> and
> 2447 were released in November 1998, and further described in RFC 3283.
> They were designed to progress the level of interoperability between
> dissimilar calendaring and scheduling systems. The Calendaring and
> Scheduling Core Object Specification, iCalendar, succeeded in 
> establishing
> itself as the common format for exchanging calendaring information 
> across
> the Internet. On the other hand, only basic interoperability as been 
> achieved
> between different scheduling systems.
>
> The Calsify working group is chartered to:
>
> (1) Publish the interoperability issues that have arisen between
> calendaring and scheduling systems, as well as document the usage of
> iCalendar by other specifications.
>
> (2) Revise the Calendaring and Scheduling standards to advance the
> state of interoperable calendaring and scheduling by addressing
> the published interoperability issues. As far as it is possible, the
> working group will ensure backwards compatibility with widely deployed
> implementations and other specifications that use it.
>
> (3) Clarify the registration process for iCalendar extensions (i.e.,
> the current core object specification only provides a template
> to register new properties).
>
> (4) Advance the Calendaring and Scheduling standards to Draft Standard.
>
> (5) Work on transition (upgrade or versioning) mechanisms for calendar
> data exchange.
>
> Proposing an XML representation or transformation of iCalendar
> objects is out of the scope of this working group.
>
> Goals and Milestones:
>
> Jul 05 - Submit draft documenting interoperability issues for use in
> progressing RFCs to Draft Standard.
> Sep 05 - Submit iCalendar bis draft 00, with formatting changes from 
> RFC2445.
> Sep 05 - Submit iTIP bis draft 00
> Sep 05 - Submit iMIP bis draft 00
> Oct 05 - Submit revised interoperability issues draft version based on 
> WG
> discussion.
> Dec 05 - WG decision on what document(s) require transition mechanisms 
> and
> hopefully rough idea what these will look like (and add new goals if 
> needed)
> Mar 06 - WG last call on interoperability issues draft.
> May 06 - Submit interoperability issues document to IESG for 
> Informational RFC.
> May 06 - Submit version of iCalendar bis draft that addresses known
> interoperability issues from interop events.
> Jun 06 - Submit versions of iTIP and iMIP that address known
> interoprability issues.
> Jul 06 - Submit version of iCalendar draft that addresses WG open 
> discussions.
> Sep 06 - Submit version of iCalendar draft ready for WG last call.
> Nov 06 - Complete WG last call of iCalendar and submit new draft.
> Nov 06 - Submit versions of iTIP and iMIP ready for last call.
> Jan 07 - Submit iCalendar (bis) to IESG for Draft Standard.
> Jan 07 - Complete WG last call of iTIP
> Feb 07 - Complete WG last call of iMIP
> Mar 07 - Submit iTIP to IESG for Draft Standard.
> Apr 07 - Submit iMIP to IESG for Draft Standard.

--Apple-Mail-4-29481670
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

FYI

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>IESG Secretary <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>June
29, 2005 11:42:13 AM PDT

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Cc: Subject: </color>WG
Review: Calendaring and Scheduling Standards Simplification  (calsify) 

</bold>

A new IETF working group has been proposed in the Applications Area.
The IESG

has not made any determination as yet. The following draft charter was

submitted, and is provided for informational purposes only. Please
send your

comments to the IESG mailing list ([email-masked]) by July 6th.

+++

Calendaring and Scheduling Standards Simplification (calsify)

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

Current Status: Proposed Working Group

Chair(s):

TBD

Applications Area Director(s):

Ted Hardie <<[email-masked]>

Scott Hollenbeck <<[email-masked]>

Mailing Lists:

General Discussion: [email-masked]

To Subscribe:
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/

Description of Working Group:

The Calendaring and Scheduling standards, defined in RFC's 2445, 2446,
and

2447 were released in November 1998, and further described in RFC 3283.

They were designed to progress the level of interoperability between

dissimilar calendaring and scheduling systems. The Calendaring and

Scheduling Core Object Specification, iCalendar, succeeded in
establishing

itself as the common format for exchanging calendaring information
across

the Internet. On the other hand, only basic interoperability as been
achieved

between different scheduling systems.

The Calsify working group is chartered to:

(1) Publish the interoperability issues that have arisen between

calendaring and scheduling systems, as well as document the usage of

iCalendar by other specifications.

(2) Revise the Calendaring and Scheduling standards to advance the

state of interoperable calendaring and scheduling by addressing

the published interoperability issues. As far as it is possible, the

working group will ensure backwards compatibility with widely deployed

implementations and other specifications that use it.

(3) Clarify the registration process for iCalendar extensions (i.e.,

the current core object specification only provides a template

to register new properties).

(4) Advance the Calendaring and Scheduling standards to Draft Standard.

(5) Work on transition (upgrade or versioning) mechanisms for calendar

data exchange.

Proposing an XML representation or transformation of iCalendar

objects is out of the scope of this working group.

Goals and Milestones:

Jul 05 - Submit draft documenting interoperability issues for use in

progressing RFCs to Draft Standard.

Sep 05 - Submit iCalendar bis draft 00, with formatting changes from
RFC2445.

Sep 05 - Submit iTIP bis draft 00

Sep 05 - Submit iMIP bis draft 00

Oct 05 - Submit revised interoperability issues draft version based on
WG

discussion.

Dec 05 - WG decision on what document(s) require transition mechanisms
and

hopefully rough idea what these will look like (and add new goals if
needed)

Mar 06 - WG last call on interoperability issues draft.

May 06 - Submit interoperability issues document to IESG for
Informational RFC.

May 06 - Submit version of iCalendar bis draft that addresses known

interoperability issues from interop events.

Jun 06 - Submit versions of iTIP and iMIP that address known

interoprability issues.

Jul 06 - Submit version of iCalendar draft that addresses WG open
discussions.

Sep 06 - Submit version of iCalendar draft ready for WG last call.

Nov 06 - Complete WG last call of iCalendar and submit new draft.

Nov 06 - Submit versions of iTIP and iMIP ready for last call.

Jan 07 - Submit iCalendar (bis) to IESG for Draft Standard.

Jan 07 - Complete WG last call of iTIP

Feb 07 - Complete WG last call of iMIP

Mar 07 - Submit iTIP to IESG for Draft Standard.

Apr 07 - Submit iMIP to IESG for Draft Standard. 

</excerpt>
--Apple-Mail-4-29481670--

To: [email-masked]
From: Lisa Dusseault <[email-masked]>
Date: Thu, 23 Jun 2005 13:05:24 -0700
Subject: [Ietf-calsify] Planning for Paris

I went ahead and asked for a slot for CALSIFY at the next IETF in 
Paris, Aug 1-5.  At the same time, the IESG is also reviewing our 
charter proposal, so we may even meet as an approved WG by then.

I'll start working on the meeting agenda shortly...

Lisa

Date: Tue, 21 Jun 2005 12:14:02 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: [email-masked]
Subject: Re: [Ietf-calsify] email alarms + description
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms050806020405050305040107
Content-Type: multipart/mixed; boundary="------------090703030100030504030303"

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

So you are saying that if the VALARM SUMMARY and DESCRIPTION are not
provided, then default to the VEVENT values?

Interesting idea, not compatible with 2445.

If you send them now with those properties missing,
no one can read them at all. So it seems to be a bit
more wasteful to send alarms that everyone tosses.

If your talking about storage, that's up to your store. iCal
is a calendar exchange protocol, not a file store. If you give
direct access to the file store as an ICS file, then you would
need to be compatible with the readers of that data.

If your ICS files are in fact dynamically generated data
that looks like an ICS file, then you can generate 2445
VALARMs at run time and do not need to store the SUMMARY
and DESCRIPTION separately.

Mike Douglass wrote:
> RFC 2445 states (4.6.6) that the description property is required for an 
> email alarm and will be used for the message body.
> 
> I'd prefer to see this as an optional property.
> 
> I'm implementing automatic mailing of (public) events to subscribed 
> users and I'll probably do so by setting alarms on the events.
> 
> An appropriate message body is probably a displayable form of the event, 
> with the actual event as an ics attachment.
> 
> I could populate all the alarm objects with the text form of the event 
> but that's a bit wasteful. In any case I'd like the user to be able to 
> signify the default mode by just leaving out the property.
> 
> The same could be said of the alarm summary. By default I'd fill it with 
> the event summary.
> 

-- 

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

               We Do Standards - You Need Standards

--------------090703030100030504030303
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-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------090703030100030504030303--

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

--------------ms050806020405050305040107--

Date: Tue, 21 Jun 2005 11:37:17 -0400
From: Mike Douglass <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] email alarms + description

RFC 2445 states (4.6.6) that the description property is required for an 
email alarm and will be used for the message body.

I'd prefer to see this as an optional property.

I'm implementing automatic mailing of (public) events to subscribed 
users and I'll probably do so by setting alarms on the events.

An appropriate message body is probably a displayable form of the event, 
with the actual event as an ics attachment.

I could populate all the alarm objects with the text form of the event 
but that's a bit wasteful. In any case I'd like the user to be able to 
signify the default mode by just leaving out the property.

The same could be said of the alarm summary. By default I'd fill it with 
the event summary.

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

Date: Sun, 19 Jun 2005 22:04:17 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] iCal-Basic -03 has been submitted.
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms070902040900000606030609
Content-Type: multipart/mixed; boundary="------------010206070708090304060603"

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

http://inet-consulting.com/draft-royer-ical-basic-03.xml

Tim Hare wrote:
> Doug, is there anywhere I can find the XML versions of these and the RFCs?
> 
> Thanks
> 
> At 11:45 PM 6/18/2005, you wrote:
> 
>> I made the changes to DURATION that was discussed on the CALSIFY mailing
>> list and submitted them to the IETF. The changes are in :
>>
>>         4.3.6  Duration
>>         4.10.3  Recurrence Date/Times
>>
>>
>> Copies at:
>>
>>         http://inet-consulting.com/draft-royer-ical-basic-03.txt
>>
>>         http://inet-consulting.com/draft-royer-ical-basic-03.html
>>
>> -- 
>>
>> Doug Royer                     | http://INET-Consulting.com
>> -------------------------------|-----------------------------
>>
>>               We Do Standards - You Need Standards
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
> 
> Tim Hare
> Interested Bystander, Non-Inc.
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-- 

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

               We Do Standards - You Need Standards

--------------010206070708090304060603
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-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------010206070708090304060603--

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

--------------ms070902040900000606030609--

Date: Sun, 19 Jun 2005 23:04:20 -0400
To: Calsify <[email-masked]>
From: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] iCal-Basic -03 has been submitted.

Doug, is there anywhere I can find the XML versions of these and the RFCs?

Thanks

At 11:45 PM 6/18/2005, you wrote:

>I made the changes to DURATION that was discussed on the CALSIFY mailing
>list and submitted them to the IETF. The changes are in :
>
>         4.3.6  Duration
>         4.10.3  Recurrence Date/Times
>
>
>Copies at:
>
>         http://inet-consulting.com/draft-royer-ical-basic-03.txt
>
>         http://inet-consulting.com/draft-royer-ical-basic-03.html
>
>--
>
>Doug Royer                     | http://INET-Consulting.com
>-------------------------------|-----------------------------
>
>               We Do Standards - You Need Standards
>
>
>
>
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc. 

Date: Sun, 19 Jun 2005 13:43:22 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] VERSION value in iCal-Basic
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms090905070107020009080302
Content-Type: multipart/mixed; boundary="------------010105050204070800000606"

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

After looking into it, Mozilla uses libical.
So  filed bug:

	https://bugzilla.mozilla.org/show_bug.cgi?id=298177

Reinhold Kainhofer wrote:
> Am Sonntag, 19. Juni 2005 06:10 schrieb Doug Royer:
> 
>>It is by belief that iCal-Basic is compatible to implementations.
>>That is the changes are clarifying existing components, properties,
>>and parameters and reduces the number of them.
>>
>>I believe that it is possible for an RFC-2445 implementation
>>to have generated an iCal-Basic object (except new properties
>>which it would ignore per 2445).
>>
>>So, I am proposing that iCal-Basic have a VERSION value
>>of:
>>
>>	VERSION:2.0;2.1
>>
>>Specifying that it is newer (2.1) and can be read by existing (2.0)
>>parsers and implementations.
>>
>>There is no change to the 2445 VERSION property needed to support this
>>value. The existing 2445 VERSION property supports a range
>>of VERSION property values.
> 
> 
> And since calsify is about using only what is supported by most 
> implementations: How many implementations actually support this range?  My 
> guess is approximately 0. 
> I wonder how implementations behave when they encounter such a VERSION? If 
> they accept it and parse it, then fine. But I suspect that there are 
> implementations out there that compare the version string with "2.0" and 
> produce an error message otherwise. This should not happen, of course.
> 
> At least libkcal (KDE's calendar library including support for iCalendar) 
> fails with such a VERSION...
> Mozilla calendar seems to ignore the VERSION altogether (but hangs while 
> importing such a file, no idea what's the exact reason).
> And Evolution also ignores the VERSION completely (i.e. if the version is 
> "4.0", evolution also imports it just fine... Which it shouldn't, I guess?)
> 
> So far, there was no other calendar version that tried to be compatible with 
> 2445, so this was a working approach, but with calsify things change...
> 
> Reinhold
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-- 

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

               We Do Standards - You Need Standards

--------------010105050204070800000606
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-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------010105050204070800000606--

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

--------------ms090905070107020009080302--

Date: Sun, 19 Jun 2005 13:25:39 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] VERSION value in iCal-Basic
X-INET-Consulting.com-MailScanner-Information: Please contact [email-masked] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms080002030909050103030701
Content-Type: multipart/mixed; boundary="------------030906020406010504020507"

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

Reinhold Kainhofer wrote:
> Am Sonntag, 19. Juni 2005 06:10 schrieb Doug Royer:
> 
>>It is by belief that iCal-Basic is compatible to implementations.
>>That is the changes are clarifying existing components, properties,
>>and parameters and reduces the number of them.
>>
>>I believe that it is possible for an RFC-2445 implementation
>>to have generated an iCal-Basic object (except new properties
>>which it would ignore per 2445).
>>
>>So, I am proposing that iCal-Basic have a VERSION value
>>of:
>>
>>	VERSION:2.0;2.1
>>
>>Specifying that it is newer (2.1) and can be read by existing (2.0)
>>parsers and implementations.
>>
>>There is no change to the 2445 VERSION property needed to support this
>>value. The existing 2445 VERSION property supports a range
>>of VERSION property values.
> 
> 
> And since calsify is about using only what is supported by most 
> implementations: How many implementations actually support this range?  My 
> guess is approximately 0. 

By 'this range', do you mean the one that I am proposing as a new one?

> I wonder how implementations behave when they encounter such a VERSION? If 
> they accept it and parse it, then fine. But I suspect that there are 
> implementations out there that compare the version string with "2.0" and 
> produce an error message otherwise. This should not happen, of course.

I do not think we have a choice. Mandating that we never use all of
the VERSION property value types simply because some did not do it
correctly will keep iCal from never being fixed.

For those that ignore it, it will not matter ether way.

For those that look at it and do not support CALSIFY,
it should not matter as they also support 2.0.

For those that support CALSIFY, they now know what to expect.

For those that crash or hang - well that was going to happen at
some point anyway in recent time as that was the entire purpose
of VERSION is to allow content type version control.

> At least libkcal (KDE's calendar library including support for iCalendar) 
> fails with such a VERSION...

Libical is open source so that is easy to fix.

> Mozilla calendar seems to ignore the VERSION altogether (but hangs while 
> importing such a file, no idea what's the exact reason).
> And Evolution also ignores the VERSION completely (i.e. if the version is 
> "4.0", evolution also imports it just fine... Which it shouldn't, I guess?)

I follow the Mozilla development. It will also be an easy fix.

> So far, there was no other calendar version that tried to be compatible with 
> 2445, so this was a working approach, but with calsify things change...

I think we agree. We need to start fixing things so that we have more
compatibility.

-- 

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

               We Do Standards - You Need Standards

--------------030906020406010504020507
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-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------030906020406010504020507--

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

--------------ms080002030909050103030701--

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: Calsify <[email-masked]>
Subject: Re: [Ietf-calsify] VERSION value in iCal-Basic
Date: Sun, 19 Jun 2005 10:55:10 +0200

--nextPart1232180.0HxSt6qklI
Content-Type: text/plain;
  charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Sonntag, 19. Juni 2005 06:10 schrieb Doug Royer:
> It is by belief that iCal-Basic is compatible to implementations.
> That is the changes are clarifying existing components, properties,
> and parameters and reduces the number of them.
>
> I believe that it is possible for an RFC-2445 implementation
> to have generated an iCal-Basic object (except new properties
> which it would ignore per 2445).
>
> So, I am proposing that iCal-Basic have a VERSION value
> of:
>
> 	VERSION:2.0;2.1
>
> Specifying that it is newer (2.1) and can be read by existing (2.0)
> parsers and implementations.
>
> There is no change to the 2445 VERSION property needed to support this
> value. The existing 2445 VERSION property supports a range
> of VERSION property values.

And since calsify is about using only what is supported by most=20
implementations: How many implementations actually support this range?  My=
=20
guess is approximately 0.=20
I wonder how implementations behave when they encounter such a VERSION? If=
=20
they accept it and parse it, then fine. But I suspect that there are=20
implementations out there that compare the version string with "2.0" and=20
produce an error message otherwise. This should not happen, of course.

At least libkcal (KDE's calendar library including support for iCalendar)=20
fails with such a VERSION...
Mozilla calendar seems to ignore the VERSION altogether (but hangs while=20
importing such a file, no idea what's the exact reason).
And Evolution also ignores the VERSION completely (i.e. if the version is=20
"4.0", evolution also imports it just fine... Which it shouldn't, I guess?)

So far, there was no other calendar version that tried to be compatible wit=
h=20
2445, so this was a working approach, but with calsify things change...

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

--nextPart1232180.0HxSt6qklI
Content-Type: application/pgp-signature

--nextPart1232180.0HxSt6qklI--

Date: Sat, 18 Jun 2005 22:10:51 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[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-calsify] VERSION value in iCal-Basic
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms080308070602060401060801
Content-Type: multipart/mixed; boundary="------------000203020602070503030005"

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

It is by belief that iCal-Basic is compatible to implementations.
That is the changes are clarifying existing components, properties,
and parameters and reduces the number of them.

I believe that it is possible for an RFC-2445 implementation
to have generated an iCal-Basic object (except new properties
which it would ignore per 2445).

So, I am proposing that iCal-Basic have a VERSION value
of:

	VERSION:2.0;2.1

Specifying that it is newer (2.1) and can be read by existing (2.0)
parsers and implementations.

There is no change to the 2445 VERSION property needed to support this
value. The existing 2445 VERSION property supports a range
of VERSION property values.

-- 

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

               We Do Standards - You Need Standards

--------------000203020602070503030005
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-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------000203020602070503030005--

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

--------------ms080308070602060401060801--

Date: Sat, 18 Jun 2005 21:45:26 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[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-calsify] iCal-Basic -03 has been submitted.
Reply-To: Calsify <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms070302070609070408020401
Content-Type: multipart/mixed; boundary="------------010309030709060400020605"

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

I made the changes to DURATION that was discussed on the CALSIFY mailing
list and submitted them to the IETF. The changes are in :

	4.3.6  Duration
	4.10.3  Recurrence Date/Times

Copies at:

	http://inet-consulting.com/draft-royer-ical-basic-03.txt

	http://inet-consulting.com/draft-royer-ical-basic-03.html

-- 

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

               We Do Standards - You Need Standards

--------------010309030709060400020605
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-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard

--------------010309030709060400020605--

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

--------------ms070302070609070408020401--

Date: Mon, 13 Jun 2005 11:46:10 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-calsify list <[email-masked]>
Subject: [Ietf-calsify] Reminder -- Questionnaire on Implementation of Timezones -- Calconnect and Calsify
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">
<pre wrap="">Dear Folks,

This is a followup reminder to my e-mail of May 24th requesting assistance in responding to a Calconnect questionnaire on Timezones.  Our original target date for responses was June 10th. We're received several responses but hope that with a little more time others will be able to help us.  If you've not responded but have a calendaring implementation, we would appreciate it very much if you could take a few minutes to respond to our questionnaire.

We've extended the target date another week to Monday, June 20th -- and so you don't have to rummage around and find my previous e-mail, the questionniare (which is in e-mail format so you can fill it out and e-mail it back) is included below.

Thank you very much for your help.

Dave Thewlis
---
<b>Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium</b>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)
<a href="http://www.calconnect.org%3E">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>

------------------------------------------------------------------------------------------
Questionnaire on Timezones in iCalendar

Introduction:

This questionnaire is being used to determine support for iCalendar
(RFC2445) timezone support. The specific sections in RFC2445 that
are being queried are:

4.6.5       Time Zone Component
4.8.2.4     Date/Time Start
4.8.3       Time Zone Component Properties
     ( and sub-sections )
4.8.5.3     Recurrence Date/Times
4.8.5.4     Recurrence Rule
4.8.7.3     Last Modified
4.8.8.1     Non-standard Properties

These may involve reference to other sections.

How to answer:

Please copy the text from the '-------' divider below to the end of
this message into a new message and address it to:

    <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;mailto:[email-masked]&gt;</a>

To fill it out:

For 'y/n/o':

    'y' means yes
    'n' means no
    'o' means other or not applicable

    Delete two letters to leave the one for your answer.
    If you have specific comments you can add about your answers,
    please do so at the end and reference the question number to which
    the comment applies.
    
For _____________________: enter text for the answer.

-------

Product Details:

P1:		Product/Implementation Name:
        
        _____________________

Components supported:

                                   Consume         Produce
Q1:     VTIMEZONE                   y/n/o           y/n/o
Q1.1:   STANDARD                    y/n/o           y/n/o
Q1.2:   DAYLIGHT                    y/n/o           y/n/o

Properties supported:
                                
        In VTIMEZONE
                                   Consume         Produce
Q2.1:   TZID                        y/n/o           y/n/o
Q2.2:   LAST-MODIFIED               y/n/o           y/n/o
Q2.3:   TZURL                       y/n/o           y/n/o
Q2.4:   XPROP                       y/n/o           y/n/o

        In STANDARD
                                   Consume         Produce
Q3.1:   DTSTART                     y/n/o           y/n/o
Q3.2:   TZOFFSETTO                  y/n/o           y/n/o
Q3.3:   TZOFFSETFROM                y/n/o           y/n/o
Q3.4:   COMMENT                     y/n/o           y/n/o
Q3.5:   RDATE                       y/n/o           y/n/o
Q3.6:   RRULE                       y/n/o           y/n/o
Q3.7:   TZNAME                      y/n/o           y/n/o
Q3.8:   XPROP                       y/n/o           y/n/o

        In DAYLIGHT
                                   Consume         Produce
Q4.1:   DTSTART                     y/n/o           y/n/o
Q4.2:   TZOFFSETTO                  y/n/o           y/n/o
Q4.3:   TZOFFSETFROM                y/n/o           y/n/o
Q4.4:   COMMENT                     y/n/o           y/n/o
Q4.5:   RDATE                       y/n/o           y/n/o
Q4.6:   RRULE                       y/n/o           y/n/o
Q4.7:   TZNAME                      y/n/o           y/n/o
Q4.8:   XPROP                       y/n/o           y/n/o

General:
    
Q5:  Do you always send DATE-TIME
     values with a timezone?         y/n/o

Q6:  Do you always send DATE-TIME
     values in UTC or floating?      y/n/o

Q7:  Do you provide a standard
     set of timezones built-in
     to your product?                y/n/o

     if yes to Q7, then
     {
Q8:     Where did you get your
        timezone definitions?
        
        _____________________
        
Q9:     How many timezone
        definitions do you have?
        
        _____________________
        
Q10:    Do you have a special
        naming scheme for TZIDs,
        and if so what is it?
        
        _____________________
        
Q11:    Do you provide a mechanism
        for updating built-in
        timezones?                  y/n/o
        
        if yes to Q11, then
        {
Q12:        Do you adjust future
            times to account for
            timezone definition
            changes?                y/n/o
        }

     }
    
Q13: Do you accept and use
     timezone definitions from
     imported iCalendar data?       y/n/o

     if yes to Q13, then
     {   
Q14:    Do you attempt to merge
        timezone definitions with the
        same TZID when importing
        iCalendar data?             y/n/o
     }
    
Q15: When exporting timezones in
     iCalendar data (either to a file
     or via iTIP) do you send the entire
     timezone definition or just the
     set of dates needed for coverage
     of the event?

     _____________________
    
Q16: Would you use timezone
     definitions from a standard
     timezone registry if one
     were created?                   y/n/o
    
Q17: What problems would be
     involved in changing a
     timezone definition if DST
     was changed at some point
     in the future?
    
     _____________________

C1:  Comments on specific answers (include Q number for cross-reference
     to original question):

     _____________________

C2:  Comments on the format and ease of use of this questionnaire:

     _____________________

C3:  Are there any additional questions we should be asking, and if
     so what are they?

     _____________________

</pre>
<br>
<div class="moz-signature"><br>
</div>
</body>
</html>

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Date: Wed, 1 Jun 2005 17:34:08 +0200
Subject: [Ietf-calsify] Questions regarding details of recurrence rules

Hi Guys,

I already sent this to ietf-calendar, but didn't get any definitive response 
so far. It may be a bit off-topic here, but I'm still hoping for an answer 
that helps me getting RFC 2445-RRULEs completely correct. For the most part, 
the RFC is clear to me, but there are some details that are not clear. I 
encountered them when I tested my new recurrence implementation which tries 
to implement every aspect of rrules, exrules, rdates and exdates.

The examples below sometimes might look like nitpicking, but I deliberately 
designed them to make little details of the RFC clear.

These issues might be a language problem on my side, or an unclear wording in 
the RFC. In any case, I'd like to know how the RFC really meant those things 
to work. 

1) About the BYDAY rule part: Let's start with some examples
  RRULE:FREQ=YEARLY;BYDAY=3SU
Okay, that's the third sunday of the year. But what exactly is
  RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2
Is this the fith sunday in the year, if it is also in february? Or is it the
fifth sunday in february? And it can be even less clear from rfc 2445. What
is
  RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2,7
Is this the fifth sunday of the year, if it's in either February or July?
Or is it the fifth sunday of both february and July?
Or is it the fifth sunday of febrary and july together (i.e. in feb if the
 feb in a leap year has 5 sundays, or the first sunday of july in all other
 years)?

If you think it's the latter, think about the following rule:
  RRULE:FREQ=YEARLY;BYWEEKNO=4;BYDAY=5SU
Is it the fifth sunday of all sundays that are in week #4? Or is it the fifth
sunday of the year if it is also in week #4?

Also, what does this rule mean:
  RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU;BYYEARDAY=72
I suppose it doesn't mean the 72th day of the year, if that's the 2nd sunday
in March (or in the year, using a different interpretation).

Also notice that rfc 2445 says "For example, within
   a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday
   within the month, whereas -1MO represents the last Monday of the
   month. ". So what does
  RRULE:FREQ=MONTHLY;BYYEARDAY=57,64;BYDAY=-1MO
mean? The last monday of each month if it's also day #57 or #64 of the year
(which the quote implies), or the last monday each month in the set of all
days #57 and #64 of the year. In particular, in 2007, would the recurrence
set be Feb 27 (=#57 of the year, and the last monday in february) without any
occurence in march (march 5 is day #64, but it's not the last monday in the
month, since rfc 2445 says -1MO means last monday of the month)? Or would it
be Feb 27 (day #57 of the year, and last monday of all dates that match the
BYYEARDAY in the february interval) and March 4 ( day #64 of the year and
last monday of all dates in March that match the BYYEARDAY).

2) In Section 4.3.10 RFC 2445 says "The COUNT rule part defines the number of
occurrences at which to range-bound the recurrence. The "DTSTART" property
value, if specified, counts as the first occurrence.". So look at this rrule:
DTSTART;TZID=whatever:20050530T120000
RRULE:FREQ=WEEKLY;COUNT=3;BYMONTH=6
The resulting recurrence dates would be
  1) 20050530
  2) 20050630
  3) 20060630

Now if the DTSTART is not specified the quote from above would imply that the
start doesn't count as a recurrence, so looking at
DTEND;TZID=whatever:20050530T150000
DURATION:PT3H
RRULE:FREQ=WEEKLY;COUNT=3;BYMONTH=6
would give the following resulting recurrence dates?
  1) 20050530 (DTSTART is always the first occurence, )
  2) 20050630
  3) 20060630
  4) 20070630 (DTSTART doesn't count towards COUNT)

If it's not meant that way, and an implicit value of DTSTART is also used for 
the count, why does RFC 2445 include the half sentence "if specified"? If 
some incidence doesn't even haven an implicit value of DTSTART, an RRULE 
doesn't make any sense at all.

3) About the DTSTART and recurrence rules: Is the DTSTART always taken to
match the rule (even if it doesn't fulfil the BY* parts)? In particular this
is important for EXRULES: Is the DTSTART always the first occurence of the
EXRULE? If that's the case, the DTSTART will always be excluded as soon as at
least one EXRULE is present.
And since exceptions overrule inclusions, there's no way to have an occurence
on the DTSTART in that case... Is this really the intended behaviour?

Thanks a lot already for your clarifications / discussions.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer