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

[lisa at osafoundation.org (Lisa Dusseault)]

FYI

Begin forwarded message:

> From: IESG Secretary <[e-mail]>
> Date: June 29, 2005 11:42:13 AM PDT
> To: [e-mail]
> 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 ([e-mail]) by July 6th.
>
> +++
>
> Calendaring and Scheduling Standards Simplification (calsify)
> -------------------------------------------------------------
>
> Current Status: Proposed Working Group
>
> Chair(s):
> TBD
>
> Applications Area Director(s):
> Ted Hardie <[e-mail]>
> Scott Hollenbeck <[e-mail]>
>
> Mailing Lists:
> General Discussion: [e-mail]
> 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

Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0D0457F545 for <[e-mail]>; Wed, 29 Jun 2005 11:43:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 65B40142284 for <[e-mail]>; Wed, 29 Jun 2005 11:43:25 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12576-06 for <[e-mail]>; Wed, 29 Jun 2005 11:43:24 -0700 (PDT)
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id CF932142280 for <[e-mail]>; Wed, 29 Jun 2005 11:43:24 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v622)
To: [e-mail]
Message-Id: <[e-mail]>
Content-Type: multipart/alternative; boundary=Apple-Mail-4-29481670
From: Lisa Dusseault <[e-mail]>
Date: Wed, 29 Jun 2005 11:43:22 -0700
X-Mailer: Apple Mail (2.622)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00
X-Spam-Level: 
Subject: [Ietf-calsify] Fwd: WG Review: Calendaring and Scheduling Standards Simplification (calsify) 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2005 18:43:21 -0000

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

FYI

Begin forwarded message:

> From: IESG Secretary <[e-mail]>
> Date: June 29, 2005 11:42:13 AM PDT
> To: [e-mail]
> 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 ([e-mail]) by July 6th.
>
> +++
>
> Calendaring and Scheduling Standards Simplification (calsify)
> -------------------------------------------------------------
>
> Current Status: Proposed Working Group
>
> Chair(s):
> TBD
>
> Applications Area Director(s):
> Ted Hardie <[e-mail]>
> Scott Hollenbeck <[e-mail]>
>
> Mailing Lists:
> General Discussion: [e-mail]
> 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 <<[e-mail]>

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

<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 ([e-mail]) by July 6th.


+++


Calendaring and Scheduling Standards Simplification (calsify)

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


Current Status: Proposed Working Group


Chair(s):

TBD


Applications Area Director(s):

Ted Hardie <<[e-mail]>

Scott Hollenbeck <<[e-mail]>


Mailing Lists:

General Discussion: [e-mail]

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9D3227F55C for <[e-mail]>; Fri, 24 Jun 2005 13:05:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id DAA6614225D for <[e-mail]>; Thu, 23 Jun 2005 13:05:48 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17431-04 for <[e-mail]>; Thu, 23 Jun 2005 13:05:48 -0700 (PDT)
Received: from [192.168.101.178] (w002.z065106067.sjc-ca.dsl.cnc.net [65.106.67.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id AE08D14225C for <[e-mail]>; Thu, 23 Jun 2005 13:05:48 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v622)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: [e-mail]
From: Lisa Dusseault <[e-mail]>
Date: Thu, 23 Jun 2005 13:05:24 -0700
X-Mailer: Apple Mail (2.622)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00
X-Spam-Level: 
Subject: [Ietf-calsify] Planning for Paris
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2005 20:05:50 -0000

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



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id A02157F547 for <[e-mail]>; Tue, 21 Jun 2005 13:29:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 2211E14228A for <[e-mail]>; Tue, 21 Jun 2005 13:29:25 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10524-02 for <[e-mail]>; Tue, 21 Jun 2005 13:29:24 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 01E3314226D for <[e-mail]>; Tue, 21 Jun 2005 13:29:23 -0700 (PDT)
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j5LIE2ZA023616 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Tue, 21 Jun 2005 11:14:05 -0700
Message-ID: <[e-mail]>
Date: Tue, 21 Jun 2005 12:14:02 -0600
From: Doug Royer <[e-mail]>
Organization: IntelliCal.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: [Ietf-calsify] email alarms + description
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050806020405050305040107"
Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism)
X-INET-Consulting.com-MailScanner-Information: Please contact [e-mail] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2005 20:29:56 -0000

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:[e-mail]
title:CEO
tel;work:208-881-0380
tel;fax:[phone]
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [e-mail]=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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDUwNjIxMTgxNDAyWjAjBgkqhkiG9w0BCQQxFgQUAqHonYotpsjBvrXvZw+Z
/wcn+GowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAkEgOQv+9yY+1gIYRlOpodxRPcF2IrsOKPwA3YWiZcnJ0JTZhgg+CTUB6YqSCFX2V
di8VQ52dNEZm9aJwTcuTK7gQw2UcV/+sISpLhlMl59j3aG7uFu/i6WBrPBDmbsnzqZxvOC0p
hdnEbArJY65s4nyh8JlH7RTnD3YaE5N3QkFZCmBMx5Sq3mhqYlvfwSPmGZSzH3hK9YZKU3Ry
JJ8CtZa8IOr6gd3VkrpkYSIhfSp7hivEOXDpOF2eVrCbeR0thJxExCZt5dBrS5a4iS9Pw+5g
m0EU8hPTqjpxPK8VMOhHUKgZ3kTb3swv6nfbPJwlZcv98dx5cJFVzpjLID5EbwAAAAAAAA==
--------------ms050806020405050305040107--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 227E67F597 for <[e-mail]>; Tue, 21 Jun 2005 08:34:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id D5D2714225C for <[e-mail]>; Tue, 21 Jun 2005 08:33:35 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05780-03 for <[e-mail]>; Tue, 21 Jun 2005 08:33:35 -0700 (PDT)
Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 7E53A14223D for <[e-mail]>; Tue, 21 Jun 2005 08:33:35 -0700 (PDT)
Received: from [128.113.124.215] (blue-eyes-white-dragon-07.dynamic2.rpi.edu [128.113.124.215]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j5LFbHVb014619 for <[e-mail]>; Tue, 21 Jun 2005 11:37:17 -0400
Message-ID: <[e-mail]>
Date: Tue, 21 Jun 2005 11:37:17 -0400
From: Mike Douglass <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-CanItPRO-Stream: default
X-RPI-SA-Score: undef - spam-scanning disabled
X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00
X-Spam-Level: 
Subject: [Ietf-calsify] email alarms + description
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Tue, 21 Jun 2005 15:34:07 -0000

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                           [e-mail]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180



Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 1E8B07F56D for <[e-mail]>; Sun, 19 Jun 2005 21:01:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id A16A014226F for <[e-mail]>; Sun, 19 Jun 2005 21:00:56 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18960-10 for <[e-mail]>; Sun, 19 Jun 2005 21:00:56 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 91250142257 for <[e-mail]>; Sun, 19 Jun 2005 21:00:55 -0700 (PDT)
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j5K44HTE014355 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sun, 19 Jun 2005 21:04:19 -0700
Message-ID: <[e-mail]>
Date: Sun, 19 Jun 2005 22:04:17 -0600
From: Doug Royer <[e-mail]>
Organization: IntelliCal.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Calsify <[e-mail]>
Subject: Re: [Ietf-calsify] iCal-Basic -03 has been submitted.
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070902040900000606030609"
Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism)
X-INET-Consulting.com-MailScanner-Information: Please contact [e-mail] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Calsify <[e-mail]>
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 20 Jun 2005 04:01:26 -0000

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
>> [e-mail]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
> 
> Tim Hare
> Interested Bystander, Non-Inc.
> 
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> 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:[e-mail]
title:CEO
tel;work:208-881-0380
tel;fax:[phone]
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [e-mail]=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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDUwNjIwMDQwNDE3WjAjBgkqhkiG9w0BCQQxFgQUakxCcSve2GWrWdqkfu1n
JXtOD8MwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAxNtd5rJjWlrqGbCldZsTbiU5dGwsUMHXig0ovm4f4bRnrIizVjsLunndlSRPK3WG
C2S9LL4o6JSHpBmPD3OYzhgMDkE78bfGccMQRj98vnQui29xD3nIWRawCgfFtdKV9HSxrkN2
bV58pk+GWXffrdwFhVvDh9TgtIppUhmmBPaau/0BiafO3mvw+uqAJIr/yTYd/1tervlk4+yy
i3QCcPsFhxgYYA7oGZ899xpxtHE7KfmqkmnQinqh5jboiJqkwR9OK58CAYzuyKHU57KC62TS
c5c+zf3xePFt56EiFMr5sCxeCVoPhvKoKnqxmlgcASdhSfEMzC1WwGTjYTQx2AAAAAAAAA==
--------------ms070902040900000606030609--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 47DD77F56B for <[e-mail]>; Sun, 19 Jun 2005 20:01:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id D9178142271 for <[e-mail]>; Sun, 19 Jun 2005 20:00:51 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21354-01 for <[e-mail]>; Sun, 19 Jun 2005 20:00:51 -0700 (PDT)
Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by smtp.osafoundation.org (Postfix) with ESMTP id 7CB59142266 for <[e-mail]>; Sun, 19 Jun 2005 20:00:51 -0700 (PDT)
Received: from thare.comcast.net (pcp03614075pcs.micske01.fl.comcast.net[68.84.31.33]) by comcast.net (sccrmhc12) with SMTP id <20050620030419012007dvn6e>; Mon, 20 Jun 2005 03:04:19 +0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Sun, 19 Jun 2005 23:04:20 -0400
To: Calsify <[e-mail]>
From: Tim Hare <[e-mail]>
Subject: Re: [Ietf-calsify] iCal-Basic -03 has been submitted.
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.7 tagged_above=-50.0 required=4.0 tests=BAYES_00
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 20 Jun 2005 03:01:21 -0000

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

Tim Hare
Interested Bystander, Non-Inc. 




Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 410737F56D for <[e-mail]>; Sun, 19 Jun 2005 13:17:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 2F9C4142271 for <[e-mail]>; Sun, 19 Jun 2005 13:17:04 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15129-10 for <[e-mail]>; Sun, 19 Jun 2005 13:17:03 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id E77FE14226F for <[e-mail]>; Sun, 19 Jun 2005 13:17:02 -0700 (PDT)
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j5JJhNik028828 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sun, 19 Jun 2005 12:43:25 -0700
Message-ID: <[e-mail]>
Date: Sun, 19 Jun 2005 13:43:22 -0600
From: Doug Royer <[e-mail]>
Organization: IntelliCal.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Calsify <[e-mail]>
Subject: Re: [Ietf-calsify] VERSION value in iCal-Basic
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090905070107020009080302"
Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism)
X-INET-Consulting.com-MailScanner-Information: Please contact [e-mail] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Calsify <[e-mail]>
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 19 Jun 2005 20:17:33 -0000

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
> [e-mail]
> 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:[e-mail]
title:CEO
tel;work:208-881-0380
tel;fax:[phone]
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [e-mail]=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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDUwNjE5MTk0MzIyWjAjBgkqhkiG9w0BCQQxFgQUufnroVb23CEQNozhgN5x
giZc1mgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAN0Vu1ohUHKbaf+LiFTKDD+MVeO/0h4F4idaCuIKeSnr/zcACjseT8lH2WBnHNLId
56lgMII2TQy7QwSpXwkK189XPLDJ9OdBLf4tsZor+/p0tEG5TnOEZ15DGqUNV8PjQgYJYPzE
X/RgYhtMJx8LnPxkDOs0kTl/woAcdWP6P4slHFJ0erbmqG6gIwXvB4nguEFbtIRQ7xSHHe7H
ymQAAUdq0o5Lk004euWtIik8IsoDcGgiuvdDtf616RKWKA5FJNhfkfFRTjPiUZPrVnnOn8TI
uMJTI7bmXDcGFn/0W+3IcaPKr2Nzy8KZzvKwwTM7BPIzi4/qBEC33NisrsavSAAAAAAAAA==
--------------ms090905070107020009080302--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 034DA7F567 for <[e-mail]>; Sun, 19 Jun 2005 13:17:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id DF800142271 for <[e-mail]>; Sun, 19 Jun 2005 13:16:59 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17769-10 for <[e-mail]>; Sun, 19 Jun 2005 13:16:59 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 9DA2F14226F for <[e-mail]>; Sun, 19 Jun 2005 13:16:58 -0700 (PDT)
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j5JJPe2W028511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sun, 19 Jun 2005 12:25:42 -0700
Message-ID: <[e-mail]>
Date: Sun, 19 Jun 2005 13:25:39 -0600
From: Doug Royer <[e-mail]>
Organization: IntelliCal.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Calsify <[e-mail]>
Subject: Re: [Ietf-calsify] VERSION value in iCal-Basic
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080002030909050103030701"
Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism)
X-INET-Consulting.com-MailScanner-Information: Please contact [e-mail] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Calsify <[e-mail]>
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 19 Jun 2005 20:17:29 -0000

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:[e-mail]
title:CEO
tel;work:208-881-0380
tel;fax:[phone]
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [e-mail]=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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDUwNjE5MTkyNTQwWjAjBgkqhkiG9w0BCQQxFgQUE5hDPuYn+Z6+Bg3kGoT/
JlHQ6QQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAkMHitFBYHeD6sW8mQMdOIf40PqGEt72vTtjIl0bWNUOeXZpiAfRyZI8z6xvwqHDO
wSqGGu+truByQCFpGlCYaIZQ4j+ks9sVLQkBzxnvWiiBzjkaEzTPpmWSETThVbr8T28BWO0A
nR181bYg0as0uUkcUieyH72H+5s7BFWAhfWe+txK9YH+2pPOQaeKp+OCiqWtmiwOtTkJSiUm
aazn6jiz+yKrduhf6602hmk8yn/esiy9FxYtCRuZl2YsRVijgfuyERa+1koK8UQ1pLFOdm6g
qEcOETV5E9NEDKf8osjDOXBEMC9CZruvp0XUw/qLypFKdTzqiNCmOgQTgQzmFwAAAAAAAA==
--------------ms080002030909050103030701--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id E3E607F57F for <[e-mail]>; Sun, 19 Jun 2005 01:52:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 5A7C7142281 for <[e-mail]>; Sun, 19 Jun 2005 01:52:04 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09029-10 for <[e-mail]>; Sun, 19 Jun 2005 01:52:04 -0700 (PDT)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id AACC014227E for <[e-mail]>; Sun, 19 Jun 2005 01:52:03 -0700 (PDT)
Received: from heisenberg (chello062178130194.6.13.tuwien.teleweb.at [62.178.130.194]) (authenticated bits=0) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-3) with ESMTP id j5J8tLGp023049 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <[e-mail]>; Sun, 19 Jun 2005 10:55:23 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: Vienna University of Technology
To: Calsify <[e-mail]>
Subject: Re: [Ietf-calsify] VERSION value in iCal-Basic
Date: Sun, 19 Jun 2005 10:55:10 +0200
User-Agent: KMail/1.8.1
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Face: ")c{Au:m/NOF(f35rjhcBt1!6qS-QGbQ@)W]oPwD`8voekiB@|F0@FgDr"S@=?utf-8?q?=5Bim*un0=5D=3A6=0A=09WH1B=24e675u=7CE/oiWJ=26=23=25?=>=M,iFa%U='hgdU@#oEH`JO8QJ6!29O?M+YO'q6'>=?utf-8?q?=26/Sva=7BkUd=0A=09uq9J13?=)"5^; &~-%==D; W']zE[VP/OuP9l(.$"7cDh\0j2<f)la8Am>}1uNY6HQ:!n)=?utf-8?q?3=5D0j=0A=09drSp?=@(cji7\N<?(YT/~]m\'|SOi,asY<!?uOSj2I*sfMyf; dnv4Hnbq#)=?utf-8?q?W=5Fm53=7Ca=5E7=60=24=5FX=0A=09k=2513=5E4=3AO=27=3Du=7C=7D?=<E9Cm@},g`JDvR2$vX])7{_.\7A+t]qI
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1232180.0HxSt6qklI"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00
X-Spam-Level: 
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 19 Jun 2005 08:52:33 -0000

--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: [e-mail], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain=
er

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBCtTL3TqjEwhXvPN0RAhvrAKCafQ2HEES5pcuCxrZrb7YQf+3rRgCeNjyK
hsYwCnmOTInjhUZ/MAo2tPQ=
=X2tw
-----END PGP SIGNATURE-----

--nextPart1232180.0HxSt6qklI--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 1ED0B7F582 for <[e-mail]>; Sat, 18 Jun 2005 21:08:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id CC7FC142282 for <[e-mail]>; Sat, 18 Jun 2005 21:08:26 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11106-04 for <[e-mail]>; Sat, 18 Jun 2005 21:08:26 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id 8C37814227E for <[e-mail]>; Sat, 18 Jun 2005 21:08:25 -0700 (PDT)
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j5J4BbBS016755 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sat, 18 Jun 2005 21:11:42 -0700
Message-ID: <[e-mail]>
Date: Sat, 18 Jun 2005 22:10:51 -0600
From: Doug Royer <[e-mail]>
Organization: IntelliCal.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Calsify <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080308070602060401060801"
Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism)
X-INET-Consulting.com-MailScanner-Information: Please contact [e-mail] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO
X-Spam-Level: 
Subject: [Ietf-calsify] VERSION value in iCal-Basic
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Calsify <[e-mail]>
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 19 Jun 2005 04:08:55 -0000

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:[e-mail]
title:CEO
tel;work:208-881-0380
tel;fax:[phone]
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [e-mail]=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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDUwNjE5MDQxMDUxWjAjBgkqhkiG9w0BCQQxFgQUEc6bV9XnL2jzKyu8kAxh
VojFpDgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAIYUCvbcZCG62ulfSa2coDJvtRKevmxmuSL8hpd0ETINs/GnMy7QjpjqtX+2LAM9i
lM8GxCCnXHx4pe0k3kD1g/kiJyEJB+k8ZPcyhRHXIDFFAqegop57E+kzSDsFCP5mqJ+D1Lod
HkpPbsk+xwMcoAm2sl02A/MsXOXVbjS/XGT7iUqqrPdTubew3Qk+dJ2t+wzOS590qBRIBYBK
V/AU+VpR971raxlAZJ1Im+/rNP0c4hO3EJpxDR1/+3vVdSSQvrD/DGiie2aWTBnMIsbca+QM
axkMjC/pZSeUo3RSH+Jw0XcuuZEb7fWE0rnWBlnn+LMdiki1zR4XTt2m/PwKNAAAAAAAAA==
--------------ms080308070602060401060801--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 072F57F582 for <[e-mail]>; Sat, 18 Jun 2005 20:42:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id B4EB114227E for <[e-mail]>; Sat, 18 Jun 2005 20:42:13 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08635-10 for <[e-mail]>; Sat, 18 Jun 2005 20:42:13 -0700 (PDT)
Received: from royer.com (inet-consulting.com [4.23.9.166]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id BE744142281 for <[e-mail]>; Sat, 18 Jun 2005 20:42:12 -0700 (PDT)
Received: from [192.168.168.10] (localhost [127.0.0.1]) (authenticated bits=0) by royer.com (8.13.3/8.13.3) with ESMTP id j5J3jQcA016395 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 18 Jun 2005 20:45:28 -0700
Message-ID: <[e-mail]>
Date: Sat, 18 Jun 2005 21:45:26 -0600
From: Doug Royer <[e-mail]>
Organization: IntelliCal.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Calsify <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070302070609070408020401"
Received-SPF: pass (royer.com: 127.0.0.1 is authenticated by a trusted mechanism)
X-INET-Consulting.com-MailScanner-Information: Please contact [e-mail] for more information
X-INET-Consulting.com-MailScanner: Found to be clean
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.4 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO
X-Spam-Level: 
Subject: [Ietf-calsify] iCal-Basic -03 has been submitted.
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Calsify <[e-mail]>
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Sun, 19 Jun 2005 03:42:42 -0000

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:[e-mail]
title:CEO
tel;work:208-881-0380
tel;fax:[phone]
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [e-mail]=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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINcDCC
A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp
YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4
MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv
cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln
biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0
ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv
nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd
trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB
AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w
KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow
KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG
MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk
TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s
MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+
i+P7FTCCBQEwggRqoAMCAQICEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEEBQAwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDQwOTAzMDAw
MDAwWhcNMDUwOTE3MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t
L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL
ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt
IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKRG91ZyBSb3llcjEdMBsGCSqGSIb3
DQEJARYOZG91Z0Byb3llci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
WHYQKNX06SDOZPZvQOVD5lgC2MtnZOR80c1scI1FHqHI0XKABQSTV+mbHKozcPYLI4Lf4Iaa
mL0bbVrINBtKmW5pt5J5dmEVMBlKnuapHyRkznktOqdVnZArTGutzqT97LxXiX+BW3dClNY5
jK4mlvcNFQ43xdn5Ihk4idks99SKWgdqG+t9NoKt8jw21tmvmuOyd/smTlWo0Y6uq+kkkPqY
d+1Y8BvgRtU0RDT5Gl1UkO6TkYBwZUE0mvmHBjy4n9rmahQzFWwe1UaHKYPb8d8xO6qGJNis
RNI3i9T9ZPU+/4gC83jqUZDunMpHobvIo7IHnwQSQL0hKTtVG0TJAgMBAAGjggEcMIIBGDAJ
BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp
Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh
Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwFAYKYIZIAYb4RQEG
BwQGFgROb25lMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2Ns
YXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAtEyTUZBOX3oBnKnjHU79UlsNnkxc9JuPKkM2
6zHybGdD0C7cQ+sali5TCfraIxtRJoZdgWWDQCbZNiQWH9YVXIiZoWW2XzgYFzLmv6+W5w53
CBKKGX1qmPEZY5LOLqZuwXtlIhzZtggUboWrtt7JhyvhlVKvaKpmd3ZPx1J38rgwggUBMIIE
aqADAgECAhBXZjZueFWwQTDzMKYn5XftMA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5W
ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE
CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElB
Qi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1
YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTA0MDkwMzAwMDAwMFoXDTA1MDkx
NzIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5
L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBO
b3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBG
dWxsIFNlcnZpY2UxEzARBgNVBAMUCkRvdWcgUm95ZXIxHTAbBgkqhkiG9w0BCQEWDmRvdWdA
cm95ZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzFh2ECjV9OkgzmT2
b0DlQ+ZYAtjLZ2TkfNHNbHCNRR6hyNFygAUEk1fpmxyqM3D2CyOC3+CGmpi9G21ayDQbSplu
abeSeXZhFTAZSp7mqR8kZM55LTqnVZ2QK0xrrc6k/ey8V4l/gVt3QpTWOYyuJpb3DRUON8XZ
+SIZOInZLPfUiloHahvrfTaCrfI8NtbZr5rjsnf7Jk5VqNGOrqvpJJD6mHftWPAb4EbVNEQ0
+RpdVJDuk5GAcGVBNJr5hwY8uJ/a5moUMxVsHtVGhymD2/HfMTuqhiTYrETSN4vU/WT1Pv+I
AvN46lGQ7pzKR6G7yKOyB58EEkC9ISk7VRtEyQIDAQABo4IBHDCCARgwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMBQGCmCGSAGG+EUBBgcEBhYETm9uZTAz
BgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0G
CSqGSIb3DQEBBAUAA4GBALRMk1GQTl96AZyp4x1O/VJbDZ5MXPSbjypDNusx8mxnQ9Au3EPr
GpYuUwn62iMbUSaGXYFlg0Am2TYkFh/WFVyImaFltl84GBcy5r+vlucOdwgSihl9apjxGWOS
zi6mbsF7ZSIc2bYIFG6Fq7beyYcr4ZVSr2iqZnd2T8dSd/K4MYIEqjCCBKYCAQEwgeEwgcwx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3
b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g
QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu
ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMw
pifld+0wCQYFKw4DAhoFAKCCAp0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMDUwNjE5MDM0NTI2WjAjBgkqhkiG9w0BCQQxFgQUXIbyX3dXSAZjTGWtPTMu
EO0aZv4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgfIGCSsGAQQBgjcQBDGB5DCB
4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0
IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j
b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg
Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQV2Y2bnhV
sEEw8zCmJ+V37TCB9AYLKoZIhvcNAQkQAgsxgeSggeEwgcwxFzAVBgNVBAoTDlZlcmlTaWdu
LCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cu
dmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChj
KTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJl
ci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEFdmNm54VbBBMPMwpifld+0wDQYJKoZIhvcNAQEB
BQAEggEAMyDhT9x/F9i2SFTdxx8v/HDILn4/MHE++3U6HeMn+yXp6vsPiBc/o3/JzGK7YCaM
8K/0q/1aUU5G3KXMHyOb/vLVbsbnlDN5BYtQUwmPMjTqM3WIBQLdxIPEuH9hPxOBeyfUpJoF
HU/0bvK09apkcY1mYp63VpFSRI/yfxNGOURJNUW6y4q+HSB5gZeLjmMHJ1sgoUFztR1IsRDh
dCvg0bfkbMDLo4LG0/0Vtv+nc002GyIN/xze0oPbMbR1SHNJornSK1SqRcEXEcoiBY0o3vBX
D8AcN60wkpugAQclg78CiI+QkC05rL/LGh4oYJd8VyPaDBF0T8P3Dp6Y0kbI0QAAAAAAAA==
--------------ms070302070609070408020401--


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 0BC547F593 for <[e-mail]>; Mon, 13 Jun 2005 11:44:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id 505F214225E for <[e-mail]>; Mon, 13 Jun 2005 11:43:43 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01284-09 for <[e-mail]>; Mon, 13 Jun 2005 11:43:43 -0700 (PDT)
Received: from smtp807.mail.sc5.yahoo.com (smtp807.mail.sc5.yahoo.com [66.163.168.186]) by smtp.osafoundation.org (Postfix) with SMTP id F31E814225C for <[e-mail]>; Mon, 13 Jun 2005 11:43:42 -0700 (PDT)
Received: (qmail 11193 invoked from network); 13 Jun 2005 18:46:14 -0000
Received: from unknown (HELO ?192.168.0.100?) ([e-mail]@69.107.112.17 with plain) by smtp807.mail.sc5.yahoo.com with SMTP; 13 Jun 2005 18:46:13 -0000
Message-ID: <[e-mail]>
Date: Mon, 13 Jun 2005 11:46:10 -0700
From: Dave Thewlis <[e-mail]>
Organization: The Calendaring and Scheduling Consortium
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ietf-calsify list <[e-mail]>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-0.1 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_30_40, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY
X-Spam-Level: 
Subject: [Ietf-calsify] Reminder -- Questionnaire on Implementation of Timezones -- Calconnect and Calsify
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: [e-mail]
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2005 18:44:05 -0000

<!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>
[phone] (voice) &middot; [phone] (mobile)
<a href="http://www.calconnect.org%3E">http://www.calconnect.org</a> &middot; <a
 href="mailto:[e-mail]">[e-mail]</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:[e-mail]">&lt;mailto:[e-mail]&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>


Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from smtp.osafoundation.org (unknown [10.10.1.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 27BD17F56D for <[e-mail]>; Wed,  1 Jun 2005 08:33:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.osafoundation.org (Postfix) with ESMTP id DC6FE14226C for <[e-mail]>; Wed,  1 Jun 2005 08:33:35 -0700 (PDT)
Received: from smtp.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16149-02 for <[e-mail]>; Wed, 1 Jun 2005 08:33:35 -0700 (PDT)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.osafoundation.org (Postfix) with ESMTP id DC7B214224B for <[e-mail]>; Wed,  1 Jun 2005 08:33:34 -0700 (PDT)
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-1) with ESMTP id j51FY9eF012409 for <[e-mail]>; Wed, 1 Jun 2005 17:34:11 +0200
Received: from mail by gauss.math.tu-graz.ac.at with spam_checked (Exim 3.35 #1 (Debian)) id 1Dd7UL-0004Bh-00 for <kainhofer@localhost>; Tue, 31 May 2005 16:13:01 +0200
Received: from mailgate.tu-graz.ac.at ([129.27.3.5] helo=mailgate.tugraz.at) by gauss.math.tu-graz.ac.at with esmtp (Exim 3.35 #1 (Debian)) id 1Dd7UL-0004Ao-00 for <[e-mail]>; Tue, 31 May 2005 16:13:01 +0200
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by mailgate.tugraz.at (8.13.4/8.13.4) with ESMTP id j4VECLBI018445 for <[e-mail]>; Tue, 31 May 2005 16:12:26 +0200 (CEST)
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-1) with ESMTP id j4VECL6d015886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <[e-mail]>; Tue, 31 May 2005 16:12:21 +0200
Received: (from reinhold@localhost) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Submit) id j4VECLGc015883 for [e-mail]; Tue, 31 May 2005 16:12:21 +0200
Received: from neelix.kom.tuwien.ac.at (neelix.kom.tuwien.ac.at [192.35.241.67]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-1) with ESMTP id j4VECDRo015863 for <[e-mail]>; Tue, 31 May 2005 16:12:13 +0200
Received: from m1.dnsix.com (m1.dnsix.com [63.251.171.165]) by neelix.kom.tuwien.ac.at (8.13.1/8.13.1) with ESMTP id j4VEC4mR016404 for <[e-mail]>; Tue, 31 May 2005 16:12:10 +0200 (MEST)
X-Connecting-Host: m1.dnsix.com [63.251.171.165]
X-Connecting-Addr: 63.251.171.165
X-Sent-To: <[e-mail]>
Received: from [208.184.76.39] (helo=above.proper.com) by m1.dnsix.com with esmtp (Exim 4.44) id 1Dd7TQ-0000Sc-DF for [e-mail]; Tue, 31 May 2005 07:12:04 -0700
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDxLD7084589; Tue, 31 May 2005 06:59:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VDxLM4084588; Tue, 31 May 2005 06:59:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDxJsR084581 for <[e-mail]>; Tue, 31 May 2005 06:59:20 -0700 (PDT) (envelope-from [e-mail])
Received: from curie.fam.tuwien.ac.at ([e-mail] [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.4/8.13.4/Debian-1) with ESMTP id j4VDxFwP015225 for <[e-mail]>; Tue, 31 May 2005 15:59:17 +0200
From: Reinhold Kainhofer <[e-mail]>
Organization: FAM, Vienna University of Technology
To: [e-mail]
Date: Wed, 1 Jun 2005 17:34:08 +0200
User-Agent: KMail/1.8
MIME-Version: 1.0
Message-Id: <[e-mail]>
Precedence: bulk
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
X-Loop: [e-mail]
X-Spam-Scanner: SpamAssassin 3.000003 
X-Scanned-By: MIMEDefang 2.51 on 129.27.5.26
X-UID: 3056
X-Length: 8804
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, FORGED_RCVD_HELO
X-Spam-Level: 
Subject: [Ietf-calsify] Questions regarding details of recurrence rules
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.5
List-Id: ietf-calsify.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://localhost.localdomain/pipermail/ietf-calsify>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://lists.osafoundation.org/mailman/listinfo/ietf-calsify>,  <mailto:[e-mail]?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2005 15:33:43 -0000

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: [e-mail], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer